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 just finished my IndieWebCamp hack day project, and I'm pretty excited about it!
A long time ago, my website used to have this 7x7 grid of pixels on the home page, which visitors could toggle between blue and green. It saved the state after you'd click them, so you could leave little pictures for the rest of my website visitors.
I eventually abandoned that version of my site, and that feature disappeared as well. I decided that it would be fun to add it back to my current website today!
So now, my home page has a similar section at the top with a little grid of pixels again!
There were a few differences in my approach this time around. I decided to make the grid 20 pixels wide by 3 pixels tall, in order to reduce the chances of people being able to spell things or draw anything inappropriate.
I wanted the grid to be responsive as well, so that the cells shrink appropriately when the width of the column shrinks. I found this nice answer on StackOverflow, "Grid of Responsive Squares", which pointed me at a technique I hadn't know about, which is to use a percentage for the padding-bottom property. Each cell in my grid is
calc(5% - 1px) wide, with
padding-bottom: calc(5% - 1px) as well. This makes the height match the width, which is based on the relative size of the container.
I also made the grid realtime! If you open the home page in two browsers, you'll see one browser update when you click a pixel in the other! I was able to do this without any complicated server-side support thanks to the nginx push-stream module that I already have installed. It lets a browser subscribe to an endpoint using the EventSource API, and then from my server I can send a POST request to the nginx module to broadcast data to anyone listening.
Maybe my next project will be to get some Neopixels and make a little thing for my desk that always shows the current pattern!