can someone explain to me the "problems" that ATProtocol people tried to "solve" in comparison to ActivityPub like if i'm 12 years old
8
Replies
3
Boosts
@doriane hi. I'm an author and current editor of ActivityPub.
There's a good FAQ here:
https://atproto.com/guides/faq
Roughly:
- Data portability between instances
- Scalability for small instances
- Global view of content and people, such as search
- Data format
- Domain handles instead of email-like handles
- Algorithmic feeds
@doriane another is governance. Bluesky started as a project at Twitter to provide a backplane for federation between commercial social networks. They were going to spin out as an independent company that would provide that backplane as a service. Using an open protocol would defeat that business model, since the other networks could just interoperate without paying Bluesky. So, they built their own.
@doriane I hope @thisismissem answers this one 
@liaizon @thisismissem hello! i would greatly appreciate too 😊 i heard there was a sex worker mastodon instance project that failed because of weakness in activity pub security and other stuffs (https://switter.at/). i see that Emelia you work on tech for sex worker, anything to do with ATProto linked to this? i'd love to learn how in certain social use case we need stuff from ATProto and where ActivityPub failed if that's the case. love
@doriane Two possible theories; only one is true.
Theory 1. ActivityPub has no "center"; each server handles only its own traffic. This means that if a startup wanted to start an ActivityPub startup, it cannot justify its own existence. Users could simply not use the startup's products, meaning you can't move from the "expand" to "cash in" phases. Forcing everything through the funnel of the relay makes the startup "necessary". You can only replace the startup with ops resources equal to it.
@doriane Theory 2. Entire-network full text search. Ex-Twitter users expect this; in practice you cannot implement it with high quality user experience unless every "node" in your decentralized network has access to every message in the network. If this is a "must have", the rest of Bluesky's architecture (scrape PDSes->relay funnel->AppView) falls out naturally. The relay means every AppView sees everything that happens and can build its index accordingly
