Thoughts on BlueSky's "Self Authenticating Social" Protocol

Got a chance to read It starts off pretty good, speaking on popular open protocols and approaches. It then brings up scale and Twitter's experience, which is really more of a concern for commercial identities—information gets where it needs to be when it can be routed there. The need for “always accessible AND high speed AND high throughout handling” really is a demand of capitalism and not that of people, so I readjusted how I perceived this from that framing going forward.

The fact that the only explicit link to the IndieWeb is to the death of is wild, but go off. This is within the “Portability” heading, which does a good job of pointing out the failings of relying on someone else to hold your information. We all still do this today—I do it by trusting DigitalOcean to keep my leased server running, files intact and connected to the Internet, DNSimple to keep resolving my domain names and maintain my lease on domain names. The Web is rented for the most part and as it stands, it has to be. I can't beam information to the UK without relying on probably ten other companies to route that information there. That's done transparently to the users involved and is mainly run by private entities, so there's no raw ability to audit such a connection without having a deep understanding of network engineering. I say all of that to say that you have to draw the line somewhere when it comes to who to trust, and I stopped at "running things for me". I didn't want people writings software for everything for me, so I tend to use freely licensed software and make whenever I feel like (like this site). That requires time, patience and a deep interest in doing so. Not a lot of people have that, so I'm deeply curious how the Bluesky team aims to solve that techno-sociological problem before creating a new set of them.

Scale is the part that screams, “we need to find a way to subtly profit from making something in the leasable commons”. Especially this part:

Existing decentralized social protocols default to local conversations because it’s a natural fit for a decentralized architecture, but our goal is to make global conversations possible while preserving the freedoms users gain from interacting through an open protocol.

Local conversation isn't only a “natural fit” for decentralized architecture, it's a natural fit for humans. Dunbar's number hints at the notion that we can only reasonably interact with about 200 people, so attempting to keep someone up to date on about 200 people daily sounds like trying to remake existing systems, but now it just lives on your devices as well. I know that for things like Lwa and even Lighthouse, keeping it from being super spam-tastic is going to be a critical feature. Like it shouldn't get to a point where you're scrolling infinitely—you have better things to do.

I really like this idea:

The premise of Bluesky, however, is to work towards a transparent and verifiable system from the bottom up by building a network that is open by default. We’ll do this by giving users ways to audit the performance of services and the ability to switch if they are dissatisfied.

This is something I want for the IndieWeb as well—other communities have it and can do it indirectly by using NodeInfo since a lot of the federated Web already uses it. Being able to have sites self-report about their public capabilities also gives people to vet the community and gives them a sort of report card. I think extending it to other systems is interesting. Especially in the case of “aggregation” or “feudal” systems, being able to take all of your information and work within a new system is still very hard. And it might not be completely a protocol or standard issue, it's similar to the situation of backups—you know they work when you use them, but can you reliably test every backup from the point of initial creation? That aside, I'm very in favor of sites handling levels of self-reporting on capability. Shock has NodeInfo reporting as a potential feature so I can see a service that can find IndieWeb features there can then run a set of semi-SWAT0 tests against the site. On the point of transparency, I think this is less of a problem for the IndieWeb, but still can be addressed. I know that for Lighthouse, every nudge of feed control that I can provide while keeping the abstractions put in place is going to be provided. Like if a post has been filtered out, I want people to know why and be able to issue 'block' statements. It's something I'm going to be working on for Lwa but I think this is something that should be baked into Microsub as well.

I'm glad that they admit later on that it's a “do what you want, but understand the risks” with their long-term goals. I do think that having backups / synchronization built into the system early can dramatically reduce the worry of data loss—it's kept as redundant as possible. However, the notion of aggregators being the place where things like search indices and metrics lie is a bit worrisome to me. There's definitely a level of local computation that we should employ on more powerful devices and give people a choice—the theme of my life. Again, this gives an opportunity for more explicit trust in these services and allows people to go full sovereign if needed. I do appreciate them calling out the immaturity of the cryptographic primitives in this space and how it'll need more work.

All in all, I hope that this stuff works on the actual Web, doesn't reinvent too much of the wheel and works to extend versus rebuild.

Engagement is powered by Webmentions — a premier standard of the Web to let other sites know you've mentioned them. Learn how to reply from your own site. or from a supported silo Aaron has an interactive post about this. If you've mentioned this URL via another one, use the form below to submit it.

If you don't currently own your replies, then you can click below to do so.

I currently aim to own my comments and plan to eventually show those I've received once I finish Lighthouse.