Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I guess I just don’t believe that any solution where you don’t have full view of the network is aligned with what normal people want. Maybe AP is on a bigger mission to teach people that they’re “wanting wrong things” and actually you should enjoy a system where everyone sees a different like count and half the replies are missing. I think it’s a dead end.


That's a purely personal point of view but I don't think the AP people claim that "people want the wrong things", but rather that "the things you want have a cost and we're not hiding it".

The fact that likes count and half the replies are missing is not specific to AP but to implementations not willing to actually follow the AP community: in fact the SocialHub (https://socialhub.activitypub.rocks/) community is the place where all coordinated development happens, and solutions to those issues have already been designed and implemented in multiple softwares, with the notable exception of Mastodon. Maybe that's the issue: people keep looking at Mastodon to understand AP, but Mastodon is one of the worst examples of AP, even when talking only about the technical domain. It doesn't implement the C2S API, it doesn't have portability, likes counts and missing replies as you said, ...


Mastodon/AP is difficult to discuss because pointing to flaws of Mastodon leads to people saying "it's just a Mastodon problem", but AP doesn't by itself specify much so it's hard to critique it too. If there's a "flavor" of AP that's competitive with what atproto solves (can "walk away" without cooperation, can "revive" and "remix" data from other apps, can "fork" products with all their data), I'd like to read a condensed summary of that architecture.


AP, even in its purest simplest form, already allows to "revive" and "remix" data: you have the JSON of the data, you can do whatever you want with it. You can build a product injecting JSON of this data, just like in AT, but those product don't really exist so even if I can say "yes you can fork them" it's all talk.

There's no talk about migration in the core spec, but how is it in ATproto in practice ? Does everyone carry their entire repository, live from their own PDS, ready to be remigrated somewhere else ? It does feel like in AT-in-practice people just have a PDS and that's it ? (I've never used it, I might be totally wrong)

Really, if you want a simplistic view of AP, it's easy: it's an INBOX where you receive content, and an OUTBOX where you send content, and the content is activitystreams-formatted JSON. Anything else just makes it easier to work with.


That's why I always say AP-in-practice. It handily avoids any "but the spec says!" diversions.


> That's a purely personal point of view but I don't think the AP people claim that "people want the wrong things", but rather that "the things you want have a cost and we're not hiding it".

I think that's a great way of putting it, and it it's at the root of a lot of problems we have today. Our society increasingly encourages people to make money by coaxing other people into doing things whose costs are hidden.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: