[danabramov]

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.

[fabrice_d]

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

And maybe that's a good thing.

[msla]

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.

[fabrice_d]

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

[jimbobthrowawy]

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.

[danabramov]

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.

[afavour]

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.