Swarms of content.
Cryptographic identities and content signing/attribution.
Cryptographic hashes for content uniqueness/immutability.
Immutability in general.
Ephemerality (content lives as long as some node cares to retain it, otherwise it gets forgotten).
Concrete but extensible ontology for core concepts.
You don't need login. You don't need to agree on a common platform. 3rd party tools and extensions can filter content, provide trust graphs, interest graphs, etc.
You can just slurp up and score whatever might interest you. Your agent or algorithm might do pre-filtering against your preferred heuristics to downsample to relevancy.
You could write any client for this in any shape or form. Completely different look and feel for different people and interests / focuses.
Atproto is an attempt to engage with the problem space in a way that hits the baseline UX of Web 2.0 apps.
But it’s worth noting atproto designers come partially from P2P lineage. Some worked on Scuttlebutt, IPFS, and others.
And maybe that's a good thing.
Coming up with a new model for social media and also dictating what features are good and bad for users is going make user adoption a tough challenge.
An "AppView" is the API server that most clients connect to that aggregates data from the network and serves it in a more useful way. mu.social still uses bluesky's AppView (api.bsky.app).
The name is confusing. I thought clients were appviews myself for a while.
This is the wrong way to see it. There is no "Best and correct" solution, only solutions with different trade-offs. ActivityPub/Mastodon/Federation makes sense in some cases, "pure" direct distributed P2P makes sense in some cases, one central server makes sense in some.
Bluesky/ATProto just made different trade-offs, for different use cases, some of which wouldn't have been possible without the architecture they ended up with, which sibling commentator expanded on exactly what.
It's a cool idea, in practice it kind of sucks as an experience.
It's been developed adjacent to the Bitcoin community and I can't say there's much going on besides spam.
(NOT ATProto and ActivityPub. Those are platonic ideals of protocols which have no real-world implementations. ActivityPub, especially, was obviously designed by architecture astronauts.)
Not sure how I haven't heard this one before, but I'm stealing it. Salient descriptor.
Joel's post was the genesis https://www.joelonsoftware.com/2001/04/21/dont-let-architect...
Salient indeed!
Interesting. I'm an architect by title because my employer doesn't have the career path of a "senior specialist who really knows their stuff and wants to keep going at it". No. We have only two paths: either Manager (not interested in the slightest), or the almighty Architect. Every time I'm forced to architect something, that bit about the bottom line comes to my mind.
Anyways, it's similar in my company. People get the architect title, so managers can justify the salary promotion.
The Google / Apple walled gardens don't make it any easier, but even without them, the fundamental issues of battery life and intermittent connectivity don't disappear, walled gardens just force you to design around them instead of hiding your head in the sand and pretending they don't exist.