and I actually don't hate that bit (I really like lexicons, although I might have approached it in a different way) - what I hate is the aggregation layer. I know that it is possible to have an AppView-less atproto app (e.g. RedDwarf), but I feel like much of the ecosystem still defaults to the assumption that it will go through the Bluesky AppView.
Unrelated apps (https://leaflet.pub/, https://tangled.org/, http://semble.so/) don't go through Bluesky Appview (since they need aggregations of different kind of data). I think aggregation is the only model that can compete with centralized services on UX, but of course different apps would need different backends.
That's pretty much what atproto is, except it's typed JSON rather than HTML, and HTTP+WebSockets to allow aggregation.
I wrote more about how it works here if you're curious: https://overreacted.io/a-social-filesystem/
and I actually don't hate that bit (I really like lexicons, although I might have approached it in a different way) - what I hate is the aggregation layer. I know that it is possible to have an AppView-less atproto app (e.g. RedDwarf), but I feel like much of the ecosystem still defaults to the assumption that it will go through the Bluesky AppView.
Unrelated apps (https://leaflet.pub/, https://tangled.org/, http://semble.so/) don't go through Bluesky Appview (since they need aggregations of different kind of data). I think aggregation is the only model that can compete with centralized services on UX, but of course different apps would need different backends.
You may be confusing the Relay, a protocol component run by Bluesky, with the Bluesky AppView
https://atproto.com/articles/atproto-for-distsys-engineers
This is like saying anyone can open a lemonade stand in Mogadishu.