Daniel Holmgren discusses this in his really good atproto ethos talk — the P2P networks are cool but incapable of delivering on what users expect from modern social media https://youtu.be/1A-0k58TfPo?si=f_d4uoz_I8kMoKDw

The problem with client P2P is there’s no aggregation at scale. You can’t even accurately calculate things like post likes. Not to speak of recommendations, search, and all other basic things people expect from social apps.

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.

> You can’t even accurately calculate things like post likes.

And maybe that's a good thing.

Technical problems give way to philosophical differences but the over-arching problem is that the people behind ATProto really want to make a social media ecosystem that attracts lots of average people who will refuse to understand that the solution you're giving them can't do things Twitter could do back before Musk bought it. People get angry enough at Bluesky not having an edit button, and it's at least possible to talk about how editing can be abused.

You can switch to the AppView from https://mu.social/ and you'll get editing working.

mu.social is a "client".

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.

I kind of started calling them all “apps” with true appviews being “independent apps”. I think sometimes it makes sense of think of this as an implementation detail. For example, Mu could actually switch to its own database if they do a bunch of technical work in the future. From the users’ perspective, it wouldn’t be noticeable.

Perhaps, but that isn’t what users want.

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.

Both Blue Sky and Mastodon are that, if you squint.

(NOT ATProto and ActivityPub. Those are platonic ideals of protocols which have no real-world implementations. ActivityPub, especially, was obviously designed by architecture astronauts.)

> architecture astronauts

Not sure how I haven't heard this one before, but I'm stealing it. Salient descriptor.

Even has a wikipedia article https://en.wikipedia.org/wiki/Architecture_astronaut

Joel's post was the genesis https://www.joelonsoftware.com/2001/04/21/dont-let-architect...

Salient indeed!

> They tend to work for really big companies that can afford to have lots of unproductive people with really advanced degrees that don’t contribute to the bottom line.

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.

I'd say an architect is kind of the opposite from a specialist. The specialists cares about the stuff only they know. The architects care about the stuff everybody should know.

Anyways, it's similar in my company. People get the architect title, so managers can justify the salary promotion.

Secure Scuttlebutt was a fun implementation of this, but the project is all but dead with Staltz working for Bsky and the other maintainers moving on.

Nostr is basically this.

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.

Yeah, kind of a bummer. There are some cool ideas that have been implemented in nostr, but everything has that bitcoin/zap hussle.

> All of this goes away if we just do P2P social media.

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.

P2p networks either kill your phone battery or require you run a hosted instance somewhere, which cuts out about 99% of potential users.

This doesn't work for intermittently-online, battery-powered, CGNATed mobile devices, and that's what people are using in practice.

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.