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

It means that your identity is tied to the server. If you ever got tired of running your server and decided to just use someone else's server, you can not just bring your keys and make a DNS change to point to the new place.


Just because there isn't such a mechanism in use currently, doesn't mean that there's something preventing ActivityPub actors using the same type of DNS pointing to DID, or IRI mechanism ATProtocol is using.


There are some extensions proposed, but to this day all AP actors are controlled by the server. No ActivityPub software today is built in a way where the client can provide their own keys. They are all generated in the server.

Even the "Client-to-Server" AP spec is written in a way where the "client" does not interact with the outside web, but always initiates every interaction through the outbox hosted by the server.

I'm not saying this just for pedantry. I'm saying this because I actually wrote a server that implements ActivityPub according to the spec [0], and realized that identity portability is not possible unless you deliberately break away from the AP spec.

[0]: https://activitypub.mushroomlabs.com


I am not convinced that it can't be done. (Saying this also as someone that wrote a spec compliant ActivityPub server: https://github.com/mariusor/fedbox)

Nothing says you can't extend an actor to provide for a did: based identity which gets stored wherever you want to. I think the main dev of Mitra[1] is someone that's exploring very strongly in this direction.

[1] https://mitra.social/


I'd consider the effort of migrating the entire ecosystem to a fundamentally different identity resolution mechanism somewhat of a barrier.


Allowing for extensions to the current ActivityPub/ActivityStreams vocabulary is one of the tenants of the specification. Nothing says everyone must implement everything.


I don't see how this could be done in a backwards compatible way.

How would incompatible servers know to trust a server foo.com to publish posts for an account bar.com? How would they know where to look for bar.com's posts when their users search for it?


how many bluesky "servers" are there?


Look who is moving the goal posts!

We are talking about ActivityPub tying identity to the server. ATProto is designed from the ground to separate user data from your identity (through its Personal Data Servers), so the answer to your question is "many. There are many servers out there."

Bluesky has many issues (and I for one still think it has fundamental flaws that still make me prefer AP), but identity coupling is not one of them.


I think i just don't understand the distinction. I have a domain, so i set up my domain so i have an identity on bluesky. I'm with you on that part.

and then what? i can take my identity and do what with it? change PDS? but bluesky itself shows everyone that i am the same person?

i didn't move the goalposts, i just don't get the distinction everyone is making here with "identity", of course if i prove i own a domain i can verify, but i can do that on mastodon, too, I can add the below to my domain that will checkmark my username on mastodon. I assume if i move servers and want people to follow me, i will just do the same on that server, too; they know it's me because the service says so.

> <a rel="me" href="https://fosstodon.org/@picofarad">Mastodon</a>

that is all i have to do to prove i own that username on that instance - put that on a domain i own and add it to one of the user editable fields on my public profile.

so maybe you understand my confusion. i never received a bluesky invite nor do i want to pay (a couple mentions here of paying for it).

> Verifying your identity on Mastodon is for everyone. Based on open web standards, now and forever free. All you need is a personal website that people recognize you by. When you link to this website from your profile, we will check that the website links back to your profile and show a visual indicator on it. The link on your website can be invisible. The important part is rel="me" which prevents impersonation on websites with user-generated content. You can even use a link tag in the header of the page instead of <a>, but the HTML must be accessible without executing JavaScript.

i can also export all my followers, so when i join a new instance, i can direct message them all and let them know i've moved, and they can see it's the same person because the service says so, because i own the same domain.


> i can also export all my followers, so when i join a new instance, i can direct message them all and let them know i've moved

If ActivityPub had actually portable identities, you would be able to move instances without losing/moving your handle.

You as an user might have moved servers, but your identity did not.

How can we make an analogy? Let's say that you want to have a domain and you are hosting it on some cheap VPS provider. You just take your data, upload to their server and point the domain to their IP address. Let's say that six months later the cheap VPS goes down and you completely lose access to the server. You want to move. What do you do? You sign up to another VPS provider, upload your data (assuming you have backups) and you simply change the DNS to point to the IP address of the new server.

If you want to do that anything like that with ActivityPub, you can only do it at the server level. If you are a "mere" user on instance mastodon.one you do not own, you are at the mercy of the admin. You can not take "genewitch@mastodon.one" and use it as a handle anywhere else. Conversely, you can not go to mastodon.social and sign up with your own domain or any other method of authentication. The only way they can serve anything for you is if you use the handle they assigned you.

With ATProto, identity is based on DIDs (decentralized identifiers), so you can change your PDS without having to change your identity. You can have a handle under your own control and tell Bluesky to host it for you, and you don't need to ask permission to them in case you change your mind and decide to move elsewhere.




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

Search: