Bluesky Is a Scam

This is... the least charitable possible interpretation of the current state of Bluesky and the AT Protocol. It's not wrong, but it's not clear that it will be right either.

Personally I would have preferred if they implemented federation before going into beta because that is the whole point of a decentralized network. But OTOH there is an opportunity right now to lure people away from Twitter and that opportunity may not exist in a few months. I don't think progressive decentralization, over a span of months not years, is inherently evil.

> The DID itself is derived from the sha256 hash of the first operation in the log. It is then base32 encoded and truncated to 24 chars.

https://atproto.com/specs/did-plc#how-it-works

They could be using public keys as identifiers, why are they using nonsense?

The solution to the problem of centralization that Bluesky has been touted as tackling (and that Mastodon doesn't deal with in a satisfactory way) doesn't look anything like Bluesky or Twitter or Mastodon. Instead, it's just making RSS (read: Atom) suck less.

Crazy that no one in the relevant circles seems to have realized that microblog posts don't require anything more sophisticated than what a static site generator can produce. The heavyweight server-to-server protocols that we've seen are just way too heavy.

note that fiatjaf is the creator of nostr, which is a competing product

This is how I've been feeling but I'm assuming there's more to this that I just don't know.

I keep thinking, what if we: 1. Use domains/subdomains as usernames by just... having the content on them.

2. Follow a truly basic structure for index (feed), single post, etc. so that clients know how to consume them easily.

3. For interactions (replies, likes, etc), the client posts them to your own server (or service hosting you) and they're available at a url referencing the original post url on their own domain. ex) mydomain.com/replies/thepostsurl/1

4. It then posts the reply url to the original posts server endpoint, which can accept or not.

5. When a user loads the post, it lists the replies and interactions as a list of links. the client goes and gets their content directly, and renders it.

This would work without any servers actually having to talk to each other or store more than a link for interactions. If you want to confirm the interaction url on receiving a submission, your server could check but it doesn't need to store or cache it.

Am I crazy or would this not work just fine? or, is this what activity pub already is?