How quill’s editor looks

a bit familiar?

Does editing UI affect writing style?

Listening to This Week in Google, Jeff and Gina were debating writing on Medium, with Gina sorry that people didn't use their own blogs any more, and Jeff saying that Medium's styling and editor made him want to write better to suit the medium house style.

So I wonder if Aaron’s new version of Quill, with its medium style editing for micropub, and Kyle’s Fever dream - which posts to wordpress, blogger and tumblr via micropub, could help change this.

having fever dreams about quill

Ooh, now I can post to my blog with micropub - thanks Kyle!

We Like IndieWeb Software

a response to Anil Dash's I Like Blogging Software

Recently on Twitter Anil Dash and I had a bit of a back and forth:

Hi, it's been two years, will somebody go build this set of tools and go make millions of dollars please? http://t.co/jLX0Dp5DxI

— Anil Dash Dot Com (@anildash) January 14, 2015

@anildash all that's been shipped as #indieweb tools, except we use html instead of json because web. Try it.

— Kevin Marks (@kevinmarks) January 14, 2015

(told for tools there is an autocorrect failure)

@kevinmarks I want products, not toolkits. Cobbling stuff together is too time-consuming & this stuff isn't all in one place.

— Anil Dash Dot Com (@anildash) January 14, 2015

@anildash then use @withknown and send feature requests. Build tools, not specs.

— Kevin Marks (@kevinmarks) January 14, 2015

Marco Rogers chided me for being short with Anil:

@kevinmarks @anildash these are feature requests. From a potential customer. Listening is a good strategy. Berating, less so.

— Marco Rogers (@polotek) January 14, 2015

This is a fair point, and so here is a post going into more detail.

The quoted parts are from Anil's blog post - I'll respond inline:

So, my contribution is to collect some of the notes I've been gathering for the last few years about what I'd like to see in a blogging tool. I know there are apps with many, perhaps even all, of these features, but I'd like to see one emerge as a leading platform for doing innovative work.

(emphasis added)

Here Anil is explicitly calling out for a monoculture, rather than a set of interoperable tools and protocols. As Anil mentions, he used to work at Six Apart, which built several blogging tools in that way, each hoping to be the one. Indeed seeing the success of silos, their monolithic nature can be seen as contributing to this; their widespread adoption coming from focusing on innovating and improving user experience rather than interoperability with others.

With indieweb we are trying a different approach by working through our own wishlists, reusing common components, and making sure we interoperate along the way. This gives us a composable set of tools that do plug together - the toolkit Anil both is and isn't asking for.

My blogging features wishlist:

• I enter markdown in plain text files; these are stored on Dropbox/Google Drive/Skydrive and/or S3 and/or GitHub.
• The system renders those plain files into JSON assets in a documented format.

There are lots of indieweb tools that work in this kind of way; but Anil is very focused on the specifics of formats. Markdown is one popular way of writing text for posts; indeed many indieweb tools support it. JSON is handy as an interchange format between programming languages, but as Anil says, having a documented common format is useful. What we realised working on indieweb is thet we already have a lingua franca for webpages and blogs, and that is HTML. Ultimately all sites publish in this format, so using that and adjusting it minimally to make interop easier is the approach we took.

Our documented format is Microformats 2, which for blog posts involves h-entry and h-feed as common structure, with additional microformats to label other reusable features. Generating HTML from Markdown is relatively straightforward, if not always deterministic, as that was its design goal. Generating JSON from HTML formatted with microformats 2 is also straightforward and more deterministic.

Storing source files in various cloud services is practical and indeed done by many indieweb tools, but requiring a specific cloud service's file system is less flexible and general than using HTML on the web itself, so that's what we do.

• A Bootstrap-themed reading client app lives at my site, on my domain, and reads a single simple config file to learn how to display and navigate between those JSON assets. This client app would also have to handle URL routing and persisting states, while ideally also keeping preferences and reading history for readers.
• The default theme offers a YouTube-style browsing view of all my content, where people can make playlists of posts (this is equivalent to navigating my archives by tag), embed my posts on their own sites, and easily explore by traditional groupings like category or date.

This is a lot of fragility - the default Blogger template switched to a JSON model like this and consequently fails to render a lot of the time. Twitter too used an all-JSON web app for a while, before reverting to HTML+json enhancements. The fragility comes from JSON being much less resilient to encoding or writing errors than HTML - HTML5 specifies how to consistently handle even invalid or poorly marked-up HTML pages, whereas with JSON you will get a parse error and lose the whole page, just like XML. By using HTML instead for your format, the page can be read on every platform by default. Now, behind the scenes JSON can be useful - indeed Known uses a JSON store for its posts database, but exposing this publicly will likely lead to incompatibility over time.

We are beginning to see indieweb reader apps that work by parsing the h-feed and h-entry markup published, and give the remixability that Anil mentions, but they are an augmentation to the basic page, not a required path along the way.

• There might be an optional administration interface separate for me, just for editing the markdown files through a plain text in-browser editor; In this case, it should be a responsive app that works in all my browsers.

On the indieweb, this is handled by two protocols: Micropub and IndieAuth.

IndieAuth lets you prove that you are the owner of the site by logging in, so you can get editing privileges or other enhanced versions.

Micropub is a simple protocol, based on HTML forms, to let you edit and publish posts and notes. By using these two it is possible to have multiple different tools to create and edit posts, independent of the mechanics of their storage, as they also use HTML for interchange.

• Ideally comments are handled as small messages in a documented json format, sent between instances of this blogging application. Of course in the short term I would just embed Disqus/Facebook/Google-style comments until that infrastructure was further along.

For comments we use the same documented HTML format, but add the idea of a webmention. This is a simple protocol that enables you to send a link to your post or comment that responds to (mentions) another post. The webmention receiver can parse this, check it does indeed link to it, and interpret it as a comment, a reply, a repost, a like or an RSVP depending on the microformats markup used.

• Having a documented format for the json objects which represent posts and comments would permit transclusion and sending of posts between sites, in a manner analogous to how Fargo does this for outliners, and in a way that would bring back some of the positives of TrackBack in the early blogosphere.

Exactly! Webmention does this, but with verification and context, which means that it can be used for reposting, but also for threaded comments, per-paragraph annotations and other things we haven't thought of yet.

• "Themes" would largely be implemented as Bootstrap CSS stylesheets, with some affordance for separate content modules. By default, themes are public so I would just be able to tell an admin app to import a theme from your site so I could remix it.

By using HTML as the source interchange format, styling can be done by CSS directly; also it is relatively easy to process and parse HTML and inject it into a site - see the webmentions on my website that are added by an indieweb service.

• The API endpoint for discovering the json representations of content would double as the API for others to access my data to build around it; Eventually a posting app which saved POSTs of that json format as fiels in dropbox would allow a write API.

The webpage itself is the HTML representation of the content; you get the json version by parsing that, using existing parsers - for example:

A posting app can look for the micropub endpoint in the page and the indieauth endpoint and work with that, as tools like Quill, ownyourgram and Postly do now.

I think that's it for now. Let me know if somebody's got all these boxes checked on their platform today, but I suspect the hardest part is the client app for readers, which works in a way analogous to an RSS reader or email client, but would have to support a new format and would be optimized for clean reading and subsequent discovery, rather than the three-pane model which has dominated those apps for the last decade or two.

Anil's assumption that the reader app is harder is shrewd, though it has also been less necessary as the browser enables reading of pages in any case. Indieweb readers are being built now with varying UI based on these underlying protocols, so we should have all the pieces soon.

The closest thing to a single platform that supports this is Known, an open source indieweb-friendly blogging tool that can be installed on your own site or hosted by Known for you.

There's even a Pro version of Known if you want to help make Anil's prediction come true.

If these indieweb ideas sound interesting, come along to the next Homebrew Website Club, or join us in IRC.

Originally on my own website
also on IndieNews

How did Twitter become the hate speech wing of the free speech party?

Twitter has changed. When it started out it was a haven from the unread count in your email inbox, from the tension of blogging and comments. You didn't have to write long form essays, you didn't have to moderate commenters. You didn't have to make all those bold lines go away to reach inbox zero. You just followed some people and typed thoughts that occurred to you. Those who followed you got texted them, or sent them in IM. Simple.

Then, we came up with @ replies. They were a way of making it clear who you were responding to. Twitter sensibly adopted them, but they were off to one side. You had to click on the @ tab to see them. Your primary experience was still the people who you followed, which you controlled. I wrote about Twitter theory with this in mind.

Twitter created permeable, overlapping publics, and championed free speech and anonymity. They said they were the "free speech wing of the free speech party".

Twitter reinforced this by hiding tweets that start with an @ unless you followed the person being talked to. This reduced serendipitous friend discovery, but also damped down arguments. (You can still see this in twitter analytics: note the difference in reach versus engagement for posts versus replies).

However, Twitter had a perceived problem - this very contained, comfortable nature meant that it took effort to get started and find people to follow. They worked really hard at changing this, building a sign up process that made it very hard not to follow lots of people, especially famous ones. Also, they changed the way we got notified.

Emails and app notifications of new followers and @ replies were set up to drive engagement, encouraging you to return.  That @ tab got an unread count on it, just like the email inbox, and the app got a red number on it on iPhones.

The problem with this is that responses do not follow a smooth distribution. Sure, most tweets get no responses, but some take off. Hashtags became another way to spread tweets sideways, beyond the follow graph.

Twitter saw this as increased engagement, and most of the time it was good. They built special tools in for "verified" users—the celebrities and brands they used to woo the rest of us with on sign up. The Verified get to damp down the notification flood, or just see other verified people.

The problem is that by making @ replies the most visible part of the app, they'd brought us back to email and blog comments again.

Your tweet could win the fame lottery, and everyone on the Internet who thinks you are wrong could tell you about it. Or one of the "verified" could call you out to be the tribute for your community and fight in their Hunger Games.

Say something about feminism or race, or sea lions and you'd find yourself inundated by the same trite responses from multitudes. Complain about it, and they turn nasty, abusing you, calling in their friends to join in. Your phone becomes useless under the weight of notifications; you can't see your friends support amongst the flood.

Twitter has become the hate speech wing of the free speech party.

The limited tools available - blocking, muting, going private - do not match well with these floods. Twitter's abuse reporting form takes far longer than a tweet, and is explicitly ignored if friends try to help.

This is where we are now. There are new attempts to remake following-focused semi-permeable publics. Known, ello, Quirell are some. In the indieweb world we are just starting to connect sites together with webmentions, and we need to consider this history as we do.

Also published on my own site

Also published on Known

Also published on ello

Also published on Medium

Fragmentions for Poets

Since the original fragmention implementation and discussion, we've been trying it out in various contexts, including any wordpress blog, Shakespeare's complete works and even the indiewebcamp wiki. Also there have been a lot of reactions and suggestions. Some of these occur often enough that I thought I'd write some responses down.

What if the linked-to text changes?

Several people pointed to the New York Times Emphasis project, which builds IDs from initial letters of sentences in a paragraph to provide some degree of resilience against the linked-to text being changed. It also tries using edit distances if it can't find the text.

Whether you still want to link to changed text is a tricky problem - if it has completely been removed, then the annotation or point of linking may have gone (pointing out a typo, or misstatement). Even a small change (adding the word 'not' for example) can mean that the point of linking has changed, so my first thought is that changing the text breaking the link can be reasonable.

If you want some fuzzy matching to go on, having more of the linked-to text in the fragment can only help the linked-to page identify where in the text was intended. Indeed, if enough is included, you could show the difference between what was linked to and what is there now.

What if the linked-to text occurs more than once?

By default, go to the first instance. If you want a different link, use more words to create a unique reference. While there have been proposals to link to the nth occurrence using more complex syntax, I don't think this is actually a natural choice, and likely to be more fragile. The NYT Emphasis tool mentioned above switched from a nth sentence type model to a content dependent one for this reason; fragmentions simplify and extend this idea.

I have tried to come up with a use case that fits this goal - the closest I can think of is referring to a particular repetition of a line of poetry, for example in a villanelle.

I can link to the 3rd line of the 1st verse by citing it in full. If I wanted the final line, linking to it and the line before would work. I think this is clear, though linking to night & Rage would be enough.

The only reason I can think of to link to specific lines would be to discuss them in the context of surrounding lines, so I think this works adequately.

If a tool is made to allow readers to construct a link to a specific phrase, indicating that that phrase is not unique to encourage them to choose a longer phrase may be worth it.

Could you combine an id and a fragmention?

A link of form #id##some+words has been suggested, but again I'm not sure I see the utility. This is the nth occurrence idea in a different guise. It combines two addressing models in one, making it harder to construct and more fragile to resolve.

Can we get rid of ## and just use #?

The other thought, based on closer reading of the HTML5 spec ID attribute:

The id attribute specifies its element's unique identifier (ID). [DOM]

The value must be unique amongst all the IDs in the element's home subtree and must contain at least one character. The value must not contain any space characters.

There are no other restrictions on what form an ID can take; in particular, IDs can consist of just digits, start with a digit, start with an underscore, consist of just punctuation, etc

is that we may not need the ## (which technically makes an invalid URL) at all.

If an HTML5 id cannot contain a space, then a fragment that contains one like #two+words can never match an id (as id="two words" would be invalid). If it can't be an id it should be treated as a fragmention.

If you really want a one-word fragmention a trailing space like #word+ could be used.

This means that the idea of fragmention could be simplified: if a fragment contains a space it MUST be a fragmention, and should be searched for in the text. If it doesn't match any IDs in the page, it COULD be a fragmention and should be searched for in the text anyway.

Fragmentions become a fallback to be used when an id can't be found.

Do not go gentle into that good night

Do not go gentle into that good night,
Old age should burn and rave at close of day;
Rage, rage against the dying of the light.

Though wise men at their end know dark is right,
Because their words had forked no lightning they
Do not go gentle into that good night.

Good men, the last wave by, crying how bright
Their frail deeds might have danced in a green bay,
Rage, rage against the dying of the light.

Wild men who caught and sang the sun in flight,
And learn, too late, they grieved it on its way,
Do not go gentle into that good night.

Grave men, near death, who see with blinding sight
Blind eyes could blaze like meteors and be gay,
Rage, rage against the dying of the light.

And you, my father, there on the sad height,
Curse, bless, me now with your fierce tears, I pray.
Do not go gentle into that good night.
Rage, rage against the dying of the light.

by Dylan Thomas

hear him read it

Originally on my own website

Fragmentions - linking to any text

A couple of weeks ago, I went to a w3c workshop about annotations on the web. It was an interesting day, hearing from academics, implementers, archivists and publishers about the ways they want to annotate things on the web, in the world, and in libraries. The more I listened, the more I realised that this was what the web is about. Each page that links to another one is an annotation on it.

Tim Berners-Lee's invention of the URL was a brilliant generalisation that means we can refer to anything, anywhere. But it has had a few problems over time. The original "Cool URLs don't change" has given way to Tim's "eventually every URL ends up as a porn site".

Instead of using URLs, Google's huge success means that searching for text can be more robust than linking. If I want to point you to Tom Stoppard's quote from The Real Thing:

I don’t think writers are sacred, but words are. They deserve respect. If you get the right ones in the right order, you can nudge the world a little or make a poem which children will speak for you when you’re dead.

the search link is more resilient than linking to Mark Pilgrim's deleted post about it, which I linked to in 2011.

Another problem is that linking in HTML is defined to address pages as a whole, or fragments within them, but only if the fragments are marked up as an id on an element. I can link to a blog post within a page by using the link:

http://epeus.blogspot.com/2003_02_01_archive.html#post-body-90336631

because the page contains markup:

<div class="post-body entry-content" id="post-body-90336631" >

But to do that I had to go and inspect the HTML and find the id, and make a link specially, by hand.

What if instead we combined these two ideas:

• use a fragment to identify part of a page
• mention words in the page as the identifier

I've named these "fragmentions"

To tell these apart from an id link, I suggest using a double hash - ## for the fragment, and then words that identify the text. For example:

http://epeus.blogspot.com/2003_02_01_archive.html##annotate+the+web

means "go to that page and find the words 'annotate the web' and scroll to show them"

If you click the link, you'll see that it works. That's because when I mentioned this idea in the indiewebcamp IRC channel, Jonathan Neal wrote a script to implement this, and I added it to my blog and to kevinmarks.com. You can add it to your site too.

However, we can't get every site to add this script. So, Jonathan also made a Chrome Extension so that these links will work on any site if you're running Chrome. (They degrade safely to linking to the page on other browsers).

So, try it out. Contribute to the discussion on the Indiewebcamp Fragmentions page, or annotate this page by linking to it with a fragmention from your own blog or website.

Maybe we can persuade browser writers that fragmentions should be included everywhere.

Originally posted on kevinmarks.com

How Apple's iOS fragmentation problems distort design thinking

As someone who uses both Android and iOS regularly, I'm getting increasingly frustrated by fragmentation. However it's not on my Android devices I see this, but on the iOS ones. I install a popular, well-funded application like Instagram, Flickr, or Circa on my iPad, but when I launch it 3/4 of the screen is black bars, with a teensy little app in the middle. Or I can choose to scale it up without smoothing, so jagged pixels I have't seen since the 1990s reinforce the sense that I am doing something wrong by attempting to run this app here. Every affordance is pushing back at me, saying I'm doing it wrong.

By contrast, on Android applications scale up to fill the space sensibly - buttons stay button sized, text and image areas expand well. Developers can add alternative layouts to better handle varying sizes, but if they don't things remain legible and touchable.

One hand or on your knees?

More pernicious is the artificial dichotomy that the iOS world leads our design thinking into. You're either on the held-in-one-hand phone, briefly standing somewhere, or you're sitting down in the evening using your iPad (so big and heavy that you have to rest it on your knees - Steve Jobs even brought out a sofa to sit on at the launch). This false 'mobile versus desktop' dichotomy even misled Mark Zuckerberg when he said "iPad's not mobile, it's a computer." and at the Facebook Home Launch, a tablet version was said to be "months away", though a working version was hacked together by outside programmers within days.

Meanwhile, nobody told Barnes and Noble, whose 7" Nook did so well that Amazon launched a Kindle range the same size, leading to the lovely Nexus 7 from Google and finally to the iPad Mini from Apple. This is the form factor, tested for years by paperback books, that makes one-handed long form reading comfortable. If you spend any time on public transit, being able to read standing up or in narrow bus seats is an obvious benefit. But the hermetically sealed company-coach commuters at Apple missed this for years.

Steve Jobs even said you'd have to file down your fingers to use it. The thing is, on iOS it does feel like that. The iPad sized apps have too-small buttons, the iPhone ones are too big if zoomed. There is no way for an app to know how big your finger is compared to the screen, let alone a website.

The supposed advantage of iOS is fewer sizes to design for, but now you need 12 different layouts to cope with the horizontal and vertical orientations of each device, and the general layout tools don't handle this as well as Android, requiring complex updates. Chiu-Ki Chan explains the pain, whereas Android Studio just made this even easier for developers.

No App is an island

The other fragmentation problem on iOS are the missing links. Not in the evolutionary sense, but the ability to readily connect between applications using URLs, as we're used to on the web. Applications can't claim parts of a URL, only a whole scheme. As Apple says:

If more than one third-party app registers to handle the same URL scheme, there is currently no process for determining which app will be given that scheme.

On Android, any app can claim any scheme, host and path, and the OS will resolve as appropriate, giving you a choice if more than one possibility is available.

On iOS, each app ends up embedding webviews inside it rather than linking to a browser, fragmenting your web history. I have to remember whether I got to the page via Twitter, or Facebook or email to go back to it later on, and I only get to share it to the iOS-approved places, Twitter, Facebook, email or iMessage. On Android, any installed app that can handle that type of media is an option to share to, or create a photo, make a phonecall, any of hundreds of "intents" that act as bridges between apps and, through browsers, the web.

This means that Android apps don't end up doing everything, but hand off to each other as needed, meaning that you can replace any function cleanly across apps. Better keyboards are the obvious example here, but camera apps, browsers, and SMS apps can drop themselves in, with the choice made by the user.

On iOS, you have to explicitly link to the scheme, which is per-app. Ironically, this means that Google (or Facebook) can release a set of iOS apps that connect to each other preferentially, leaving the Apple applications out of the loop. But it also makes it harder for developers to specialise in doing one thing well and linking to the rest.

What of the Web?

The other pernicious influence of iOS fragmentation has been the rise of the mobile-only site - the m. layout that was tuned for iPhone use, then slightly adapted for other mobile users, often giving rise to farcical single column layouts with huge whitespace on tablets. In the early iOS days this was a bonus, as it encouraged function-first design, without the organisation-chart-inspired cruft around the edges that websites accumulate over time. As the effective resolution of mobile devices has increased, now often exceeding what is available on desktops, the assumptions that drove mobile-specific sites are breaking down.

Now that Android is the dominant operating system, Google is getting serious about it as a web platform too, which is very welcome. The Android Browser was installed as part of the OS, and didn't get upgraded over time. This has changed, with Chrome now the default Android browser, and it is on a regular update pipeline like Desktop Chrome and Firefox. iOS's Safari updates are frequent too now, and Microsoft is now pleading with developers to give them modern web apps too.

Truly responsive design has succeeded mobile-first as the best choice for websites, and we're seeing this spread as browsers converge on HTML5 features. What this means is that the web platform is now evolving rapidly, without any one browser provider being a bottleneck. The installed base for SVG passed Flash a while back, and even Adobe is now backing the web fully, bringing their design know-how to HTML5 features such as regions and exclusions. Also in the pipeline for HTML5 is browser to browser audio, video and text chat via WebRTC.

Hoping Apple continues the revolution

This web platform revolution was catalysed by Apple with WebKit and Mozilla with Firefox, and picked up by Google, Microsoft, Adobe and others. We now have a Browser Battle to be more standards compliant and consistent, rather than a Browser War to be different and proprietary. What I'll be hoping for from Apple at next weeks WWDC is a clear recognition of these design lacunae and new and better ways for developers to succeed both with native apps and on the web.

This was also published on TechCrunch.

Finally, some progress in video codecs.

An announcement on Friday via Brendan Eich:

ORBX.js, a downloadable HD codec written in JS and WebGL. The advantages are many. On the good-for-the-open-web side: no encumbered-format burden on web browsers, they are just IP-blind runtimes. Technical wins start with the ability to evolve and improve the codec over time, instead of taking ten years to specify and burn it into silicon.

I think the 'remote-screen viewing of videogames' use case is bogus (if anyone notices latency it's gamers), but this is a really important development for the reasons Brendan mentions and more.

Nine years ago, I wrote:

I'd say video compression is maybe 2-4 times as efficient (in quality per bit) than it was in 1990 or so when MPEG was standardised, despite computing power and storage having improved a thousandfold since then.

Not much has changed. The video compression techniques we're using everywhere are direct descendents of 1980s signal processing. They treat video as a collection of small 2D blocks that move horizontally and vertically over time, and encode all video this way. If you want to make a codec work hard, you just need to rotate the camera. Partly this is because of the huge patent thicket around video encoding, mostly it's because compression gets less necessary over time as network capacity and storage increases. However, it was obvious 10 years ago that this was out-dated.

Meanwhile, there has been a revolution in video processing. It's been going on in video games, and in movies and TV. The beautiful photorealistic scenes you now see in video games are because they are textured 3D models rendered on the fly for you. Even the cut scenes work this way, though their encoding is often what compression researchers dismissively call a 'Graduate Student Algorithm' - hand-tweaking the models and textures to play back well within the constraints of the device. Most movies and TV has also been through 3d-modelling and rendering, from Pixar through visual effects to the mundane superimposition of yard lines on sports. The proportion of YouTube that is animation, machinima or videogame run-throughs with commentary keeps growing too.

Yet codecs remain blind to this. All this great 3d work is reduced to small 2D squares. A trimesh and texture codec seems an obvious innovation - even phones have GPUs in them now, and desktops have for 20 years. Web browsers have been capable of complex animations for ages too. Now they have the ability to decode bytestreams to WebGL in real time, we may finally get codecs that are up to the standards we expect from videogames, TV and movies, with the additional advantage of resolution independence. It's time for this change.

Forking, Spooning or Knifing?

Reading the tech news this week, there's a lot of talk about forking. Google Blink forking AppKit. Apple not forking Chromium because that would be hostile. Facebook 'forking' Android. Even Tim O'Reilly forking the memetic nature of Free Software into Open Source.

However not all of these things are really forks, and forking is no longer necessarily a hostile act. Lets go through them. Google Blink is a fork of Webkit, or rather of Webcore. Alex explains this is to reduce the amount of time they need to spend merging back to Webkit, but it doesn't preclude anyone continuing to do this if desired. Maciej explained that the reason for the difference in multiprocessing implementations that precipitated this was Apple not wanting to do so.

Facebook did not need to fork Android, because it is designed to support substitutable components. You can swap out any OS components, and you can communicate between apps using intents. Indeed, Facebook could make a deal with handset manufacturers or carriers that don't offer the 'with Google' experience to replace it with a Facebook one. Expect to see this in overseas markets, especially the ones where Facebook Zero works with carriers.

The more subtle thing is that forking is no longer perjorative. It used to be a last resort, what you did when your open source community had broken down. It meant that people had to pick sides, and choose which fork to adopt, because open source had a hierarchic nature. Now, forking is what you do to show interest. If you go to github, where much open source lives now, forking a project is a single click. Sucessful projects will have many forks, and will accept pull requests from some of them.

This is the real difference between the Free Software and Open Source worldviews that were debated this week - the web enables more parallel, less centralised forms of co-operation and ownership. The monolithic projects and integrations are giving way to ones with better defined boundaries between them, and the ability to combine components as needed. Which means tech companies don't get to tell each other to "Knife the baby" any more.

Hosting and Impermanence

I linked to my boys' old blog today when Christopher asked for an April Fools prank idea, and noticed that the images were missing. This is due to the demise of iDisk, Apple's handy built-in version of DropBox that I paid them about $100/year for until they shut it down and broke all my links to it.

To fix this, I copied the old iDisk Sites folder to Google Drive, and manually changed the links in the blog posts. Then I had a thought - could I host my twitter archive this way? As you can see it works.

Here's how to do it:

1. Download your Twitter Archive by clicking Request your archive on the Account Settings page.
2. Install Google Drive
3. Expand the archive and copy it into the local Google Drive folder
4. Go to Google Drive in the browser, and set the folder to public using the Share button.
5. Copy the URL which will be something like: https://drive.google.com/#folders/0B7cAS_dEul22V3d5c0d5WkpEOFE
6. Edit the first part to be 'googledrive.com/host' so you get https://googledrive.com/host/0B7cAS_dEul22V3d5c0d5WkpEOFE
7. (Optional) Go over to a URL shortener and make a short link for it like I did http://j.mp/kmtweets

Now you have your old tweets hosted on Google. Tweet a link to them.

Aha, I can just drag my Twitter archive onto Google Drive and publish it j.mp/kmtweets

— Kevin Marks (@kevinmarks) April 2, 2013