The main part of ATProto that is centralized is the PLC and that will eventually be made (most likely) into a consortium. PDS hosting is debatable

That being said, it should be possible to run completely independent atproto networks today. We have several dev infra setups for doing it in the ecosystem

One of the most interesting projects is tangled.sh - a github-like using atproto for the social layer, which fits perfectly.

Bluesky's name collision was pretty avoidable here but I guess they thought the obvious name was BS.

This isn’t quite true. WordPress.com announced they were planning on ActivityPub support, but that is a separate entity run by a commercial company (Automattic).

Their plan was to support it specifically on Tumblr, as well as helping fund an open source plugin for it; there have been no plans to integrate it into the WordPress software directly.

I believe they’ve also deprioritised it as they did significant layoffs recently.

I would also discard services that auto post to the fediverse but are not actively used by the majority of users as such.

Insta: https://bsky.app/profile/pinksky.app

Twitch: https://bsky.app/profile/stream.place

Events: https://bsky.app/profile/smokesignal.events

And just unsolicited feedback but "Blebbit" is a deeply terrible name. It turns my stomach for some reason. I don't even know what a bleb could be or what it could represent besides, like, an ulcer.

Personally, I'd prefer something like an expansion of how XMPP works. By default you only see what people in your contact list have sent you, and anything else is marked "dubious", and it's up to you to read it or not. I think it's a mistake that email servers have been given the responsibility to filter unwanted traffic. Email servers should have only ever simply passed along whatever they received (excluding excessively large messages, of course).

The first email a sender sends to a recipient has an attachment that serves as a request to email them for a specific purpose (e.g. human:human, mailing list, transactional). This email is not delivered to their inbox immediately, but to a separate “friend request” style queue. When the recipient approves, the sender receives a Biscuit token [0] and the email is delivered to the inbox.

Subsequent emails are sent by attenuating a one-time-use token from the master token, which is included in a header. Because they have verifiable authorisation, this can skip all existing spam heuristics because the receiving mail system knows for certain the recipient authorised this sender.

Biscuits can also be attenuated to reduce scope. Want the hotel you are staying at to only be able to send you email for the next 30 days? No problem. Mailing list providers can reject tokens that are scoped to transactional email. A sender can reduce blast radius of compromises by attenuating new tokens to give to third-party providers.

Authorised senders who spam can have all their historical emails quarantined at once and their ability to send in the future removed. Recipients can see who gave spammers their email address.

People who send mail are incentivised to implement this because it improves delivery rates by bypassing all existing spam filters, including IP reputation. “Ask for a token and you’ll never hit a spam filter again” is something a lot of people would jump at the chance for. No need for providers like Mailchimp, you could go back to sending mail directly from your own servers.

Recipients are incentivised to implement this because it will cut down on spam and phishing significantly.

This can be implemented independently of the other side because the fallback situation is the status quo – the initial email just has an attachment that goes ignored, and subsequent emails are sent without tokens and are subject to existing spam filters.

It’s possible for spammers to send lots of unsolicited contact requests, however separating things out into a spam-free inbox and a “this new person wants permission to email you” queue makes it far more manageable than the current ocean of potential spam in an overflowing inbox. Determining “is this new contact legitimate?” a handful of times is much easier than determining “is this email legitimate?” thousands of times more often.

What you’re essentially doing with this is bootstrapping a social graph on top of email. You can then add a bunch of other nice things on top of that, like public key cryptography, but the actual diff between current email and this system is surprisingly thin.

[0] https://www.biscuitsec.org

DMAC, DKIM, SPF, S/MIME, PGP are all ugly workarounds. The issues are fundamental.