@hongminhee@hollo.social

One thing I keep coming back to when comparing and AT Protocol: ActivityPub is basically a convention on top of the stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the , and then years later it could, just by adding an endpoint.

AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.

I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.

5 replies

@simonwood@mastodon.social · Reply to 洪 民憙 (Hong Minhee) :nonbinary:

@hongminhee I think that's a very good description of one of the key attributes of ActivityPub and the difference with AT Proto. ActivityPub can add something to the existing web, it allows for great diversity, and adds huge value in doing so. But over on AT Proto the way that infrastructure is composed is supporting a lot of completely new apps and developments, which is also exciting in its own way.

@hongminhee also making decentralised ID just URL you fetch simplifies a lot

I've read about dereferencing at:// urls[1], and it's...well, it's more like recursive DNS resolving, where you go to the registry (PLC), to get information where stuff you need is hosted (PDS), and then go there and get it

sure, it gives more flexibility, but I still don't get how they're gonna decentralise PLC
Blockchain is the only suitable solution I know, and in terms of efficiency they suck

[1] overreacted.io/a-social-filesy

overreacted.io

A Social Filesystem — overreacted

Formats over apps.

@openrisk@mastodon.social · Reply to 洪 民憙 (Hong Minhee) :nonbinary:

@hongminhee activitypub has a top-down feel, abstracting "social web" concepts and indeed sticking (mostly) within the Web conventions. It is not very prescriptive about implementations.

In comparison ATproto is more of a bottom-up design, in a sense the bluesky code is the documentation of the protocol. Important design choices target a certain type of "scaling".

Its quite fascinating and revealing that such different approaches, help create the same "twitter" microblogging illusion.