Here’s something on the order in which I, sometimes partially, implemented different IndieWeb concepts on this site. I’m planning to add and rewrite, I dont know, something, so I’m not yet publicly publicly publishing it. I’m like that sometimes.
Webmentions are like pingbacks, minus the downsides.
Seriously, the Webmention protocol’s a lot like Pingback. Wikipedia kind of nails it, when it states “Webmention [is] a modern re-implementation of [Pingback] using HTTP and x-www-urlencoded POST data.”
You mention someone else’s blog post in yours, they get pinged, and subsequently choose to show a message on their site—link back to your post, perhaps—or do nothing at all.
Use microformats, too? Then they’ll probably also be able to figure out if you merely mentioned said post’s URL, or explicitly replied to or bookmarked it, or did something else, still.
Wanna port social media likes and replies to your site, too? Well, you can, but only because of Bridgy, a service that translates interactions on Twitter and other social media silos into webmentions.
(Webmention is so much more than just displaying likes on your own site. Not that there’s anything wrong with that.)
Again, you’re in total control of what happens with incoming webmentions. You don’t have to send webmentions, either, if you don’t feel like it.
I started with incoming webmentions. Sent one from one of my blogs to another. Then enabled Bridgy.
Microformats turn your HTML into an API.
By adding a few, semantic class names to your HTML—or having your CMS do so—microformats (and, more specifically, h-entry and h-feed) parsers are able to more meaningfully interpret posts (and lists of posts).
HTML feed readers are one example of such parsers, and work very much like traditional RSS readers. Except that, instead of RSS (an XML file format), you feed them actual (microformatted) HTML. From which they’re able to extract all sorts of information, like author profiles, post types, (the nature of) outbound links, and so on.
If you send out webmentions, you may want to implement microformats, too. Many Webmention endpoints, after all, run source posts through a microformats parser to extract the same kind of information. (You don’t have to, though. Sites on the receiving end will just, well, it depends. They’ll probably stick with a very simple representation of your backlink. Which is totally acceptable.)
If you’d like to offer a “microformats feed,” well, then you just have to.
Total sidenote: there are many feed formats, like RSS and Atom, and JSON Feed, and microformats feeds (which have the potential to offer the richest reading experience of them all).
IndieAuth is like OAuth. You know, “log on with Twitter (or Facebook, Google, or whatever)”? Like, you authorize a site or app to, say, fetch and fill out some of your details for you, through this service that you’re logged into, without ever giving them your password?
Well, IndieAuth is just like that, except now the service is your site. (And if you’d rather not implement it, or your CMS doesn’t support it, yet, there’s a bunch of solutions, too.)
Now, which platform out there would support this? Does support this? Folks using their own sites to claim they’re them (or rather, the owners of said sites)? Well, quite a few IndieWeb apps and services.
And, although this concept is definitely the more philosophical of the bunch, it makes sense too: lots of people refer to themselves online as @soandso on Twitter, instead of, e.g., https://soandso.net. Which is crazy, because (1) Twitter won’t be around forever, and (2) a great deal of people aren’t even on it and thus can’t follow you there—Twitter killed off its RSS feeds a long time ago—but they could access, and follow your feeds at, you kow, your own site.
(Also, when I say Twitter, I mean every darn social media silo out there.)
Seriously, there’s way too many promising researchers sticking to Twitter, presenting their studies, engaging in discussions, and what not. Put that stuff up on the open web, for chrissakes. (And stop lending credibility to platforms that go out of their way to please all sorts of conspiracy theorists.)
Anyway, if you’re looking into setting up Micropub—a great way to post on your site—or Microsub, you’re going to need IndieAuth. (Why? Because both Micropub and Microsub clients get their info—where to post, where to go fetch your timelines—off your site.)
Micropub’s yet another protocol, and provides an API for posting to your own site, from a variety of clients that support it.
Like WordPress’s REST API, but … a standard, which any CMS could choose to offer, to work with any compatible client.
Say I’m on my phone and just wanna post a quick note to my site, or a brief reply to this blog post elsewhere, and I don’t wanna log into my CMS and all that, but use a dead-simple app instead. Well, thanks to Micropub, I can.
Or … remember WordPress’s “Press This,” the bookmarklet that’d let you post and annotate links to other sites really easily? Micropub apps let you do exaclty that, on any device, and more.
Micropub is probably the IndieWeb building brick I use most often. (Then again, I very often post short status updates, much like I used to on Twitter.)
While my blog (sort of) runs on WordPress, I find its official Android app quite cumbersome, and instead use Indigenous.
I can long-press URLs anywhere, “share to Indigenous,” and choose to like, bookmark, or reply to them, type a quick note and hit submit, and Micropub pretty much takes it from there. (That is, makes sure the resulting post appears in the right section of my site, and so on.)
While it’s technically incorrect to just equate Microsub with RSS, Microsub readers are definitely very much like RSS readers.
That’s because Microsub is, well, another protocol, but for consuming news and blogs. A Microsub server typically does all the heavy lifting, i.e., aggregate and parse RSS and microformats feeds into a more standard, JSON-based format, while a Microsub reader (or client), well, ensures a comfortable reading experience.
Exactly like the RSS readers of yore, which are typically both server and client—they’d fetch the different feeds in the background and present you with the resulting timeline on their front end.
Why the divide, you ask? So that more folks can work on and improve readers. Or servers. Whichever they’re better at.
(Honestly, if we wanted more folks to self-host their readers, maybe an integrated service would be, uh, more convenient. Either way works for me, though. Also, the spec pretty much supports doing everything from the client. It’s just that, in reality, some clients [and some servers] don’t always allow for this, requiring end users to jump back and forth between the two.)
If you’re a fan of RSS and just want to stick with that, though, that’s totally fine. Microsub, in fact, is probably the IndieWeb building brick you could most easily do without.