Hacker News Reader

Comment by danabramov | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com