ActivityPub over ATProto (2023)(berjon.com)
berjon.com
ActivityPub over ATProto (2023)
https://berjon.com/ap-at/
41 comments
Damn, I could've been there, if I'd known about it
Will content from dwebcamp be online for those unable to make it?
I think so, yes. The videos of the last camp are online as well at https://dwebcamp.org/videos
RSS/webmention > ActivityPub > ATProto
I don't disagree with the sentiment as I love RSS, but doesn't it have a different use case than ActivityPub or ATProto?
I mean, conceptually ActivityPub is quite similar to RSS. You might be able to call it Less Simple Syndication.
That doesn't do ActivityPub (or ATProto) justice. The inverse would be "more complicated RSS". But it is way more than that. You get semantically meaningful typed messages on AP. Most people think of AP as what you get on the fediverse, where basically the only type in use is the ActivityStreams Note object. But it can be anything that is transferred in a standards-conform interoperable way.
And how does RSS let you move your data to a new host while preserving your identity like AT Proto does?
Change the DNS record?
Yes, this works if your RSS server has its own DNS record that you control, and is essentially what the Domain Handle -> DID indirection gives you in AT Proto.
What Bluesky and AT Proto in general do is make it easy for people to either get a domain (a *.bsky.social subdomain) or use their own as their handle.
And AT Proto also lets you change your domain while preserving your identity, since the actual identity is a DID.
That makes it very easy to move your data and your handle around and not lose followers. If you change your RSS server's domain name, your subscribers don't come with you.
What Bluesky and AT Proto in general do is make it easy for people to either get a domain (a *.bsky.social subdomain) or use their own as their handle.
And AT Proto also lets you change your domain while preserving your identity, since the actual identity is a DID.
That makes it very easy to move your data and your handle around and not lose followers. If you change your RSS server's domain name, your subscribers don't come with you.
If the PDS URL is dead, is there a way to find the new canonical PDS? I guess you can theoretically index every log from everywhere and just look for new entries signed by the same key? But there would be no way to know if you have the latest posts without the PDS address.
This is an apples-to-oranges comparison
Ok, since everyone's here, I'll ask: what is the credible exit from Bluesky - as in, not ATProto as a whole, but specifically the Bluesky PDS/AppView/etc - right now, in 2026?
I have a Bluesky identity that I registered primarily to follow someone that I happened to meet in person while stumping for the Rio Grande Plan[0]. I only have like five posts on it, but I would like to migrate that over to the same domain I already self-host Mastodon on. Bluesky has an option to have your handle on a custom domain, but that involves publishing a DNS record containing a did:plc whose keys are custodially owned by Bluesky. This is not so much an exit as it is an overcomplicated verification scheme.
My assumption is that if Bluesky wanted a better credible exit than ActivityPub, then we would need some way to rotate keys so that I could have my own PDS publish new posts on my existing identity and have other AppViews recognize that as the same kmeisthax that was previously using Bluesky as a PDS. The Mastodon exit is woefully inadequate, but at least if the admin cooperates, you can redirect your account and export your data. Everyone else on any other ActivityPub instance will see the same thing. As it currently stands, ATProto has a great way to migrate between AppViews[1], but no way to migrate off an uncompliant PDS.
[0] The Rio Grande Plan is a citizen-led movement calling for burying the heavy rail corridor going through Salt Lake City.
[1] ActivityPub is actually really lousy at cross-app interaction. If you're on a Mastodon instance, there is no way to participate in a Lemmy forum. Mastodon does not understand how to send the correct ActivityPub messages that Lemmy expects; and there's no protocol for Lemmy to tell Mastodon to publish certain ActivityPub messages on its behalf.
I have a Bluesky identity that I registered primarily to follow someone that I happened to meet in person while stumping for the Rio Grande Plan[0]. I only have like five posts on it, but I would like to migrate that over to the same domain I already self-host Mastodon on. Bluesky has an option to have your handle on a custom domain, but that involves publishing a DNS record containing a did:plc whose keys are custodially owned by Bluesky. This is not so much an exit as it is an overcomplicated verification scheme.
My assumption is that if Bluesky wanted a better credible exit than ActivityPub, then we would need some way to rotate keys so that I could have my own PDS publish new posts on my existing identity and have other AppViews recognize that as the same kmeisthax that was previously using Bluesky as a PDS. The Mastodon exit is woefully inadequate, but at least if the admin cooperates, you can redirect your account and export your data. Everyone else on any other ActivityPub instance will see the same thing. As it currently stands, ATProto has a great way to migrate between AppViews[1], but no way to migrate off an uncompliant PDS.
[0] The Rio Grande Plan is a citizen-led movement calling for burying the heavy rail corridor going through Salt Lake City.
[1] ActivityPub is actually really lousy at cross-app interaction. If you're on a Mastodon instance, there is no way to participate in a Lemmy forum. Mastodon does not understand how to send the correct ActivityPub messages that Lemmy expects; and there's no protocol for Lemmy to tell Mastodon to publish certain ActivityPub messages on its behalf.
The PLC keys are normally intended to be held by your current PDS. Not a hard protocol requirement, but without it, certain things like migrating to a custom domain handle cannot be done cleanly though the app, and would need to be done manually. It might be a requirement of the bluesky hosted PDSes though, as those have some extra requirements beyond the reference self-hosted PDS.
The fact that BlueSky runs the PLC central server is supposed to be fixed by them creating a swiss association to run and control it instead, but while they announced this, it is unclear if it went anywhere.
If you migrate to a self hosted PDS using the all-in-one migration `goat account migrate` command, it will temporarily change your handle to a subdomain of your new PDS, and leave the new PDS managing the PLC. You can instead perform each step manually via goat or raw API calls, either of which would let you transition to direct PLC key management, and/or a new domain based handle as a single atomic plc update, as part of the overall migration process.
See https://atproto.com/guides/account-migration for a discussion of the process at the protocol level. See https://whtwnd.com/bnewbold.net/3l5ii332pf32u for a breakdown of both the automated, and step by step process via `goat`. It does not go into the details of switching to self managed, but it basically requires crafting your new PLC document, sending that one to the old PDS to sign, and then submitting the result. There are manual PLC signing, and submission commands available as `goat plc` subcommands, for use once you have manual control.
The fact that BlueSky runs the PLC central server is supposed to be fixed by them creating a swiss association to run and control it instead, but while they announced this, it is unclear if it went anywhere.
If you migrate to a self hosted PDS using the all-in-one migration `goat account migrate` command, it will temporarily change your handle to a subdomain of your new PDS, and leave the new PDS managing the PLC. You can instead perform each step manually via goat or raw API calls, either of which would let you transition to direct PLC key management, and/or a new domain based handle as a single atomic plc update, as part of the overall migration process.
See https://atproto.com/guides/account-migration for a discussion of the process at the protocol level. See https://whtwnd.com/bnewbold.net/3l5ii332pf32u for a breakdown of both the automated, and step by step process via `goat`. It does not go into the details of switching to self managed, but it basically requires crafting your new PLC document, sending that one to the old PDS to sign, and then submitting the result. There are manual PLC signing, and submission commands available as `goat plc` subcommands, for use once you have manual control.
> The fact that BlueSky runs the PLC central server is supposed to be fixed by them creating a swiss association to run and control it instead, but while they announced this, it is unclear if it went anywhere.
That I didn't know! So... Basically the whole solution is still "trust me bro"?
That I didn't know! So... Basically the whole solution is still "trust me bro"?
This more or less answered my question in exactly the way I was dreading.
The option to register and manage PLC rotation keys should be built into the Bluesky Appview itself, sitting right next to the existing option to verify a domain with your did:plc string. Having the option only exist as a command line tool means most people aren't going to use it and third-party PDS hosts are going to be a pain in the ass to use for people with data already on Bluesky's PDS.
I'm also not happy about the existence of the PLC directory at all, mostly because it's not really explained all that well in the Bluesky interface. I assumed PDSes were just identified by their domain name (like a Mastodon instance is) - and while that is an option with did:web, it's not the default option, and you cannot migrate an identity between PLC and DNS governance. Hopefully that will change.
The option to register and manage PLC rotation keys should be built into the Bluesky Appview itself, sitting right next to the existing option to verify a domain with your did:plc string. Having the option only exist as a command line tool means most people aren't going to use it and third-party PDS hosts are going to be a pain in the ass to use for people with data already on Bluesky's PDS.
I'm also not happy about the existence of the PLC directory at all, mostly because it's not really explained all that well in the Bluesky interface. I assumed PDSes were just identified by their domain name (like a Mastodon instance is) - and while that is an option with did:web, it's not the default option, and you cannot migrate an identity between PLC and DNS governance. Hopefully that will change.
If you don't like BlueSky managing your keys, the alternative to did:plc is did:web. Unfortunately, afaiu, it's not possible to migrate[0]. If this is something you really care about, and you trust yourself to manage your own private keys, you should probably bite the bullet and do it now. Make a pinned post on the old account to point to the new one.
That's the one part you can't migrate; everything else you can change while retaining your followers, posts, etc.
Setting your handle to a domain name via DNS[1] is intended to be easy for non-technical users (especially with registrars adding one-click forms for doing so) and also decoupled from actual PDS hosting. Many users just want their handle to reflect their identity on the web, and are ok trusting BlueSky to host their PDS for free.
Migrating to a new PDS is possible in both the cooperative case[2] or in the adversarial case[3]. The gist is that A: you should take regular backups by exporting your account data, and B: if you're using did:plc instead of did:web, you should register a backup key that has a higher priority than the key held by your PDS, so a malicious PDS can't simply migrate you back.
[0] https://github.com/bluesky-social/atproto/discussions/2705
[1] Alternatively there's an option for HTTP handle resolution instead via `/.well-known/atproto-did`
[2] https://atproto.com/specs/account#pds-account-migration
[3] https://www.da.vidbuchanan.co.uk/blog/adversarial-pds-migrat...
That's the one part you can't migrate; everything else you can change while retaining your followers, posts, etc.
Setting your handle to a domain name via DNS[1] is intended to be easy for non-technical users (especially with registrars adding one-click forms for doing so) and also decoupled from actual PDS hosting. Many users just want their handle to reflect their identity on the web, and are ok trusting BlueSky to host their PDS for free.
Migrating to a new PDS is possible in both the cooperative case[2] or in the adversarial case[3]. The gist is that A: you should take regular backups by exporting your account data, and B: if you're using did:plc instead of did:web, you should register a backup key that has a higher priority than the key held by your PDS, so a malicious PDS can't simply migrate you back.
[0] https://github.com/bluesky-social/atproto/discussions/2705
[1] Alternatively there's an option for HTTP handle resolution instead via `/.well-known/atproto-did`
[2] https://atproto.com/specs/account#pds-account-migration
[3] https://www.da.vidbuchanan.co.uk/blog/adversarial-pds-migrat...
Feel like alot has happened since (2023). Mastodon/fediverse didn't take off in the way many thought it might at the time, with various silo/controversies, limitations on network effect, and general public uptake dwindling. Acknowledging that a good chunk of the public wants a centralized service is a thing (despite all the problems with that down the road etc etc). Some like it and have found their community on various servers, good. Meanwhile AT Proto has put a lot of work into getting devs on board with building things on the protocol etc and a snazzy new website recently https://atproto.com/. Not arguing that Bluesky is wildly successful, with stagnating growth etc but as with fediverse, many have found community there as well. But again, since 2023, there has been change and developments as far as people interested in external PDS etc putting the work in (Eurosky, Blacksky etc). Not even mentioning Meta's Threads, with again, some finding community there (tho how they even arrived there is one thing (instagram forced) and Fediverse integration or wider instance support is questionable).
All of these things require engineering and social work to grow and it's hit and miss to gather momentum and stickiness.
All of these things require engineering and social work to grow and it's hit and miss to gather momentum and stickiness.
Related:
The Fediverse Is Not the Way Forward
https://news.ycombinator.com/item?id=48785077
There are no instances in ATProto
https://news.ycombinator.com/item?id=48599515
The Fediverse Is Not the Way Forward
https://news.ycombinator.com/item?id=48785077
There are no instances in ATProto
https://news.ycombinator.com/item?id=48599515
I can easily install an ActivityPub server, with Glitch.
Show me the ATProto server that can integrate with BlueSky.
Show me the ATProto server that can integrate with BlueSky.
There is no "AT Proto server" - https://overreacted.io/there-are-no-instances-in-atproto/
Which is a misleading message, according to the recent HN discussion, https://news.ycombinator.com/item?id=48599515.
I don't think it's misleading at all, the comment you're looking to is.
People really do ask where "The AT Proto server is" as evidenced by this thread, and the really is no "AT Proto server" or "instance". AT Proto and BlueSky are a collection of services with no 1-1 relationship to a Mastodon or RSS server.
There's absolutely nothing misleading about that.
People really do ask where "The AT Proto server is" as evidenced by this thread, and the really is no "AT Proto server" or "instance". AT Proto and BlueSky are a collection of services with no 1-1 relationship to a Mastodon or RSS server.
There's absolutely nothing misleading about that.
Is there a relevant recent HN discussion or is this comment just in bad faith?
Sorry, I fixed the link.
> I can easily install an ActivityPub server, with Glitch.
Can you? The same Glitch that shut down last year? https://blog.glitch.com/post/goodbye-glitch
Regardless, ActivityPub and ATProto have different designs and goals. Your question is akin to comparing a helicopter and an airplane.
There's no such thing as a "ATProto server". How complicated it is, and the trade-offs it made are valid criticisms of it. It all depends on what exactly your goal is as a participant of a distributed social network.
Can you? The same Glitch that shut down last year? https://blog.glitch.com/post/goodbye-glitch
Regardless, ActivityPub and ATProto have different designs and goals. Your question is akin to comparing a helicopter and an airplane.
There's no such thing as a "ATProto server". How complicated it is, and the trade-offs it made are valid criticisms of it. It all depends on what exactly your goal is as a participant of a distributed social network.
What does ATProto run on, if not servers? Is it fully decentralised mesh P2P that runs on phones?
What makes up the ATProto is more than one type of server. Compared to ActivityPub where you just run a single Mastodon instance and you're set.
If the thing you want to own is your identity and data, you can fairly easy run a PDS yourself. If the thing you care about is different moderation decisions, you can run your own labeller (moderation system) or subscribe to another someone else has made.
If the thing you want to own is your identity and data, you can fairly easy run a PDS yourself. If the thing you care about is different moderation decisions, you can run your own labeller (moderation system) or subscribe to another someone else has made.
There's not one server instance type, there are different components to it
To 'own your data' you just need a PDS, which should be cheaper to run than an ActivityPub server
To build an app you need some of the more expensive parts
To 'own your data' you just need a PDS, which should be cheaper to run than an ActivityPub server
To build an app you need some of the more expensive parts
Never used it, but I've seen some praise for Snac as an easy to deploy activitypub server
https://codeberg.org/grunfink/snac2
https://codeberg.org/grunfink/snac2
Is run your own pds good enough? Or you want your own view?
The answer here would be "there's no such thing as a generic "server" like in ActivityPub because it's split into different components, of which a PDS is only one".
Honestly my main question here is "If you disagree with various ActivityPub instances' defederations, you can get around this by starting your own instance that federates with everything; is there an equivalent for bypassing Bluesky's moderation decisions?"
Honestly my main question here is "If you disagree with various ActivityPub instances' defederations, you can get around this by starting your own instance that federates with everything; is there an equivalent for bypassing Bluesky's moderation decisions?"
A PDS? Here: https://blog.bront.rodeo/setting-up-your-own-pds/
Want your own AppView so you can have nekusar.net and post your messages and people on BSky see it ? https://github.com/blacksky-algorithms/atproto
ActivityPub zealots would do well to calm down for one second, this can't be good for your heart man.
Want your own AppView so you can have nekusar.net and post your messages and people on BSky see it ? https://github.com/blacksky-algorithms/atproto
ActivityPub zealots would do well to calm down for one second, this can't be good for your heart man.
Well actually, that's not what an AppView is for.
If you just want to post messages on your website that get syndicated to BlueSky (as blog post links or full threads or whatever) you could have your website server make API calls to your PDS (whether that's self-hosted or not).
If you're talking about building your own custom BlueSky app, "AppView" is not synonymous with "viewer app"; basically it's an "AppView" because it provides a "view" of the network necessary to power an end user "app". I.e. it holds a copy of every single post, repost, and like, so you don't have to. Your custom app would simply make requests to the logged-in user's PDS, which routes most of those requests to that user's preferred AppView.
If you just want to post messages on your website that get syndicated to BlueSky (as blog post links or full threads or whatever) you could have your website server make API calls to your PDS (whether that's self-hosted or not).
If you're talking about building your own custom BlueSky app, "AppView" is not synonymous with "viewer app"; basically it's an "AppView" because it provides a "view" of the network necessary to power an end user "app". I.e. it holds a copy of every single post, repost, and like, so you don't have to. Your custom app would simply make requests to the logged-in user's PDS, which routes most of those requests to that user's preferred AppView.
Huge fan of this concept.
[deleted]
[0] https://dwebcamp.org