WebSub is a standardized way for publishers to notify subscribers when new content is available. It was formerly known as PubSubHubbub, which was hard to say, so I'm glad we renamed it.
One of our goals with WebSub was to ensure that existing PubSubHubbub implementations would still be compliant, so there are already lots of implementations in the wild! If you're publishing content online, want to receive realtime updates when feeds are updated, or are building a tool to facilitate either of these, WebSub is a great fit! You can use the tool at websub.rocks while building your implementation to get immediate feedback!
Thanks to everyone who contributed to the spec, and especially my co-editor Julien!
IndieAuth is an identity layer on top of OAuth 2.0, and used by Micropub clients. Micropub was published as a W3C Recommendation in May of last year. Today, IndieAuth was published as a W3C Working Group Note.
The Social Web Working Group did not set out with the goal to standardize any sort of authentication mechanism, but since almost all of the Micropub implementations already supported the same mechanism, we decided to publish a "Note" to that effect. (The Micropub implementations that don't use IndieAuth use hard-coded tokens as a shortcut.) Notes are quite different from Recommendations in the eyes of the W3C, as described by this sentence: "The publication of a NOTE by the Consortium implies no endorsement of any kind." The goal of publishing this Note was to capture the current state of interoperable implementations.
One of the things I like most about the W3C standardization process is that specs are published after they describe things that are working, rather than published as an aspirational blueprint. We kind of pushed that definition to an extreme with IndieAuth, since there have been live interoperable IndieAuth implementations for several years now. Previously, I had written up several guides for how to implement the various roles in the IndieAuth flow, but never written it down as its own spec. The guides were certainly useful, as was clearly demonstrated by the fact that people were following them to build out various parts of the ecosystem. But there is also a need for a spec to lay things out and remove any ambiguities along the way.
Thanks to everyone who helped iron out the details of the language in the spec! We made a lot of good progress over the last few months!
So with these two specs published today, we've taken quite a lot of the IndieWeb building blocks through the W3C process!
So here's a few specs and tools that I'm working in the immediate future:
IndieAuth test suite - Like webmention.rocks, micropub.rocks and websub.rocks, I plan to make a tool that will help test your IndieAuth implementation. It will do things like throw tricky situations at your client to ensure you're handling the edge cases properly.
Finally finish renaming indieauth.com - I never should have called it that, since it's doing two completely separate things. You can read about the details here.
Microsub - Microsub is currently an early draft spec. The goal of Microsub is to do for reader interfaces what Micropub did for publishing interfaces. A Microsub server provides a standardized API that reader clients can use to show content. This will help make developing IndieWeb readers a lot easier, and also allows you to keep your subscription list in a server that you control rather than letting the reader own the list.
Monocle - Monocle is my Microsub implementation. It subscribes to feeds and presents a them as a Microsub server so that I can use any Microsub client to view everything. There's still a lot of work ahead for me here, but it's my goal to finally stop using IRC as a reader by getting Monocle to the point of being functional enough to cover all my use cases.
As always, you can help me and the rest of the IndieWeb out by adding support for any of these specs on your own website! We are always excited to welcome new people to the IndieWeb chat if you have any questions!
I'm excited to announce that Micropub is now a W3C Recommendation! It's been a long road, but we made it! This is the final stage in the W3C spec lifecycle, and means that the spec has gone through several stages of review, and all parts of the spec have been implemented by at least two people.
Micropub began in 2013 when I outlined a simple API to create blog posts and short notes for my website, and published it on the IndieWeb wiki. I implemented it on my server as well as in a few new client applications, and was quickly using it day-to-day. The main design goal with Micropub is that it should be easy to implement, and it should build on top of existing standards: OAuth 2.0 and the Microformats 2 vocabulary.
Micropub is also intended to be implemented incrementally. Rather than having to read, understand, and implement the whole spec, you can start by implementing the basics of just creating simple text posts. You can later expand your implementation to support more complex objects, as well as editing and deleting posts.
One of the benefits of supporting Micropub on your server is that it allows you to leverage other peoples' work in building an interface to create posts on your own website. By 2014, there were already six independent server implementations, and four client implementations other than my own.
Over the next years, more and more people built out Micropub support in their blogging systems, including plugins for WordPress, Known, Kirby and more. Many client implementations have popped up as well, for a variety of platforms including the Micro.blog iOS application, a Ruby web app, an XMPP chat bot, and more. I also wrote a Micropub proxy service OwnYourGram which imports your Instagram photos to your website, and another called OwnYourSwarm that does the same for Foursquare checkins.
In 2015, the Social Web Working Group decided to adopt the Micropub spec to fulfill the client-to-server API aspect of our charter.
After taking the initial spec from the IndieWeb wiki and writing it up in W3C format, I brought it to the working group as an Editor's Draft. After working on it within the group for a few months, we resolved to publish it as a Working Draft in January 2016.
Publishing a Working Draft is typically the first time the spec will be noticed by other groups within the W3C, as it's the first time a working group signals that a spec is intending to reach Recommendation status. Micropub went through 5 revisions of Working Drafts from January to July 2016, gathering feedback from implementers and incorporating it into the spec. The changes ranged from editorial clarifications, to changes that affect the implementations such as names of properties or response formats. You can see all of the changes in the Micropub working drafts here.
At the point the working group is satisfied that the spec is in good shape, the group can request that the spec be promoted to a Candidate Recommendation. To do so, the group must demonstrate that the spec has received "wide review" from people outside of the working group. We used GitHub Issues to get and track feedback, to make it easy to show the feedback received and how any feedback was incorporated into the spec. Publishing a Candidate Recommendation requires the approval of the W3C director.
The spec then stays in the Candidate Recommendation stage for a minimum of four weeks. This time is used to gather feedback from other W3C member companies, as well as gathering implementation reports from anyone interested in the spec. Implementation reports are meant to collect information on which parts of the spec are being implemented, in order to get a sense of how mature the spec is and how well it's written. While the implementation report may look like a checklist you have to complete, it's totally fine to submit it with only a few boxes checked. It's more of an evaluation of the spec than an evaluation of your implementation.
In the W3C Social Web Working Group, we set an intentionally high bar for our specs to graduate out of Candidate Recommendation. In order to be promoted from Candidate Recommendation to Proposed Recommendation, our group decided that each feature of the spec must be implemented by at least two independent implementations. This helps ensure that the spec really does encourage interop between implementations.
I created a test suite, micropub.rocks, that you can use to test your client and server implementations. The test suite helps you fill out the implementation report, and also is a great tool for debugging your application as you're building it out.
If you're building a server, micropub.rocks will pretend to be a client and will send you requests that hit all the edge cases of the spec. If you're building a client, you can use micropub.rocks as a server to test how well your client can create and edit posts.
At the point the working group has determined that all features of the spec have been implemented, and that the spec has been reviewed by people outside the working group, the group can decide to request that the spec be promoted to Proposed Recommendation. The spec can't have any substantive changes between Candidate Recommendation and Proposed Recommendation, but things like typo fixes are okay. The W3C director must approve the request to transition to Proposed Recommendation. The Proposed Recommendation step is one last chance to broadcast widely that the W3C believes the spec is ready to publish as a Recommendation, and gives the W3C Advisory Committee an opportunity to formally object to any aspect of the spec.
Micropub reached Proposed Recommendation status in April 2017.
The final step is to publish the spec as a W3C Recommendation. In order to be promoted from Proposed Recommendation to Recommendation, the W3C Advisory Committee and the Director must approve the request. Once a Recommendation, the spec is finished, and can only be changed by submitting Errata.
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!
I hope this post has been a useful overview of what I've been working on for the past several years, and gives you a bit of a sense of what it's like to work on specs at the W3C!
Does anyone know of any actual *live* implementations of WebSub (or PubSubHubbub, any version) that use the .host-meta method of advertising the hub URL, or any consumers that check for it? I did a bit of looking around at some of the major players and couldn't find any that did. If you know of a publisher or consumer that supports it, please share the URL to it.
To clarify, I'm talking about the third method of Discovery listed here: https://www.w3.org/TR/websub/#discovery
publishers may also use the Host-Meta Well-Known URI [RFC6415] /.well-known/host-meta to include the <Link> element with rel="hub"
We plan to exit CR on 2017-05-11, and if we don't have at least two claims of implementations of that feature, we'll be dropping it from the spec when we exit CR. It's important that if any implementations of this feature exist, we hear about them ASAP.
I did add support to websub.rocks for discovering the hub URL using this method, and the test suite is now logging whether anyone publishes a URL that advertises the hub that way, so we'll get a bit of data from that. However I don't want to waste the time writing tests to check whether subscribers support this, since there's no evidence of demand for the feature. I also don't want the presence of the test to cause new subscribers to have to do the extra work of checking the .host-meta file just to pass the test suite.
So far, all known WebSub/PubSubHubbub publishers support rel discovery through the HTTP Link or HTML/XML tags, so there was never any incentive for subscribers to check the .host-meta as well, so I strongly suspect there just aren't any subscribers that check for it.
Since this feature is already marked At Risk, the data is strongly pointing towards dropping it on the 11th.
If this feature is important to you, then please show evidence that it's been implemented in any form, and I would also highly encourage you to write a test for it in websub.rocks.