In case you don’t know, I believe the future of the web involves moving away from the idea of centralized, authoritative locations and into something I call “connected copies”.

The idea is that the current model of the web, which is based on the places where things live instead of the names of things, creates natural choke points and power inequities. Further, it undermines the true peer-to-peer potential of the web.

A newer model would look like email, torrenting, or git, where multiple copies of things were stored across the web, but connected and authenticated by protocols, data models, or other conventions. Federated wiki is one way to do that. Named Data Networking is another. The Interplanetary File System is a third. This new project by the Berkman Center is a fourth.

I’m posting this because I’ve been writing an explanatory post on Connected Copies for five months now (and I’ve been writing on the subject of copies as an approach to OER for over half a decade) and it’s clear it’s just a hard idea to explain to people who aren’t poised to get it. The draft of the explanatory post is now about 10,000 words which is ridiculous.

But maybe the better way to get the idea is to just keep this term in your head — connected copies — and just go about your daily life. My experience is that once you do that, you can’t unsee how many people are working in this space.

Making a quicker pass at the reply to Dave Winer below, I want to call out one radical idea that people don’t get: You should be able to browse the web through your own website.

As an example of this, consider my Wikity interface when I’m logged in (if you’re not logged in the interface will be missing the edit box):

I use Wikity as a combination social-bookmarking tool and wiki. And I’ve got my site set  up in a way that’s efficient for me — I have a Markdown based editor at the top, and then around it I have little Pinterest-like excerpts of my posts. When I want to write something new, or when I read something I want to summarize I usually execute a search to remind me of what I’ve written on it before and then plug stuff into the Markdown box. I scan over these search results and link to them or quote from them as I write.

If I want to alter older posts to link to this, I can quick-edit them on the spot to cross link my new stuff.

I haven’t quite got this part working yet, but the idea is a multi-document editing environment that mimics some of the affordances of federated wiki. Here’s a screenshot of writing an article while updating two other articles to link to the new information (note scroll bars of pages where editing is going on).

But the thing is it’s really lonely in here — the only things I’m working with are the ones I’ve created.

And what I learned from federated wiki is doesn’t have to be like that. If I had a common data format and a set of protocols, I could pull all the articles from my friends into this space, and I could fork them in and work on them, link to them, etc.

In the web as it is, we move, and the data stays put. In a federated web, the data moves and we stay put. Does that make sense?

To me at least, that’s the core dream of federated wiki. But what’s interesting is it’s also the dream of Dave Winer to reboot the blogosphere.

You can do some of the above with feeds, of course. But for something like the search-my-network-and-write habits I’ve developed you really need API calls, and if you are going to port things like categories and data and media that are going to be processed by the UI you might as well put it in JSON.

Dave Winer wrote a recent post on, roughly, how to reboot the Blogosphere with JSON. I read it last night and thought I understood it, then read it again this morning and realized I’d missed the core idea of what he was saying. Here’s the relevant graf:

But there is another approach, to have WordPress accept as input, the URL of a JSON file containing the source code for a post, and then do its rendering exactly as if that post had been written using WordPress’s editor. That would give us exactly what we need to have the best of all worlds. Widespread syndication and control over our own writing and archive. All at a very low cost in terms of storage and CPU.

Maybe I was just a bit tired last night but it’s worth staying on how this is different from other models. The idea here is that your data doesn’t have to be stored in WordPress at all. Dave Winer can make his editor, Ward Cunningham can make federated wiki — but should they want to publish to WordPress site —

See, that’s not quite it either. Because the idea here as I read it is pull, not push. (Dave, correct me if I misunderstand here). The idea is, given certain permissions and compliance with a WordPress API, a WordPress site I have can go out and fetch Dave or Ward’s content and render it up for me in my own blog dynamically.

I’m not sure Dave is going this far, but imagine this as a scenario — I link to Dave on my WordPress blog, but the link makes a double pass.

First, it sees if it can just grab the JSON and render Dave’s post in my WordPress blog. If it can, great. It renders Dave’s page with the links. Links I click on there also attempt to render in my default WordPress environment.

Sometimes links won’t return nice requests for JSON. Those ask me if I want to go outside my reading environment to someone else’s site. If history is any guide, these sites don’t get much traffic, because the answer to that question is often no.

Links that render into your environment could be acted on by your theme functions. Maybe you take a snapshot of something, repost it, index it, annotate it. Over time, there is a market for themes that play nice with other peoples content, or allow people to make the best sense of it.

And of course if you add in feeds….

What this does is move from a situation where we have a couple online RSS readers to a world where every WordPress theme (and there are tensof thousands of WordPress themes)  is potentially an RSS reader of sorts. It moves from a world where every theme is potentially a new Facebook or Twitter as well.

It does this because it solves part of the problem Facebook solved for people — it lets us read other people’s stuff in a clean, stable environment that we control. (There are other things as well, but you have to start somewhere).

So why not try this? Turn themes — the killer feature of WordPress — into a way to read other people’s content, and see what happens. WordPress has already made a stab at being the universal publisher, but it could be the Universal Reader as well, not through providing a single UI, but by supplying an endlessly customizable one.

Update: If you read the comments below you’ll see one of the API developers has responded; there are some issues with private information in short codes being exposed.

I still wish all the smart-quotification, m-dashing, and paragraphing could be more easily disabled, but I’m very grateful for the quick and thoughtful response.

——-

I wasted another afternoon looking for a way that I won’t have to write my own custom WordPress JSON API. After all, the WordPress REST API folks have spent many, many hours producing a core API, and writing my own just seems silly.

But it looks like I will have to write my own, and I thought I’d explain why. Maybe the WordPress API folks will read this and understand a whole set of use cases they have missed.

Here’s the deal. I store Markdown in my WordPress database. Not the processed stuff. Not Markdown that turns to HTML on save. Markdown.

I do this because I believe in what I call “capable clients”. I want anyone else to be able to make their own client and represent my data in the best way they see fit.  I want people to be able to fork my source text. I want people to be able to remix my stuff with stuff from other servers.

The same is true about the short codes that go in for things like images. I want my reader’s client to get the source and render it, or move it to their server to render.

I don’t think this is such a weird thing. This is, after all, how the web worked in 1991, before graphic designers and relational database designers mucked the whole thing up with their magazine designs and fifth normal forms.  Back in 1991, if you saved a file from Tim Berners-Lee’s NeXT server to your laptop, you had an exact copy of what Tim’s server had. You had the source. It was a level playing field.

APIs + JSON gives us a chance to return to that world, a world of capable clients. A world where clients of my platform can potentially build a better view of my data than I had imagined.  A world where I let you fork raw data from my server and reuse it on yours, git-style. A world where people can remix data from multiple servers in new and illuminating ways, the way they did in the early days of RSS.

That’s the real promise of JSON development — the permissionless innovation that characterized the early web, but brought up to date.

So why would you only allow raw content — the unprocessed HTML or Markdown source — to be accessed by people who are logged in as editors?

Is what I typed originally into the text field of the WordPress editor such a secret? I suppose it could be, but why not give people the option to see exactly what I entered into the editor? Why fix it with paragraph tags and smart quotes, when you don’t even know if it’s HTML, or Markdown, or LaTeX stored there? Why run always run the shortcode filters, even when the client wants the data — not the useless processed output?

There’s a huge opportunity here to unleash a level of innovation we haven’t seen for years. But it starts with allowing capable clients to consume clean data, even if they only have read permissions.

In a system that truly values client-side development, clean data is a right, not a privilege. Why not give us that right?

I’m excited about Brave, the new browser coming out with privacy and content payment features built into the core browser code. I won’t detail it here, but you need to check it out.

The piece that people miss about all these debates about Facebook-ization and evil tracking and big data is that the Web we got is largely a function of the structure of browsers and protocols we inherited. As a simple example, a browser has an idea of what your IP is, but no concept of you as a user, which means you need to rely on big central servers like Facebook to supply an identity to you. (Compare email, where identity is federated, and central to the system protocols).

As another example, more pertinent to Brave, the third-party cookie hack available in browsers sprouted a culture of Surveillance as a Business Model.

I think two approaches to this mess have emerged. The first idea is since browsers cede all your power to servers (at least when you want to do something interesting) — the idea is you should own a server, because that’s where the power is.

I think the less publicized idea is to move more power back to the client. Let the browser (or the JavaScript running in the browser) make more choices on how to interact with the web, supplying the layers that never got built, the identity, commerce, and syndication gaps that companies like Google and Facebook have made a fortune filling in.

Both the “Own your own domain” approach and the “Power to the client” approach to a better web are complementary, but I actually believe that it is this second path — exemplified by projects such as Brave and Calypso — that has the best chance of broad adoption.

See also Calypso is the Future of Personal Cyberinfrastructure

If you’ve started a new site on Wikity, you’ll notice that it has a new interface. We’ve taken some cues from people who loved the index-cardiness of federated wiki and from others who urged us to embrace the “like Pinterest for text” elevator speech and JUST GO WITH IT.

These are your latest posts, with special first two cards.

The first card has your site name and description, as well as a number of functions we’ll get to in a moment. The second card, which only appears when you are logged in as an author or editor, is a “quick create” window, and it turns out to be awesome.

So let’s make a page using the quick create interface.

We’re going to make this page using Markdown. While Markdown has a but of a learning curve to it, it turns out to be easier to learn and less overwhelming than many graphical WYSIWYG interfaces. It also turns out to be a killer way to compose posts on your phone as well as make sure that the site is accessible to people who may not be able to operate a mouse or trackpad, or may have a vision impairment which makes selection of text time-consuming. In the past few weeks, I’ve come to see Markdown support in terms of universal design, and it’s a good fit.

So we make a page. Here we’re going to take some notes for a class on colonialism. We’re researching the 1931 Paris exhibition (one of the last of the “human zoos”) and we want to research and record what we can on the full-scale model of Angkor Wat which was constructed in Paris for the event.

We fill out the title and write an introductory paragraph. Then we decide we want to add a video, so we copy a YouTube URL.

And then paste it in our text box as a bare URL

Now we’ll add a blockquote, using the Markdown “angle bracket” syntax, and the asterisk syntax to italicize the title:

Want to add a picture? We use the markdown syntax with a twist — put in a Markdown image reference to an external image, and when you save the file the server will go out and fetch that image for you and upload it to your server, replacing your image URL with the new one. (Make sure you cite the author!)

Here we put an image at the top of our post:

Now we add our works cited, and related pages using the hash heading syntax (here we’ll do heading level 3):

And here’s what that page looks like — formatted, with an embedded YouTube and a cited image that is now being served from your local server:

Want to edit it after you post? Just click any card in your “card stack”, and it goes back to edit mode.

I know this may seem like it’s complex, but I’ve shown this to a few people now, and the pain of having to learn a bit of Markdown is made worth it by never having to enter into the Dashboard interface, even when doing a complicated multi-part formatted document like this.

Moreover, I am not kidding you when I say it is possible to compose a document like this using any size smartphone — there’s no modifier keys needed (alt, cntrl), no complex download and upload behaviors, no ribbon menu bars, no right click. I personally believe the laptop is the most perfect machine ever invented, but I have done edits on the fly on my phone, and even started an article or two. The ability to do this on mobile can supplement laptop use in nice ways.

Anyway, next post will be on the new feature called “paths”, which was inspired by Vannevar Bush, but can also form the basis of an OER strategy.

Wikipedia turned 15 today, a day where I happen to have my back against the wall on some deadlines. Turns out faculty want to nail down their edtech plan by week three of the class. Who knew?

But in any case, I didn’t want to let the anniversary go by without saying something.

The thing I’ve come to realize about Wikipedia is this: it’s the one impossible thing the Web has given us.

Name the other things you encounter on the Web on a daily basis: email, online reading, shopping, media viewing, self-paced education, online hobby communities, self-publishing. Cooperative music making.

For any of these things I can find you a prediction somewhere between 1968 and 1978 that describes these functions as an inevitable part of the future. In many cases (e.g. online education and shopping) I can show you early 1970s technologies *in use* that are not that different from what we do today.

If, at the dawn of the web, I was to take a list of things the web would bring about and show them to a researcher, they might disagree on the level of interest people would have in things (what’s with the cat pictures, spaceman?) but there’d be little there to surprise them except for one item: the most used reference work in the world will be collaboratively maintained by a group of anonymous and pseudonymous volunteers as part of a self-organizing network.

Nobody predicted that in 1971 or 1991. In fact, in 2001, the only people predicting it were a small group of people who had been using wiki.

I’m sure people will reply that I’ve missed thing X or Y, and there’s an argument to be made that “the one impossible thing” is hyperbole. But if it is, it’s not by much, and most of the things you’d mention were partially inspired by Wikipedia in any case.

It would be nice if on this day, as we marvel about the rise of Wikipedia, we could turn some of our attention to the Wikipedias of the future. Where are opportunities for this mode of collaboration that we’ve missed? Why are we not confronted by more impossible things? How can we move from the electronic dreams of the 1970s to visions informed by the lessons of wiki and Wikipedia?

Some people might think we’ve already done that. But I’m pretty sure we’re barely getting started.

A recent-ish study looked at film recommendation systems and found an interesting result: perceived novelty of the recommendations was negatively correlated with user satisfaction, and user satisfaction was correlated adoption.

One of the most striking things we found is that the novelty of recommended items has a significant negative impact on users’ perception of a recommender’s ability to satisfactorily meet their information needs. This effect was particularly strong in its impact on the user’s first impression of an algorithm, and was present even though we restricted the depth of the long tail into which our algorithms could reach.

And so you end up with what I’ll call the recommender’s paradox. People turn to recommendation systems to find things they wouldn’t have thought of themselves, but they choose recommendation systems that largely provide them choices that don’t surprise them. Aspects of trust in the recommender relationship undermine efficacy.

One approach to the paradox is to introduce novelty slowly, after trust is built, but there’s some bad news there as well:

Increasing the novelty of recommendations as the user gains more experience with the system and has had more time to consider its ability to meet their needs may provide benefit, but our results cannot confirm or deny this. The users in our study are experienced with movie recommendation in general and MovieLens in particular (the median user has rated 473 movies), and their first impressions were still heavily influenced by novelty.

One other way to think of this is that people think they want new films recommended to them but actually they really want to be reminded of films they had already been thinking about seeing but had forgotten about, or notified about familiar looking films that had slipped under their radar. My guess is the most successful engine (based on user satisfaction) would probably provide you with a wide range of films by directors and actors you know you like but had forgotten about, in genres that you know work for you.  These results would seem tailored to you, but at the same time be things you would not have thought of yourself.

Obvious implications here on Open Educational Resource recommendation algorithms, Big Data, the Filter Bubble, and the problem of resistance to novelty in education more generally.

We got our first piece of spam on Wikity, so we’ve rotated out the join code. It used to be “peloton”. It is now “copies”.

If you are reading this post more than a month after it was posted, you probably need to look for a more recent post on Wikity, with a new join code. We’ll rotate it as often as we have to to keep spammers out.