As you doubtless know by now, in 2010 I went and gave a plenary at UMW on the Liberal Arts in an era of Just-In-Time Learning, drank more than any human really should at the various parade of after-events, predicted the coming onslaught of xMOOCs in a drunken vision, and ended up going back to Jim Groom’s place at like 3 a.m. to drink some more.
It was at that point, where my liver was already in the process of packing its bags and moving to find a home in a saner individual that Jim Groom asked me a fateful question.
“So,” he said, “What do you think of my den?”
I looked up and noticed we were sitting in a den.
“It’s nice,” I said.
I don’t remember much more about that night, but I did wake up back in the hotel, so that’s good.
It would be the last time I would drink to that level, because, no joke, I was hungover for three days. Welcome to age 40, time to stop acting like a teenager.
I forget the next time I saw Jim in person, but it was at one conference or another. Someone tried to introduce us, not knowing we go way back (2007?) and Jim said something to the effect of “Oh, I know Mike, we go way back. Last time he was over my house he insulted my den.”
I tried to piece together fragments of that night.
“I said it was nice,” I said.
“Yes,” he said, “Nice. You said it was ‘nice’. I worked hard on that den.”
This was the beginning of #denwars, which would come up anew at every conference.
But this week, heading to ELI, I realized there is another side to the story.
On the way back from that 2010 UMW event I took Amtrak, and I started writing an album called Double Phantasm. (The title is a pun involving John Lennon’s Double Phantasm album and the Derridian notion of hauntology. This is why I’m currently outselling Taylor Swift).
The first song on it, Queen of America, was loosely based on an events of that week. And until yesterday I thought that was the only song that bore any relation to that trip. The rest of the album is a science fiction concept album that details the dying romance of a man and a woman during a post-apocalyptic future. (Again, these hot song ideas are the secrets to my stunning success).
But giving it my first relisten in several years on the plane, I was suddenly struck by the last song, “Like a Great Big Meteor“. It’s the final scene of the four song apocalyptic romance.
And there it was, in the setting of the final scene of that album. It was Jim’s den:
If all we have is now,
then what did we have then
as she sat across me nervously
in what used to be a den?
Here, in this verse, looking for a scene which would contrast former suburban opulence with post-apocalyptic decay I could find no better setting than Jim’s den. The world is over in this song, but what we miss is the den.
The song is rough, as all my songs are (I spend hours writing and tinkering with synth settings and textures, and then basically record a demo-level version of the song in thirty minutes, because I like writing and synths but hate production and singing). Sometimes this style of production works, and sometimes it doesn’t. It sort of half-works here.
But if you listen to my rough vocal on that track you can hear the raw and powerful emotions that Jim’s den stirred in me.
So there you go Jim. I did say your den was “nice”. But that was only because the depths of my feelings for your den could only be expressed through art. Perhaps we can now lay to rest the den wars.
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.
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.
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.