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.

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?

The biggest hurdle is the vast VAST majority of people do NOT want to host or run anything, which means there is varying levels of centralization, which introduces the issues people have had.