"These are some quick notes on @shreyanjain.net's [Nostr and ATProto](https://shreyanjain.net/2024/07/05/nostr-and-atproto.html) write-up.
Overall: omg this thing is a book. Lauditory! It is really great to see this discussed in depth and detail. I don't know whether to be embarassed that we didn't write up something like this much earlier, or proud that things have been open/transparent enough that something so complete and correct can be written independently.
atproto architecture decisions (especially existence of AppView) hinge on a couple assumptions:
- big world public social web is worth trying to fix
- global aggregations and discovery are important big world networks
- anchoring persistent online identity+security in a single private cryptographic key won't work for majority of humans
It is possible somebody will have a big breakthrough in cryptographic UX that changes the last one, but i'm not holding my breath.
AppView trustworthiness: a big crux of going with AppViews at all was deciding that aggregations are actually fairly important: eg, controling who/what shows up in reply threads, or who is using hashtags or keywords, both has a lot of utility, and impact/tempration for abuse, trust-wise. In nostr, are not trusting the relay to compute/verify the aggregations, but you are using them to query for relevant data, and as far as I can tell you are trusting them to return accurate and complete query responses.
If all you care about is access to content from a known repo, you can just connect directly to the PDS, or one or more relays for redundancy, to access and validate that content. As you point out, this potentially more reliable and trustworth chain than relying on queries to relays, which may return incomplete answers (censorship!), or you need to query an indeterminate number of relays redundantly until you can trust the results.
I think most folks want aggregations, not just content. If you don't include aggregation relatively natively in the system, centralized sidecar aggregators will build up for search and discovery, just like Google for the web. AppViews are google-like, but at least they are specified and interoperable. I expect/hope that the activation-energy and resulting "moat" to running an appview will be way lower than google to the web... but still takes effort. Definitely a bit of a concern and area for possible improvement, but I don't think it is existential for atproto, and do think having them actively included in the architecture a strength and advantage for atproto vs AP or nostr. (IIUC, AP also has a concept of "relays", but I don't think they are very core to the protocol and don't have much adoption/impact)
Generic nostr relay queries: these would be quite useful for small atproto app devs! at least when getting started, not having to subscribe to the full firehose. Backlinks would help a lot (as Paul has also mentioned). The queryLabels endpoint on Ozone is an existing fairly-powerful generic interface. Does result in an expensive piece of infrastructure!
PLC: definitely too centralized as it is operated today, to me the big question is whether our plan/roadmap is clear and credible enough that we can push it off longer, or if we more urgently need to implement the plan. DIDs are also a clearly modular part of protocol: atproto overall does not live-or-die by the future of DID PLC specifically, only that some credible DID method ends up working out.
atproto also kind of wants to be "graph of data just out there in cyberspace".
I think AT-URIs are really nice and underappreciated as a concept and dev affordance."