I think this one single feature is going to get me to switch to iA Writer:
For starters, we added Micropub support. This means you can publish to Micro.blog and other IndieWeb tools.
A great introduction to indie web building blocks from Jamie.
Paul is making a micropub endpoint for static sites—very cool!
Here’s the talk I gave recently about indie web building blocks.
There’s fifteen minutes of Q&A starting around the 35 minute mark. People asked some great questions!
A good half-hour presentation by Stephen Rushe on the building blocks of the indie web. You can watch the video or look through the slides.
I’ve recently been exploring the world of the IndieWeb, and owning my own content rather than being reliant on the continued existence of “silos” to maintain it. This has led me to discover the varied eco-system of IndieWeb, such as IndieAuth, Microformats, Micropub, Webmentions, Microsub, POSSE, and PESOS.
Here’s the video of the talk I gave at Design4Drupal last week in Boston. There’s a good half an hour of questions at the end.
This presentation on the indie web was delivered as the opening keynote at Webstock in Wellington, Zealand in February 2018.
Thank you. Thank you very much, Mike; it really is an honour and a privilege to be here. Kia Ora! Good morning.
This is quite intimidating. I’m supposed to open the show and there’s all these amazing, exciting speakers are going to be speaking for the next two days on amazing, exciting topics, so I’d better level up: I’d better talk about something exciting. So, let’s do it!
Yeah, we need to talk about capitalism. Capitalism is one of a few competing theories on how to structure an economy and the theory goes that you have a marketplace and the marketplace rules all and it is the marketplace that self-regulates through its kind of invisible hand. Pretty good theory, the idea being that through this invisible hand in the marketplace, wealth can be distributed relatively evenly; sort of a bell-curve distribution of wealth where some people have more, some people have less, but it kind of evens out. You see bell-curve distributions right for things like height and weight or IQ. Some have more, some have less, but the difference isn’t huge. That’s the idea, that economies could follow this bell-curve distribution.
But, without any kind of external regulation, what tends to happen in a capitalistic economy is that the rich get richer, the poor get poorer and it runs out of control. Instead of a bell-curve distribution you end up with something like this which is a power-law distribution, where you have the wealth concentrated in a small percentage and there’s a long tail of poverty.
That’s the thing about capitalism: it sounds great in theory, but not so good in practice.
The theory, I actually agree with, the theory being that competition is good and that competition is healthy. I think that’s a sound theory. I like competition: I think there should be a marketplace of competition, to try and avoid these kind of monopolies or duopolies that you get in these power-law distributions. The reason I say that is that we as web designers and web developers, we’ve seen what happens when monopolies kick in.
We were there: we were there when there was a monopoly; when Microsoft had an enormous share of the browser market, it was like in the high nineties, percentage of browser share with Internet Explorer, which they achieved because they had an enormous monopoly in the desktop market as well, they were able to bundle Internet Explorer with the Windows Operating System. Not exactly an invisible hand regulating there.
But we managed to dodge this bullet. I firmly believe that the more browsers we have, the better. I think a diversity of browsers is a really good thing. I know sometimes as developers, “Oh wouldn’t it be great if there was just one browser to develop for: wouldn’t that be great?” No. No it would not! We’ve been there and it wasn’t pretty. Firefox was pretty much a direct result of this monopoly situation in browsers. But like I say, we dodged this bullet. In some ways the web interpreted this monopoly as damage and routed around it. This idea of interpreting something as damaged and routing around it, that’s a phrase that comes from network architecture
As with economies, there are competing schools of thought on how you would structure a network; there’s many ways to structure a network.
One way, sort of a centralised network approach is, you have this hub and spoke model, where you have lots of smaller nodes connecting to a single large hub and then those large hubs can connect with one another and this is how the telegraph worked, then the telephone system worked like this. Airports still pretty much work like this. You’ve got regional airports connecting to a large hub and those large hubs connect to one another, and it’s a really good system. It works really well until the hub gets taken out. If the hub goes down, you’ve got these nodes that are stranded: they can’t connect to one another. That’s a single point of failure, that’s a vulnerability in this network architecture.
It was the single point of failure, this vulnerability, that led to the idea of packet-switching and different network architectures that we saw in the ARPANET, which later became the Internet. The impetus there was to avoid the single point of failure. What if you took these nodes and gave them all some connections?
This is more like a bell-curve distribution of connections now. Some nodes have more connections than others, some have fewer, but there isn’t a huge difference between the amount of connections between nodes. Then the genius of packet-switching is that you just need to get the signal across the network by whatever route works best at the time. That way, if a node were to disappear, even a relatively well-connected one, you can route around the damage. Now you’re avoiding the single point of failure problem that you would have with a hub and spoke model.
Like I said, this kind of thinking came from the ARPANET, later the Internet and it was as a direct result of trying to avoid having that single point of failure in a command-and-control structure. If you’re in a military organisation, you don’t want to have that single point of failure. You’ve probably heard that the internet was created to withstand a nuclear attack and that’s not exactly the truth but the network architecture that we have today on the internet was influenced by avoiding that command-and-control, that centralised command-and-control structure.
Some people kind of think there’s sort of blood on the hands of the internet because it came from this military background, DARPA…Defence Advance Research Project. But actually, the thinking behind this was not to give one side the upper hand in case of a nuclear conflict: quite the opposite. The understanding was, if there were the chance of a nuclear conflict and you had a hub and spoke model of communication, then actually you know that if they take out your hub, you’re screwed, so you’d better strike first. Whereas if you’ve got this kind of distributed network, then if there’s the possibility of attack, you might be more willing to wait it out and see because you know you can survive that initial first strike. And so this network approach was not designed to give any one side the upper hand in case of a nuclear war, but to actually avoid nuclear war in the first place. On the understanding that this was in place for both sides, so Paul Baran and the other people working on the ARPANET, they were in favour of sharing this technology with the Russians, even at the height of the Cold War.
In this kind of network architecture, there’s no hubs, there’s no regional nodes, there’s just nodes on the network. It’s very egalitarian and the network can grow and shrink infinitely; it’s scale-free, you can just keep adding nodes to network and you don’t need to ask permission to add a node to this network. That same sort of architecture then influenced the World Wide Web, which is built on top of the Internet and Tim Berners-Lee uses this model where anybody can add a website to the World Wide Web: you don’t need to ask for permission, you just add one more node to the network; there’s no plan to it, there’s no structure and so it’s a mess! It’s a sprawling, beautiful mess with no structure.
And it’s funny, because in the early days of the Web it wasn’t clear that the Web was going to win; not at all. There was competition. You had services like Compuserve and AOL. I’m not talking about AOL the website. Before it was a website, it was this thing separate to the web, which was much more structured, much safer; these were kind of the walled gardens and they would make wonderful content for you and warn you if you tried to step outside the bounds of their walled gardens into the wild, lawless lands of the World Wide Web and say, ooh, you don’t want to go out there. And yet the World Wide Web won, despite its chaoticness, its lawlessness. People chose the Web and despite all the content that Compuserve and AOL and these other walled gardens were producing, they couldn’t compete with the wild and lawless nature of the Web. People left the walled gardens and went out into the Web.
And then a few years later, everyone went back into the walled gardens. Facebook, Twitter, Medium. Very similar in a way to AOL and Compuserve: the nice, well-designed places, safe spaces not like those nasty places out in the World Wide Web and they warn you if you’re about to head out into the World Wide Web. But there’s a difference this time round: AOL and Compuserve, they were producing content for us, to keep us in the walled gardens. With the case of Facebook, Medium, Twitter, we produce the content. These are the biggest media companies in the world and they don’t produce any media. We produce the media for them.
How did this happen? How did we end up with this situation when we returned into the walled gardens? What happened?
Facebook, I used to wonder, what is the point of Facebook? I mean this in the sense that when Facebook came along, there were lots of different social networks, but they all kinda had this idea of being about a single, social object. Flickr was about the photograph and upcoming.org was about the event and Dopplr was about travel. And somebody was telling me about Facebook and saying, “You should get on Facebook.” I was like, “Oh yeah? What’s it for?” He said: “Everyone’s on it.” “Yeah, but…what’s it for? Is it photographs, events, what is it?” And he was like, “Everyone’s on it.” And now I understand that it’s absolutely correct: the reason why everyone is on Facebook is because everyone is on Facebook. It’s a direct example of Metcalfe’s Law.
Again, it’s a power-law distribution: that the value of the network is proportional to the square of the number of nodes on a network. Basically, the more people on the network the better. The first person to have a fax machine, that’s a useless lump of plastic. As soon as one more person has a fax machine, it’s exponentially more useful. Everyone is on Facebook because everyone is on Facebook. Which turns it into a hub. It is now a centralised hub, which means it is a single point of failure, by the way. In security terms, I guess you would talk about it having a large attack surface.
Let’s say you wanted to attack media outlets, I don’t know, let’s say you were trying to influence an election in the United States of America… Instead of having to target hundreds of different news outlets, you now only need to target one because it has a very large attack surface.
It’s just like, if you run WordPress as a CMS, you have to make sure to keep it patched all the time because it’s a large attack surface. It’s not that it’s any more or less secure or vulnerable than any other CMS, it’s just that it’s really popular and therefore is more likely to be attacked. Same with a hub like Facebook.
OK. Why then? Why did we choose to return to these walled gardens? Well, the answer’s actually pretty obvious, which is: they’re convenient. Walled gardens are nice to use. The user experience is pretty great; they’re well-designed, they’re nice.
The disadvantage is what you give up when you gain this convenience. You give up control. You no longer have control over the content that you publish. You don’t control who’s going to even see what you publish. Some algorithm is taking care of that. These silos—Facebook, Twitter, Medium—they now have control of the hyperlinks. Walled gardens give you convenience, but the cost is control.
This is where this idea of the indie web comes in, to try and bridge this gap that you could somehow still have the convenience of using these beautiful, well-designed walled gardens and yet still have the control of owning your own content, because let’s face it, having your own website, that’s a hassle: it’s hard work, certainly compared to just opening up Facebook, opening a Facebook account, Twitter account, Medium account and just publishing, boom. The barrier to entry is really low whereas setting up your own website, registering a domain, do you choose a CMS? There’s a lot of hassle involved in that.
But maybe we can bridge the gap. Maybe we can get both: the convenience and the control. This is the idea of the indie web. At its heart, there’s a fairly uncontroversial idea here, which is that you should have your own website. I mean, there would have been a time when that would’ve been a normal statement to make and these days, it sounds positively disruptive to even suggest that you should have your own website.
I have my own personal reasons for wanting to publish on my own website. If anybody was here back in the…six years ago, I was here at Webstock which was a great honour and I was talking about digital preservation and longevity and for me, that’s one of the reasons why I like to have the control over my own content, because these things do go away. If you published your content on, say, MySpace: I’m sorry. It’s gone. And there was a time when it was unimaginable that MySpace could be gone; it was like Facebook, you couldn’t imagine the web without it. Give it enough time. MySpace is just one example, there’s many more. I used to publish in GeoCities. Delicious; Magnolia, Pownce, Dopplr. Many, many more.
Now, I’m not saying that everything should be online for ever. What I’m saying is, it should be your choice. You should be able to choose when something stays online and you should be able to choose when something gets taken offline. The web has a real issue with things being taken offline. Linkrot is a real problem on the web, and partly that’s to do with the nature of the web, the fundamental nature of the way that linking works on the web.
When Tim Berners-Lee and Robert Cailliau were first coming up with the World Wide Web, they submitted a paper to a hypertext conference, I think it was 1991, 92, about this project they were building called the World Wide Web. The paper was rejected. Their paper was rejected by these hypertext experts who said, this system: it’ll never work, it’s terrible. One of the reasons why they rejected it was it didn’t have this idea of two-way linking. Any decent hypertext system, they said, has a concept of two-way linking where there’s knowledge of the link at both ends, so in a system that has two-way linking, if a resource happens to move, the link can move with it and the link is maintained. Now that’s not the way the web works. The web has one-way linking; you can just link to something, that’s it and the other resource has no knowledge that you’re linking to it but if that resource moves or goes away, the link is broken. You get linkrot. That’s just the way the web works.
But. There’s a little technique that if you sort of squint at it just the right way, it sort of looks like two-way linking on the web and involves a very humble bit of HTML. The rel attribute. Now, you’ve probably seen the rel attribute before, you’ve probably seen it on the link element. Rel is short for relationship, so the value of the rel attribute will describe the relationship of the linked resource, whatever’s inside the href; so I’m sure you’ve probably typed this at some point where you say rel=stylesheet on a link element. What you’re saying is, the linked resource, what’s in the href, has the relationship of being a style sheet for the current document.
link rel="stylesheet" href="..."
You can use it on A elements as well. There’s rel values like prev for previous and next, say this is the relationship of being the next document, or this is the relationship of being the previous document. Really handy for pagination of search results, for example.
a rel="prev" href="..."
a rel="next" href="..."
And then there’s this really silly value, rel=me.
a rel="me" href="..."
Now, how does that work? The linked document has a relationship of being me? Well, I use this. I use this on my own website. I have A elements that link off to my profiles on these other sites, so I’m saying, that Twitter profile over there: that’s me. And that’s me on Flickr and that’s me on GitHub.
a rel="me" href="https://twitter.com/adactio"
a rel="me" href="https://flickr.com/adactio"
a rel="me" href="https://github.com/adactio"
OK, but still, these are just regular, one-way hyperlinks I’m making. I’ve added a rel value of “me” but so what?
Well, the interesting thing is, if you go to any of those profiles, when you’re signing up, you can add your own website: that’s one of the fields. There’s a link from that profile to your own website and in that link, they also use rel=me.
a rel="me" href="https://adactio.com"
I’m linking to my profile on Twitter saying, rel=me; that’s me. And my Twitter profile is linking to my website saying, rel=me; that’s me. And so you’ve kind of got two-way linking. You’ve got this confirmed relationship, these claims have been verified. Fine, but what can you do with that?
Well, there’s a technology called RelMeAuth that uses this, kind of piggy-backs on something that all these services have in common: Twitter and Flickr and GitHub. All of these services have OAuth, authentication. Now, if I wanted to build an API, I should probably, for a right-API, I probably need to be an OAuth provider. I am not smart enough to become an OAuth provider; that sounds way too much like hard work for me. But I don’t need to because Twitter and Flickr and GitHub are already OAuth providers, so I can just piggy-back on the functionality that they provide, just be adding rel=me.
Here’s an example of this in action. There’s an authentication service called IndieAuth and I literally sign in with my URL. I type in my website name, it then finds the rel=me links, the ones that are reciprocal; I choose which one I feel like logging in with today, let’s say Twitter, I get bounced to Twitter, I have to be logged in on Twitter for this to work and then I’ve authenticated. I’ve authenticated with my own website; I’ve used OAuth without having to write OAuth, just by adding rel=me to a couple of links that were already on my site.
Why would I want to authenticate? Well, there’s another piece of technology called micropub. Now, this is definitely more complicated than just adding rel=me to a few links. This is an end-point on my website and can be an end-point on your website and it accepts POST requests, that’s all it does. And if I’ve already got authentication taken care of and now I’ve got an end-point for POST requests, I’ve basically got an API, which means I can post to my website from other places. Once that end-point exists, I can use somebody else’s website to post to my website, as long as they’ve got this micropub support. I log in with that IndieAuth flow and then I’m using somebody else’s website to post to my website. That’s pretty nice. As long as these services have micropub support, I can post from somebody else’s posting interface to my own website and choose how I want to post.
In this example there, I was using a service called Quill; it’s got a nice interface. You can do long-form writing on it. It’s got a very Medium-like interface for long-form writing because a lot of people—when you talk about why are they on Medium—it’s because the writing experience is so nice, so it’s kind of been reproduced here. This was made by a friend of mine named Aaron Parecki and he makes some other services too. He makes OwnYourGram and OwnYourSwarm, and what they are is they’re kind of translation services between Instagram and Swarm to micropub.
Instagram and Swarm do not provide micropub support but by using these services, authenticating with these services using the rel=me links, I can then post from Instagram and from Swarm to my own website, which is pretty nice. If I post something on Swarm, it then shows up on my own website. And if I post something on Instagram, it goes up on my own website. Again I’m piggy-backing. There’s all this hard work of big teams of designers and engineers building these apps, Instagram and Swarm, and I’m taking all that hard work and I’m using it to post to my own websites. It feels kind of good.
There’s an acronym for this approach, and it’s PESOS, which means you Publish Elsewhere and Syndicate to your Own Site. There’s an alternative to this approach and that’s POSSE, or you Publish on your Own Site and then you Syndicate Elsewhere, which I find preferable, but sometimes it’s not possible. For example, you can’t publish on your own site and syndicate it to Instagram; Instagram does not allow any way of posting to it except through the app. It has an API but it’s missing a very important method which is post a photograph. But you can syndicate to Medium and Flickr and Facebook and Twitter. That way, you benefit from the reach, so I’m publishing the original version on my own website and then I’m sending out copies to all these different services.
For example, I’ve got this section on my site called Notes which is for small little updates of say, oh, I don’t know, 280 characters and I’ve got the option to syndicate if I feel like it to say, Twitter or Flickr. When I post something on my own website—like this lovely picture of an amazingly good dog called Huxley—I can then choose to have that syndicated out to other places like Flickr or Facebook. The Facebook one’s kind of a cheat because I’m just using an “If This Then That” recipe to observe my site and post any time I post something. But I can syndicate to Twitter as well. The original URL is on my website and these are all copies that I’ve sent out into the world.
OK, but what about…what about when people comment or like or retweet, fave, whatever it is they’re doing, the copy? They don’t come to my website to leave a comment or a fave or a like, they’re doing it on Twitter or Flickr. Well, I get those. I get those on my website too and that’s possible because of another building block called webmention. Webmention is another end-point that you can have on your site but it’s very, very simple: it just accepts pings. It’s basically a ping tracker. Anyone remember pingback? We used to have pingbacks on blogs; and it was quite complicated because it was XML-RPC and all this stuff. This is literally just a post that goes “ping”.
Let’s say you link to something on my website; I have no way of knowing that you’ve linked to me, I have no way of knowing that you’ve effectively commented on something I’ve posted, so you send me a ping using webmention and then I can go check and see, is there really a link to this article or this post or this note on this other website and if there is: great. It’s up to me now what I do with that information. Do I display it as a comment? Do I store it to the database? Whatever I want to do.
And you don’t even have to have your own webmention end-point. There’s webmentions as a service that you can subscribe to. Webmention.io is one of those; it’s literally like an answering service for pings. You can check in at the end of the day and say, “Any pings for me today?” Like a telephone answering service but for webmentions.
And then there’s this really wonderful service, a piece of open source software called Bridgy, which acts as a bridge. Places like Twitter and Flickr and Facebook, they do not send webmentions every time someone leaves a reply, but Bridgy—once you’ve authenticated with the rel=me values—Bridgy monitors your social media accounts and when somebody replies, it’ll take that and translate it into a webmention and send it to your webmention end-point. Now, any time somebody makes a response on one of the copies of your post, you get that on your own website, which is pretty neat.
It’s up to you what you do with those webmentions. I just display them in a fairly boring manner, the replies appear as comments and I just say how many shares there were, how many likes, but this is a mix of things coming from Twitter, from Flickr, from Facebook, from anywhere where I’ve posted copies. But you could make them look nicer too. Drew McLellan has got this kind of face-pile of the user accounts of the people who are responding out there on Twitter or on Flickr or on Facebook and he displays them in a nice way.
Drew, along with Rachel Andrew, is one of the people behind Perch CMS; a nice little CMS where a lot of this technology is already built in. It has support for webmention and all these kind of things, and there’s a lot of CMSs have done this where you don’t have to invent this stuff from scratch. If you like what you see and you think, “Oh, I want to have a webmention end-point, I want to have a micropub end-point”, chances are it already exists for the CMS you’re using. If you’re using something like WordPress or Perch or Jekyll or Kirby: a lot of these CMSs already have plug-ins available for you to use.
Those are a few technologies that we can use to try and bridge that gap, to try and still get the control of owning your own content on your own website and still have the convenience of those third party services that we get to use their interfaces, that we get to have those conversations, the social effects that come with having a large network. Relatively simple building blocks: rel=me, micropub and webmention.
But they’re not the real building blocks of the indie web; they’re just technologies. Don’t get too caught up with the technologies. I think the real building blocks of the indie web can be found here in the principles of the indie web.
There’s a great page of design principles about why are we even doing this. There are principles like own your own data; focus on the user experience first; make tools for yourself and then see how you can scale them and share them with other people. But the most important design principle, I think, that’s on that list comes at the very end and it’s this: that we should 🎉 have fun (and the emoji is definitely part of the design principle).
Your website is your playground; it’s a place for you to experiment. You hear about some new technologies, you want to play with them? You might not get the chance at work but you can try out that CSS grid and the service worker or the latest JavaScript APIs you want to play with. Use your website as a playground to do that.
I also think we should remember the original motto of the World Wide Web, which was: let’s share what we know. And over the next few days, you’re going to hear a lot of amazing, inspiring ideas from amazing, inspiring people and I hope that you would be motivated to maybe share your thoughts. You could share what you know on Mark Zuckerberg’s website. You could share what you know on Ev Williams’s website. You could share what you know on Biz Stone and Jack Dorsey’s website. But I hope you’ll share what you know on your own website.
Thank you.
Here’s the talk I gave at Webstock earlier this year all about the indie web:
In these times of centralised services like Facebook, Twitter, and Medium, having your own website is downright disruptive. If you care about the longevity of your online presence, independent publishing is the way to go. But how can you get all the benefits of those third-party services while still owning your own data? By using the building blocks of the Indie Web, that’s how!
Here’s the talk I gave at Mozilla’s View Source event. I really enjoyed talking about the indie web, both from the big-picture view and the nitty gritty.
In these times of centralised services like Facebook, Twitter, and Medium, having your own website is downright disruptive. If you care about the longevity of your online presence, independent publishing is the way to go. But how can you get all the benefits of those third-party services while still owning your own data? By using the building blocks of the Indie Web, that’s how!
Excellent presentation slides on all things Indie Web.
I was idly thinking about the different ways I can post to adactio.com. I decided to count the ways.
This is the classic CMS approach. In my case the CMS is a crufty hand-rolled affair using PHP and MySQL that I wrote years ago. I log in to an admin interface and fill in a form, putting the text of my posts into a textarea. In truth, I usually write in a desktop text editor first, and then paste that into the textarea. That’s what I’m doing now—copying and pasting Markdown from the Typed app.
If I’m logged in, I get a stripped down posting interface in the notes section of my site.
This is how I post links. When I’m at a URL I want to bookmark, I hit the “Bookmark it” bookmarklet in my browser’s bookmarks bar. That pops open a version of the admin interface tailored specifically for links. I really, really like bookmarklets. The one big downside is that they don’t work on mobile.
This is something I knocked together at Indie Web Camp Brighton 2015 using the Twilio API. It’s handy for posting notes if I’m travelling somewhere and data is at a premium. But I don’t use it that often.
Thanks to Aaron’s OwnYourGram service—and the fact that my site has a micropub endpoint—I can post images from Instagram to my site. This used to happen instantaneously but Instagram changed their API rules for the worse. Between that and their shitty “algorithmic” timeline, I find myself using the service less and less. At this point I’m only on their for the doggos.
Like OwnYourGram, Aaron’s OwnYourSwarm allows me to post check-ins and photos from the Swarm app to my site. Again, micropub makes it all possible.
OwnYourGram and OwnYourSwarm are very similar and could probably be abstracted into a generic service for posting from third-party apps to micropub endpoints. I’d quite like to post my check-ins on Untappd to my site.
Thanks to rel="me" and IndieAuth, I can log into other people’s posting interfaces using my own website as the log-in, and post to my micropub endpoint, like this. Quill is a good example of this. I don’t use it that much, but I really should—the editor interface is quite Medium-like in its design.
Anyway, those are the different ways I can update my website that I can think of right now.
In terms of output, I’ve got a few different ways of syndicating what I post here:
Just so you know, if you comment on one of my posts on Facebook, I probably won’t see it. But if you reply to a copy of one of posts on Twitter or Instagram, it will show up over here on adactio.com thanks to the magic of Brid.gy and webmention.
I was just talking about micropub …and now it’s officially a W3C spec. Great work!
If you’re building a blogging platform, you can allow your users choose from a wide variety of posting clients by implementing the Micropub spec.
If you’re building a posting client and want it to work with many different server backends instead of hard-coding it to Twitter or other proprietary APIs, implement the Micropub spec and you’ll quickly have people eager to start using the app!
The opening keynote from the inaugural HTML Special held before CSS Day 2016 in Amsterdam.
The world exploded into a whirling network of kinships, where everything pointed to everything else, everything explained everything else.
Apophenia is the name for that tendency in humans to see patterns where none exist, to draw connections, to make links.
Every conspiracy theory is an example of apophenia. But you don’t have to be a conspiracy theorist to experience it. We do it all the time. We see shapes in the constellations in the night sky. We see faces in just about everything.
Today, I would like to engage the apopheniac in you.
An anchor is an odd device to represent a link. I can even remember seeing anchor symbols used in the interfaces of rich text editors. If it wasn’t an anchor, it was a chain. I suppose that was meant to represent a link …because chains have links.
Anyway, why A? Why Anchor?
It goes back to how the A element was originally used. When I say originally, I mean originally. Let’s look at the first A element in the first web page at the first URL.
<A NAME=0 HREF="WhatIs.html">
hypermedia
</A>
This looks pretty familiar to us today. There’s an A Element with opening and closing tags, some text in between, and an HREF attribute for the destination. But there’s also a NAME attribute. This has since been deprecated—now we can just use an ID attribute on any element. The idea was that A elements could be used to create destinations for inbound links. They were, if you like, anchors within a page that other pages could tether themselves to. Each anchor is given a unique identifier (unique within the page, that is). Here, the identifier is simply the number zero, because this page was created by a programmer and in the mind of a programmer, counting begins with zero.
This use of the A element—using NAME attributes to create in-page anchors—never really took off. But the other attribute, the HREF attribute, that spread like wildfire. It’s short for hypertext reference, and in this particular instance, the reference is to another page in the same directory on the same server. It’s a page about hypertext.
Hypertext is text which is not constrained to be linear.
The term was first coined by Ted Nelson. He didn’t just talk about text either. He also coined the term hypermedia. He coined lots of interesting words. He talked about things being deeply intertwingled. He also coined the term teledildonics, but that is not directly relevant to hypertext or hypermedia.
If hypertext is text which is not constrained to be linear, how did we ever manage with good old-fashioned non-hyper text and non-hyper media? We used archives.
In 1965, JCR Licklider was commissioned to write a report on Libraries Of The Future. He—and his company Bolt, Beranek and Newman—would prove to be instrumental in creating our modern interconnected hypermedia world. More on that later. For now, let’s look at this report. It has two parts:
I love the scope of that first part, looking at the body of recorded knowledge.
It’s interesting that he talks about knowledge, not information, not data, but knowledge. How does data become information? How does information become knowledge?
The Library Of Babel is a short story by Jorge Luis Borges, who I think of as the poet laureate of hypertext . He imagines a vast library that is filled with data, but frustratingly short on knowledge …because this library contains not only all the books ever written, but all the books that could ever possibly be written, with every possible permutation.
Here’s how it works:
The universe (which others call the Library) is composed of an indefinite, perhaps infinite number of hexagonal galleries… The arrangement of the galleries is always the same: Twenty bookshelves, five to each side, line four of the hexagon’s six sides… each bookshelf holds thirty-two books identical in format; each book contains four hundred ten pages; each page, forty lines; each line, approximately eighty black letters.
Let’s figure out how many books are in the Library of Babel. First, we need to know how much data each book holds.
Multiplying 80 by 40 gives us 3200, the number of symbols on each page. Multiply that by 410 and we get a total number of 1,312,000 symbols in each book.
We have two other pieces of information to work with. Borges tells us:
The orthographic symbols are twenty-five in number.
That’s 22 letters, the comma, the period, and the space.
Here’s the crucial bit of information that ensures that the library has boundaries:
In the vast library there are no two identical books.
Knowing that, we can calculate the number of books in the library. It’s the number of symbols (25) raised to the power of the number of symbols in each book (1,312,000).
25 to the power of 1,312,000 expressed in base ten is 10 to the power of 1,834,097. Remember that’s just the number of books: a figure that’s over 1,834,097 digits long. That number wouldn’t fit inside one book in the library (which, if you remember only holds 1,312,000 symbols).
So the number of books in the Library of Babel is not infinite …but it is really, really, really big. To give you some idea of just how big 10 to the power of 1,834,097 is, it has been calculated that the observable universe contains approximately 10 to the power of 80 atoms. There are more books in the Library of Babel than there are atoms in the universe.
And yet, thanks to the World Wide Web, you can theoretically peruse every single one of them.
Jonathan Basile has created libraryofbabel.info—an online representation of Borges’s creation. It contains all possible text. You can browse by hexagon, then shelf, then row, then book, then page. Or you can search for a specific piece of text, because—of course—that text must be in there somewhere.
The very words I am speaking now must be somewhere in the library.
There’s also a plug-in for Chrome so you can highlight any piece of text on the web, and then find its corresponding page in the Library of Babel.
This library has every possible piece of data …but it’s sorely lacking in information (although the online version helps).
Having all the data isn’t enough. It needs to be organised—turned into information—for us to make use of it (and hopefully further transform that information into knowledge).
There have been many attempts to organise information. When those attempts are limited to a subset of data—instead of trying to create a Library of Babel—then they can be quite successful.
Carl Linnaeus organised the natural world using a naming convention for describing species—binomial nomenclature.
Charles Messier catalogued astronomical objects.
Melvil Dewey created the Dewey Decimal System to help librarians organise their collections. But this was a proprietary system, not an open standard. So the Belgian librarian Paul Otlet devised a Universal Decimal Classification system. I think it’s fair to think of him as the father of information architecture.
The crazy old uncle of information architecture would be bishop John Wilkins, who in 1668 wrote An Essay towards a Real Character and a Philosophical Language. Centuries later, this would pique the interest of Borges who described Wilkins’s madcap idea in an essay called The Analytical Language of John Wilkins. The idea was that the world could be classified into sounds.
He divided the universe in forty categories or classes, these being further subdivided into differences, which was then subdivided into species. He assigned to each class a monosyllable of two letters; to each difference, a consonant; to each species, a vowel. For example: de, which means an element; deb, the first of the elements, fire; deba, a part of the element fire, a flame.
It didn’t scale well.
Gottfried Wilhelm Leibniz—inventor of calculus and nemesis to Newton—had a similar idea to Wilkins, but whereas Wilkins was trying to classify information using sounds, Leibniz wanted to use symbols: characteristica universalis. His leap of genius was to realise that if you could do this—represent the world with symbols—then you could perform calculations on those symbols. He described the conceptual framework for performing such operations as a Calculus ratiocinator. Centuries later, Norbert Wiener, the creator of cybernetics would say:
The general idea of a computing machine is nothing but a mechanization of Leibniz’s calculus ratiocinator.
Leibniz’s calculus ratiocinator was an idea, rather than a real machine. Charles Babbage was a Victorian inventor and entrepreneur who was given seed funding by the British government to create his Difference Engine: a machine for computing logarithmic tables …a computer, if you will.
The Wozniak to Babbage’s Jobs was Ada Lovelace, the daughter of the notorious Lord Byron. Ada’s mother did everything in her power to steer her daughter away from following in her father’s footsteps of becoming a poet. Instead Ada immersed herself in the world of mathematics. It was through mathematics that Ada hit upon the same insight as Leibniz—if we can perform calculations upon symbols, and those symbols don’t have to just represent numbers, then we can perform calculations on anything …maybe even poetry.
In enabling mechanism to combine together general symbols in successions of unlimited variety and extent, a uniting link is established between the operations of matter and the abstract mental processes of the most abstract branch of mathematical science.
The Difference Engine was abandoned in favour of an even more ambitious project: The Analytical Engine. Finally, the world would get a mechanical machine capable of performing calculations on symbols that could represent concepts or thoughts—a thinking machine!
As with so many start-ups, Lovelace and Babbage never quite managed to make it to market. But at least they did genuinely have an incredible journey before going broke.
The Analytical Engine, like the calculus ratiocinator, remained an idea. It would be another century before we’d get a real nuts’n’bolts computing machine, thanks to the brilliant Alan Turing.
But as well as having a hand in creating the world’s first physical computer, he also presented us with an imaginary machine. This theoretical machine was described as having:
…an infinite tape marked out into squares, on each of which a symbol could be printed.
Like Leibniz’s calculus ratiocinator, a Turing machine would operate on symbols. How many symbols are we talking about here? Remember the Library Of Babel had twenty five symbols to work with.
Two. Two symbols. One and zero. On and off. True and false. With an infinitely long piece of tape and infinite amount of time, two symbols are enough to calculate literally anything.
This reduction of the world into its smallest pieces was the brainchild of Claude Shannon. He coined the term "bit" to describe this indivisible unit of information.
By the way, Turing himself referred to his theoretical machine as an automatic machine, or a-machine. A is for A-machine.
There’s another imaginary machine that serves as a wonderful conceptual prototype for working with hypertext and hypermedia. In 1945 Vannevar Bush published an article in the Atlantic Monthly called As We May Think. In this article, Bush describes a machine called the Memex, a contraction of Memory Index.
The Memex is built into a desk. Screens and switches on the surface of the desk allow the user to interact with huge amounts of information stored within the desk on microfilm. This would provide an "enlarged intimate supplement to one’s memory."
Because everyone’s mind is different, no two people would use the Memex in quite the same way. Bush described these individualistic approaches to linking concepts together as associative trails:
Wholly new forms of encyclopedias will appear, ready made with a mesh of associative trails running through them, ready to be dropped into the memex and there amplified.
The information stored in the Memex is the same for everyone, but the associative trails created by the user in navigating this information are unique. Bush also proposed that these associative trails could be shared. Users of the Memex could follow the breadcrumbs left by others.
This is hypertext.
So many ideas about hypertext confined to the imagination! When do we get a working demo?
Ladies and gentlemen, on December 9th, 1968, we get the mother of all demos, courtesy of Douglas Engelbart. Six years previously, he had set out his goals for human-computer interaction in a work entitled Augmenting Human Intellect: A Conceptual Framework. To achieve this aim of augmenting humanity, he created a working demo of his oNLine System, abbreviated to NLS.
Oh, and for this demo he just happened to invent video conferencing, the graphical user interface, and the mouse. He also implemented hypertext.
With Bush’s Memex and Engelbart’s NLS, concepts could be linked together, turning them from text storage devices to hypertext storage devices. But for hypertext to reveal its true power, we need a network greater than anything seen up to this point. Towards the end of the mother of all demos, we hear the first rumblings of just such a network.
ARPA stands for the Advanced Research Projects Agency.
This government agency turned to our old friend JCR Licklider, author of Libraries Of The Future. His company—Bolt, Beranek and Newman—set about designing a communications system that used this new-fangled packet switching that Leonard Kleinrock was so excited about. With packet switching, information was broken down into discrete chunks, routed around a network independent of each other, and then re-assembled at the destination.
At the same time, this idea of packet switching was independently discovered by Paul Baran at the Rand Corporation, who was trying to find a resilient network architecture capable of surviving nuclear attack.
The packet-switching idea was put to the test with the creation of a new network called the ARPANET. The very first message sent over the ARPANET was at 10:30pm on October, 29th, 1969. It was the command: LOG IN.
The message was sent and… the system crashed after the first two characters. Fittingly, then, the real first message sent over this proto-internet was "LO".
But they fixed the bugs and they kept working on making the system better as it grew bigger. It morphed from being a single network, the ARPANET, into being a network of networks, or an Inter-network, soon shortened to simply Internet.
For this internet to work, it was essential that all the individual networks connecting to it were using the same protocols to communicate. That’s what really makes the internet the internet—regardless of what kind of hardware is being used, there’s an agreement on how to switch those packets around. That’s really all a protocol is: an agreement. They’re more like treaties than code.
Bob Kahn and Vint Cerf were the statesmen crafting the internet’s protocols, and Jon Postel was the diplomat ensuring adoption went smoothly. They wanted a robust network, resilient not to nuclear attack, but to any kind of top-down control. They set out to create a protocol that would work for a network with no centre.
Together they crafted TCP/IP: the Transmission Control Protocol and Internet Protocol. TCP/IP is a deliberately dumb set of protocols. The protocols care not a whit for the contents of the packets being switched around the network. It’s a simple low-level agreement. They used to joke that you should be able to implement TCP/IP using two tin cans and a piece of string.
You can then create more complex protocols on top of this simple, low-level, dumb foundation. You can create protocols for sending and receiving email, protocols for telnet, gopher, file transfer protocols that sit atop TCP/IP. Best of all, you don’t need to ask anyone for permission. If you want to create a new protocol today, you can just go ahead and do it. All you need is rough consensus and running code. It turns out that running code isn’t the hard part. The hard part is convincing people to use your protocol. Otherwise you don’t benefit from Metcalfe’s Law:
The value of a network is proportional to the square of the number of connected users of the system.
Think about it. The first person to own a telephone had a completely useless object. As soon as one other person had a telephone, it suddenly become exponentially more useful. That was the challenge facing the creator of a new protocol at the start of the 90s: that protocol was HTTP—the HyperText Transfer Protocol.
HTTP is one part of a three-part stack: HTTP is the protocol, URLs are the identifiers, and HTML is the format. Together they form the World Wide Web project.
The project was the brainchild of a young computer scientist named Tim Berners-Lee. This wasn’t his first attempt at creating a hypertext system.
In the 1980s, he created a system called ENQUIRE. It was named after a Victorian book of manners called Enquire Within Upon Everything, which I always thought would be a great name for the web.
Enquire didn’t work out in the end, but it would influence the design of the World Wide Web project.
Another influence on the design of the system was the place where Tim Berners-Lee was working. CERN—the European Centre for Nuclear Research. It’s an amazing place. The greatest experiment in the history of our species is being conducted beneath the border between Switzerland and France. In the 16-mile wide ring of the Large Hadron Collider at CERN, human beings are recreating the conditions from the start of our universe. Protons are smashed together at velocities approaching the speed of light. It’s a truly awe-inspiring endeavour.
When I visited CERN, I expected to be blown away by the science, and I was. I also expected to be blown away by simply being at the birthplace of the web, and I was. But what I wasn’t expecting was to be blown away by how things get done at CERN. There is very little hierarchy. People from all kinds of backgrounds—from Nobel prize winning physicists to students on a Summer internship—collaborate on experiments for pure scientific research.
Trying to manage the flow of information in this collaborative but chaotic place was the challenge that Tim Berners-Lee was trying to solve. You can’t just mandate a particular operating system or piece of software—people at CERN can and will use whatever they want. In the same way that the internet is a network of networks, what CERN needed was some way of allowing all these different computers with different operating systems to share information with each other.
Tim Berners-Lee submitted a paper to his supervisor, Mike Sendall. It had the uninspiring title Information Management: A Proposal. Well, Mike Sendall must have seen some potential, because he scrawled across the top:
Vague, but exciting.
The proposal described:
…a solution based on a distributed hypertext system.
Tim Berners-Lee was very familiar with previous hypertext systems. All of these fed into his project:
But just creating the code wasn’t enough. He—and his colleague and collaborator, Robert Cailliau—needed to convince the scientists at CERN to use this technology. To start with, they needed a catchy name.
For a while, they floated the idea of calling it the Mesh.
Then they kick around the idea of calling it The Information Mine. But Tim Berners-Lee wasn’t keen on this one. He knew that, whatever name they chose, it would end up getting abbreviated, and he was worried it would look a bit egotistical.
And so they settled on World Wide Web. You have to admire the chutzpah of calling it World Wide Web when, at that point, it only existed on one person’s computer.
Sure enough, it did end up getting abbreviated. Except in this case, there are actually more syllables in the so-called abbreviation—WWW—than there are in the full name.
They even made a logo. Graphic designers they are not. But there is a reason for the green colour of the Ws. Robert Cailliau is a synesthesiac—he “hears” the W sound as the colour green.
And so the web was born. Good job!
Learning from the lessons of TCP/IP, Tim Berners-Lee made sure to keep the individual parts of the system as simple as possible (but no simpler). The World Wide Web didn’t succeed because the technology was the best; far from it. It succeeded because the technology was just simple enough—but also powerful enough—for people to get started with straight away.
Take HTML, for example. There was no official Version 1 specification for this hypertext markup language.
Instead there was a document called simply HTML Tags, presumably written by Tim Berners-Lee. This document listed the entirety of HTML, which was a grand total of 21 elements.
Most of those elements weren’t even invented by Tim Berners-Lee. Instead, he borrowed the vocabulary already being used by scientists at CERN. They were used to writing documents in GML, which is supposed to stand for Generalised Markup Language, but was coincidentally created by three people whose last names were Goldfarb, Mosher, and Lorie: G, M, and L.
There was one element that was completely new to HTML:
A
This one single element is what enables the HT part of HTML. With this element, and its href attribute, anyone could link to anything on the web. It is brilliant in its simplicity.
Pleased with the way their project was progressing, Tim Berners-Lee and Robert Cailliau submitted a proposal to present their World Wide Web at a hypertext conference.
They were rejected. Hypertext experts thought the World Wide Web was stupid.
As Ted Nelson put it:
Today’s one-way hypertext—the World Wide Web—is far too shallow. The Xanadu project foresaw world-wide hypertext decades ago, and endeavored to create a much deeper system. The Web, however, took over with a very shallow structure.
He’s not wrong. Hypertext on the web is shallow. It is stupid. Like TCP/IP, it is not smart.
The thing is, if you’re hoping to get mass adoption, being smart is a bug. Being stupid is a feature.
Just about every other hypertext system embodied the idea of two-way linking. There was an awareness at both ends of the link. If the resource being linked to were to move or change, the link could be updated. It’s robust, but it’s complicated.
On the World Wide Web, by contrast, links only work in one direction. If the resource being linked to ends up moving or changing, well, tough luck. The result is link rot. That’s the price we pay for a very simple hypertext system.
But, now that the web has been around a couple of decades, there is a sort-of, kind-of implementation of two-way linking.
It uses the humble rel attribute.
Rel is short for relationship. The value inside the rel attribute describes the relationship of the linked resource to the current document.
<a href="…" rel="…">
Some rel values were officially canonised in HTML.
rel="prev" means that the linked resource has the relationship of being the previous document to the current document.
<a href="…" rel="prev">
rel="next" means that the linked resource has the relationship of being the next document after the current document.
<a href="…" rel="next">
rel="author" means that the linked resource has the relationship of representing the author of the current document.
<a href="…" rel="author">
You get the idea.
Incidentally, there was once a corresponding rev attribute that described the reverse relationship. In other words, the relationship of the current document to the linked resource.
<a href="…" rev="…">
So you could simultaneously say the current document has a relationship of being the previous document to the linked resource and that the linked resource has a relationship of being the next document to the current document.
<a href="…" rev="prev" rel="next">
Confused? Well, that’s why the rev attribute was eventually dropped from HTML. It was just too complicated.
There was an attempt to use the rev attribute in an early microformat called vote-links. This was proposed way back in 2004. Blogs were hot. Political blogs were very hot indeed: Bush Jr.—no relation to Vannevar—was running for re-election in the States, and John Kerry was the challenger. There was much blogging and gnashing of teeth.
The problem was the rise of PageRank, the algorithm that drove Google’s search engine. The fundamental premise of PageRank was that linking to something counts as an endorsement. But there were many bloggers linking to articles that they disagreed with very strongly.
By using a rev value of “vote-for”, authors could explicitly say that this document is a vote for the resource being linked to.
Or by using a rev value of “vote-against” they could make it clear that this document is a vote against the linked resource.
It never really took off because, as I said, the rev attribute was just too hard to grok.
And that’s okay. The whole point of microformats is that they are the very embodiment of the motto of the Internet Engineering Task Force: rough consensus and running code. There just wasn’t enough take-up of vote-links for it to thrive.
Another early idea—that actually preceded the official creation of microformats—was XFN, which stood for XHTML Friends Network: the most Web 1.0 format name ever.
XFN built on existing behaviour. Bloggers would often have a list of links in their sidebar pointing to other bloggers they had some kind of relationship with. If you assume that a URL can represent a person, then the rel attribute is perfect for encoding that relationship information.
I can link to a friend’s website and say that the person represented by the linked resource has a relationship of being a friend to the person represented by the current document: me!
<a href="…" rel="friend">
Or I can link to a colleague’s website and say that they have a relationship of being a colleague to me.
<a href="…" rel="colleague">
And because rel values—like class values—can be space-separated, I can combine rel values into one attribute. I can link to someone and say that they are both a friend and a colleague.
<a href="…" rel="friend colleague">
I still have XFN values in the sidebar of my blog, but again, it never really took off.
Except for one value, that seems at first glance to be completely pointless:
A rel value of "me": the linked resource has a relationship of being …me?
<a href="…" rel="me">
My website is adactio.com. I love my website. Even though it isn’t a physical thing, I think it might be my most prized possession.
It’s a place for me to think and a place for me to link.
But my web presence isn’t limited to adactio.com—I have profiles on lots of different sites: Twitter, Facebook, Instagram, Medium, Dribbble, Flickr, Tumblr, CodePen …the list goes on.
None of those places are as important to me as my own website, but they are representations of me.
I link out to these profiles from my own website using that rel value of "me". That’s me on Twitter. That’s me on Github. That’s me on Flickr.
<a rel="me" href="https://twitter.com/adactio">
<a rel="me" href="https://github.com/adactio">
<a rel="me" href="https://flickr.com/adactio">
Nothing unusual there. These are regular one-way hyperlinks.
What’s interesting is that many of those profiles on other websites provide a URL field where I can enter my own website. These third-party profiles then link back to my website also using a rel value of "me".
<a rel="me nofollow" href="https://adactio.com">
(They also use a rel value of "nofollow" to discourage spammers. The phrase "nofollow" makes absolutely no sense as a rel value—you can’t have a relationship of "nofollow" to anything—but it was invented by Google. We don’t get to argue with the 900 pound Google gorilla.)
Anyway, the result of having these reciprocal links, both using rel="me" means that we’ve kinda, sorta got two-way linking on the World Wide Web.
But …so what?
Some of those third-party profiles I’m linking to—Twitter, Github, Flickr—have something in common. They allow third-party authentication using OAuth.
If I can log into my Twitter, or Github, or Flickr profile using OAuth, and those profiles have two-way links with my website, then I can “borrow” that authentication flow for my own site.
That’s the idea behind IndieAuth. I enter the URL of my own website. It finds the links from there to my other profiles using rel="me". Then I can choose which one of those profiles I want to authenticate against. Once I’ve authenticated with that service, I’ve also authenticated my own website.
Just by adding a short rel value to some links, I can use my website as a log-in.
My website also has a small write API. The API is called micropub. By combining IndieAuth and micropub, I can log into somebody else’s posting interface using my website, and then use that interface to post to my own website.
These building blocks—microformats, IndieAuth, micropub—have emerged from a small but dedicated group of people.
We gather together at fun little events called Indie Web Camps.
An Indie Web Camp takes place over two days. The first day is split into discussions of technology and design. The second is all about implementing what we’ve discussed on the first day. I’m always amazed by how much gets done when you’re in the same space as like-minded people.
Still, the technologies being discussed and implemented aren’t the real focus of Indie Web Camp. The core tenet of Indie Web Camp is an idea. It’s a very simple idea, that at one point would have been uncontroversial. That idea is that you should have your own website.
But who’s got time for that? Especially when it’s so much easier to write and share and link using platforms like Twitter, Facebook, and Medium. That’s a good point. A lot of the time at an Indie Web Camp is spent reverse-engineering what those services are doing so well, and applying them to personal websites.
Also, we don’t necessarily want to stop using those services. After all, that’s where the people are (for now). Instead we want to figure out ways of making use of these services, while still keeping the canonical versions of what we create under our own control.
There’s a fantastic little Indie Web service called Brid.gy that allows you to not only post from your own site out to third party networks, but also receive replies, and likes, and retweets back at your own site, using another Indie Web building block called webmention.
In a way, webmentions allow a kind of two-way linking. I can cross-post something from adactio.com to Twitter, or Instagram, or Facebook. Then when someone replies on Twitter, or Instagram, or Facebook, I get notified with a ping back to my own site.
All of this is possible because I’ve verified the identity of those third-party profiles using nothing more than a simple rel attribute on a hyperlink.
The Indie Web uses a grab-bag of deliberately simple technologies that combine to create something so much more powerful than the sum of its parts …just like the web itself.
We often talk about places like Facebook, or Instagram, or Medium as walled gardens. Walled gardens are as old as the web itself. AOL was a well-cultivated walled garden back in the day.
There’s nothing wrong with walled gardens. They’re safe spaces. They take care of your enjoyment and entertainment, so you don’t have to.
But there also a bit boring. I certainly don’t relish the idea of spending my days within the boundaries of someone else’s vision.
There’s a different kind of garden. It takes its name from another short story by Borges.
The Garden of Forking Paths. It is uncontrolled. It is full of possibilities. It’s a bit scary. It takes more dedication to explore. You might get lost. But is that so bad? When was the last time you were truly lost on the World Wide Web, when you clicked through link after link—no cheating by opening new tabs, now—until you ended up somewhere, blinking and asking yourself “what I was looking for?”
I would like us all to spend more time in the garden of forking paths. I would like us all to continue to grow this garden of forking paths. Add your own website to this garden of forking paths. Use it to make more links.
On your website, you can link to this thing over here and that thing over there, and in doing so create an entirely new forking path.
Remember, the web, like the internet, has no centre. In theory I could start from any single A element, and by following all the forking paths, traverse the entire World Wide Web.
That opening hyperlink could be on your own website. One single A element can be the portal to an entire universe of knowledge.
The slides from Aaron’s talk at OS Bridge in Portland, looking at the formats and protocols powering the indie web.
I was back in Nürnberg last week for the second border:none. Joschi tried an interesting format for this year’s event. The first day was a small conference-like gathering with an interesting mix of speakers, but the second day was much more collaborative, with people working together in “creator units”—part workshop, part round-table discussion.
I teamed up with Aaron to lead the session on all things indie web. It turned out to be a lot of fun. Throughout the day, we introduced the little building blocks, one by one. By the end of the day, it was amazing to see how much progress people made by taking this layered approach of small pieces, loosely stacked.
The first step is: do you have a domain name?
Okay, next step: are you linking from that domain to other profiles of you on the web? Twitter, Instagram, Github, Dribbble, whatever. If so, here’s the first bit of hands-on work: add rel="me" to those links.
<a rel="me" href="https://twitter.com/adactio">Twitter</a>
<a rel="me" href="https://github.com/adactio">Github</a>
<a rel="me" href="https://www.flickr.com/people/adactio">Flickr</a>
If you don’t have any profiles on other sites, you can still mark up your telephone number or email address with rel="me". You might want to do this in a link element in the head of your HTML.
<link rel="me" href="mailto:jeremy@adactio.com" />
<link rel="me" href="sms:+447792069292" />
As soon as you’ve done that, you can make use of IndieAuth. This is a technique that demonstrates a recurring theme in indie web building blocks: take advantage of the strengths of existing third-party sites. In this case, IndieAuth piggybacks on top of the fact that many third-party sites have some kind of authentication mechanism, usually through OAuth. The fact that you’re “claiming” a profile on a third-party site using rel="me"—and the third-party profile in turn links back to your site—means that we can use all the smart work that went into their authentication flow.
You can see IndieAuth in action by logging into the Indie Web Camp wiki. It’s pretty nifty.
If you’ve used rel="me" to link to a profile on something like Twitter, Github, or Flickr, you can authenticate with their OAuth flow. If you’ve used rel="me" for your email address or phone number, you can authenticate by email or SMS.
Next question: are you publishing stuff on your site? If so, mark it up using h-entry. This involves adding a few classes to your existing markup.
<article class="h-entry">
<div class="e-content">
<p>Having fun with @aaronpk, helping @border_none attendees mark up their sites with rel="me" links, h-entry classes, and webmention endpoints.</p>
</div>
<time class="dt-published" datetime="2014-10-18 08:42:37">8:42am</time>
</article>
Now, the reason for doing this isn’t for some theoretical benefit from search engines, or browsers, but simply to make the content you’re publishing machine-parsable (which will come in handy in the next steps).
Aaron published a note on his website, inviting everyone to leave a comment. The trick is though, to leave a comment on Aaron’s site, you need to publish it on your own site.
Here’s my response to Aaron’s post. As well as being published on my own site, it also shows up on Aaron’s. That’s because I sent a webmention to Aaron.
Webmention is basically a reimplementation of pingback, but without any of the XML silliness; it’s just a POST request with two values—the URL of the origin post, and the URL of the response.
My site doesn’t automatically send webmentions to any links I reference in my posts—I should really fix that—but that’s okay; Aaron—like me—has a form under each of his posts where you can paste in the URL of your response.
This is where those h-entry classes come in. If your post is marked up with h-entry, then it can be parsed to figure out which bit of your post is the body, which bit is the author, and so on. If your response isn’t marked up as h-entry, Aaron just displays a link back to your post. But if it is marked up in h-entry, Aaron can show the whole post on his site.
Okay. By this point, we’ve already come really far, and all people had to do was edit their HTML to add some rel attributes and class values.
For true site-to-site communication, you’ll need to have a webmention endpoint. That’s a bit trickier to add to your own site; it requires some programming. Here’s my minimum viable webmention that I wrote in PHP. But there are plenty of existing implentations you can use, like this webmention plug-in for WordPress.
Or you could request an account on webmention.io, which is basically webmention-as-a-service. Handy!
Once you have a webmention endpoint, you can point to it from the head of your HTML using a link element:
<link rel="mention" href="https://adactio.com/webmention" />
Now you can receive responses to your posts.
Here’s the really cool bit: if you sign up for Bridgy, you can start receiving responses from third-party sites like Twitter, Facebook, etc. Bridgy just needs to know who you are on those networks, looks at your website, and figures everything out from there. And it automatically turns the responses from those networks into h-entry. It feels like magic!
Here are responses from Twitter to my posts, as captured by Bridgy.
That was mostly what Aaron and I covered in our one-day introduction to the indie web. I think that’s pretty good going.
The next step would be implementing the idea of POSSE: Publish on your Own Site, Syndicate Elsewhere.
You could do this using something as simple as If This, Then That e.g. everytime something crops up in your RSS feed, post it to Twitter, or Facebook, or both. If you don’t have an RSS feed, don’t worry: because you’re already marking your HTML up in h-entry, it can be converted to RSS easily.
I’m doing my own POSSEing to Twitter, which I’ve written about already. Since then, I’ve also started publishing photos here, which I sometimes POSSE to Twitter, and always POSSE to Flickr. Here’s my code for posting to Flickr.
I’d really like to POSSE my photos to Instagram, but that’s impossible. Instagram is a data roach-motel. The API provides no method for posting photos. The only way to post a picture to Instagram is with the Instagram app.
My only option is to do the opposite of POSSEing, which is PESOS: Publish Elsewhere, and Syndicate to your Own Site. To do that, I need to have an endpoint on my own site that can receive posts.
Working side by side with Aaron at border:none inspired me to finally implement one more indie web building block I needed: micropub.
Having a micropub endpoint here on my own site means that I can publish from third-party sites …or even from native apps. The reason why I didn’t have one already was that I thought it would be really complicated to implement. But it turns out that, once again, the trick is to let other services do all the hard work.
First of all, I need to have something to manage authentication. Well, I already have that with IndieAuth. I got that for free just by adding rel="me" to my links to other profiles. So now I can declare indieauth.com as my authorization endpoint in the head of my HTML:
<link rel="authorization_endpoint" href="https://indieauth.com/auth" />
Now I need some way of creating and issuing authentation tokens. See what I mean about it sounding like hard work? Creating a token endpoint seems complicated.
But once again, someone else has done the hard work so I don’t have to. Tokens-as-a-service:
<link rel="token_endpoint" href="https://tokens.indieauth.com/token" />
The last piece of the puzzle is to point to my own micropub endpoint:
<link rel="micropub" href="https://adactio.com/micropub" />
That URL is where I will receive posts from third-party sites and apps (sent through a POST request with an access token in the header). It’s up to me to verify that the post is authenticated properly with a valid access token. Here’s the PHP code I’m using.
It wasn’t nearly as complicated as I thought it would be. By the time a post and a token hits the micropub endpoint, most of the hard work has already been done (authenticating, issuing a token, etc.). But there are still a few steps that I have to do:
I tested my micropub endpoint using Quill, a nice little posting interface that Aaron built. It comes with great documentation, including a guide to creating a micropub endpoint.
It worked.
Here’s another example: Ben Roberts has a posting interface that publishes to micropub, which means I can authenticate myself and post to my site from his interface.
Finally, there’s OwnYourGram, a service that monitors your Instagram account and posts to your micropub endpoint whenever there’s a new photo.
That worked too. And I can also hook up Bridgy to my Instagram account so that any activity on my Instagram photos also gets sent to my webmention endpoint.
Each one of these building blocks unlocks greater and greater power:
Each one of those building blocks you implement unlocks more and more powerful tools:
But its worth remembering that these are just implementation details. What really matters is that you’re publishing your stuff on your website. If you want to use different formats and protocols to do that, that’s absolutely fine. The whole point is that this is the independent web—you can do whatever you please on your own website.
Still, if you decide to start using these tools and technologies, you’ll get the benefit of all the other people who are working on this stuff. If you have the chance to attend an Indie Web Camp, you should definitely take it: I’m always amazed by how much is accomplished in one weekend.
Some people have started referring to the indie web movement. I understand where they’re coming from; it certainly looks like a “movement” from the outside, and if you attend an Indie Web Camp, there’s a great spirit of sharing. But my underlying motivations are entirely selfish. In the same way that I don’t really care about particular formats or protocols, I don’t really care about being part of any kind of “movement.” I care about my website.
As it happens, my selfish motivations align perfectly with the principles of an indie web.