A long-winded IndieWeb ramble I wrote on the train back from Portland

(This is a somewhat-edited version of a disconnected ramble I posted on Twitter/Mastodon while on the train home today. I feel like putting this somewhere that I own it, but am not in a good enough mental state to actually write it properly.)

Yesterday at IndieWeb Summit, someone – Aaron, I believe – mentioned that one of the big differences between IndieWeb initiatives and ActivityPub is that IndieWeb is made up of simple building blocks you can pick and choose while ActivityPub frontloads a lot of complex work. This is a sentiment I very much agree with and it’s unfortunate that the main reason Mastodon switched from OStatus (which is very IndieWeb-esque) is because it made it slightly less inconvenient to pretend to have private posts. Which aren’t even implemented that well.

Mastodon’s “private” posts really suck from a bunch of standpoints. There’s no ability to backfill or even view on web without being on the same instance, and Mastodon’s actual privacy controls go in the wrong direction, so it’s still necessary for a separate vent account. As usual I don’t know if this is a problem with ActivityPub itself, or an artifact of how Mastodon shoehorned its functionality into ActivityPub, but either way, the end result is that Mastodon’s post privacy isn’t really all that useful, nor is it really all that private.

So, right now ActivityPub is the darling of the fediverse, but I’m hoping that the current push toward AutoAuth and trying to use it as a basis for private webmentions and the obvious next steps of private feeds and private WebSub will change that. I do worry that IndieAuth/AutoAuth are kind of hard to do in piecemeal ways though (well, okay, IndieAuth becomes really easy using IndieLogin but I don’t want to see a single endpoint become what everyone on the Internet relies on). And of course once you get into an integration between auth stuff and content stuff you also need to worry a lot more about content management and how it integrates, as well as this seeming fundamentally incompatible with static site generation.

At the Summit there was definitely a lot of compromise that people were doing, such as using Javascript libraries to introduce externally-hosted dynamic IndieWeb stuff onto statically generated pages. I think in this world where SSGs can be supplemented with third-party endpoints that use client-side JavaScript there could be a world where some level of privacy can happen via clever use of client-side includes of data at non-public unguessable URLs. (Although the ideal solution for that is to use the third-party APIs to generate webhooks that then trigger a file change → git commit → commit hook → build/redeploy.)

Non-public unguessable URLs aren’t great for privacy in general (and I mean, Publ has had “privacy through obscurity” since day one and there’s several reasons why I rarely use it anyway) but it’s at least better than nothing.

Read more…

Some WebSub-Atom observations

As part of testing my WebSub changes for FoF, I decided to switch to a WebSub hub for myself that provides some subscriber analytics and so on. One neat thing about how WebSub works is that the “hub” layer is completely modular and it really doesn’t matter at all which one you use, and if the one you use has problems you can switch to another one just by changing the URL in your feed and all subscribers will eventually seamlessly migrate (at their next normal polling interval); if anyone even notices a problem it will just be that they don’t receive a push update during that polling interval. (Which, let’s be honest, is incredibly unlikely for most RSS feeds.)

Anyway, because of these new analytics, as well as information I gathered from my new WebSub-supporting reader, I now know a bit more about the state of WebSub.

Read more…