3 ms·

I still don't understand how this project meaningfully addresses the problem of identity and data ownership. When it come to identities, either you have your o

I still don't understand how this project meaningfully addresses the problem of identity and data ownership. When it come to identities, either you have your own domain, or you use someone else's domain (say, Bluesky). Most people don't have domains, and so their identity will be owned by a third party. You also have the same problem when it comes to the data itself. The moment Bluesky or some other server bans you, your repo is shut down and you lose the ability to move the data somewhere else. In short, this is exactly like email. Unless you have your own domain and server you don't control anything.

password4321 1y ago
At least with email you can own a PGP/SMIME key and take it elsewhere, right? Isn't this something similar with ATproto?
- danabramov 1y ago
  Yes, see here: https://news.ycombinator.com/item?id=45471337 https://news.ycombinator.com/item?id=45471337. You can change your domain with no cooperation from whoever owns your current domain. And you can change your host, provided you have a backup of your data. (If the old hosting doesn't cooperate, you'd also need a rotational key.)
athrowaway3z 1y ago
I'm not a user, but I do think there is a need for these type of schemes. Approximately 0% of email users could change email host, and prove their identity between the old messages and the new messages. The value is it caps bluesky's "window of abuse". Platforms like Facebook or Twitter have dialed up the enshitification far beyond what I find acceptable, but many people are still on there. A competitor to bluesky can decide how to approach it. Like staying (partially) compatible, and decide to compete on UI, repo storage, or user admin.
solatic 1y ago
> Most people don't have domains, and so their identity will be owned by a third party. Indeed, and as a result, such users will always be vulnerable to specific risks like sudden bans, i.e. when the hosting service becomes adversarial. The only full protection is to own your own domain off a neutral TLD, with protocols that use DNS to describe how traffic should be routed. But, because most users don't have domains (as you pointed out), the state-of-the-art can still be improved upon with partial flexibility and protections, when the hosting service is cooperative. This project allows people to keep their Bluesky handle (because they don't own a domain) while (hypothetically) moving their data hosting to a different provider, unlike current Big Social where your data is stuck on Facebook/X/Instagram/TikTok/YouTube forever. Bluesky has an interest in this because it also allows people to set up their own handle and move their hosting to Bluesky. Sometimes we improve upon the existing state of the art not by delivering perfect solutions, but by delivering improvements upon limitations that we accept as a given (like the fact that most users will not set up their own domains).
- braebo 1y ago
  Nobody owns their domain — it still bugs me that we just lease them on yearly renewals by the good grace of the anointed registrars who may, at the will of governments or through sheer negligence, relieve us of such “ownership”.
- danabramov 1y ago
  I responded to this here (https://news.ycombinator.com/item?id=45471337 https://news.ycombinator.com/item?id=45471337) but I want to emphasize this: your domain is "just" a handle. If something happens to it, you still control your identity, so you can point it at a different domain. Apps just display "invalid handle" instead of your handle but your posts/follows/data stay intact. You can go through a "change handle" flow then and fix it. Unlike with web redirects, you don't need cooperation from whoever owns the old domain because it's the DID Document that controls which handle you use, and you still control the DID Document even if you lose your handle. (That's part of what my article tried to explain by showing the flow: domain is resolved to DID, DID is resolved to hosting, links are stored with the DID.) When you change your handle, all your followers/posts/etc stay with you, it just seamlessly updates in the apps you use.
astrobe_ 1y ago
Owning a private key is the best way to prove your identity. As for hosting, I think BitTorrent is the most rock-solid? So maybe store your content in a Git repo, sign your commits, and publish on Torrent. And NNTP or RSS to notify users/followers of updates? Problems though are discoverability and passivity (e.g. no user comments from blogs etc.).
- danabramov 1y ago
  That's more or less how AT works, minus the Torrent part. There's a private key you own (which is normally held on your hosting but you can also add a "higher priority" key that would override that one if your relationship with your hosting sours). The updates are broadcasted by WebSockets but you can think of it similar to RSS. The repo is MST but that's not too far from Git. The commits are signed. The publishing is done on traditional web though.
danabramov 1y ago
Neither of these is quite right. In AT, data is tied to identity (DID), not handles or hosting. That’s what my article tried to explain. If you lose the “handle” domain, all it means is that you won’t have a valid handle (which apps will tell you about) but your posts will remain up (they’re still addressable by your DID, which is how apps look things up). In the Bluesky app, for example, it would say “invalid handle” instead of your username. However, it’ll work. It’s the same situation as what happens if your domain expires or you delete your records. Your data is still there, you’re still “followed“ by the same people, etc. A handle is just an alias. All you’ll need to do is to change the handle, thereby attaching a new domain, through any app that has the “change handle” flow. (It’s enough to have one app that gives you free ones.) With hosting, it is similar (although there are barriers which need to be lowered). If your repo shuts down, you absolutely can move it somewhere else provided that you have a backup of it. Backups are trivial to automate on AT so this is something I expect hosting providers to offer. There are already third-party apps that regularly do backups for you. And you can export your repository from some clients as well (eg from the official Bluesky client). In the “happy” case, your hosting will cooperate with moving your repo to another host. See https://pdsmoover.com/info.html https://pdsmoover.com/info.html for the happy case. For the “unhappy” case where your old hosting doesn’t cooperate, you also can move if you saved a rotational key. See https://www.da.vidbuchanan.co.uk/blog/adversarial-pds-migration.html https://www.da.vidbuchanan.co.uk/blog/adversarial-pds-migrat.... This requires some technical knowledge today but you can imagine a backup solution having that feature also. And when your repo goes up again at a different host, the difference will be imperceptible to you or other users, since it's signed by the same identity. All your posts, followers, etc, will "come back" with no disruption or broken links. This is very different from email. Yes, there's some technical know-how in setting up protections if you expect to be adversarial to your hosting, but you do have that ability, and I expect with the AT ecosystem developing, it'll be much more user-friendly to set them up than it is today.
- Denvercoder9 1y ago
  > In AT, data is tied to identity (DID), not handles or hosting. But there's exactly two types of identity, one of which requires you to have a domain (did:web:), and the other relies on a centralized registry owned by a third party (did:plc:). Still the exact same problem.
BrandoElFollito 1y ago
> you have your own domain Until you don't. As opposed to a server you host (together with its data), for domains you are at the mercy of the registrar. This was one (tiny, to be honest) of the considerations I had when choosing a registrar in my country, we are under one legislation, so my hope is a bit higher to recover it if needed.
- extraduder_ire 1y ago
  For comparison, how does mastodon or activitypub in general deal with losing a domain name? It's included in every user's handle. I heard about that happening with a popular server under .af, but didn't see a follow up.
  - OneDeuxTriSeiGo 1y ago
    With atproto if you use did:web, if you lose or change your domain you are fucked. That's one of the main reason people say "don't use did:web". But with atproto using did:plc, if you lose your domain, your handle stops working but your account works just fine (since your actual account id is a did:plc identifier) and you just change the handle to a domain you have control of (or live without @s by refusing to set up a handle).
  - WhyNotHugo 1y ago
    Much like the protocol described in this article, Mastodon and ActivityPub also can’t handle losing control of the domain. Er, unless you rely on a centralised registry, but then you’re depending on their good will. You’re back to the same situation as using a centralised service.

password4321 1y ago

At least with email you can own a PGP/SMIME key and take it elsewhere, right? Isn't this something similar with ATproto?

danabramov 1y ago
Yes, see here: https://news.ycombinator.com/item?id=45471337 https://news.ycombinator.com/item?id=45471337. You can change your domain with no cooperation from whoever owns your current domain. And you can change your host, provided you have a backup of your data. (If the old hosting doesn't cooperate, you'd also need a rotational key.)

athrowaway3z 1y ago

I'm not a user, but I do think there is a need for these type of schemes. Approximately 0% of email users could change email host, and prove their identity between the old messages and the new messages. The value is it caps bluesky's "window of abuse". Platforms like Facebook or Twitter have dialed up the enshitification far beyond what I find acceptable, but many people are still on there. A competitor to bluesky can decide how to approach it. Like staying (partially) compatible, and decide to compete on UI, repo storage, or user admin.

solatic 1y ago

> Most people don't have domains, and so their identity will be owned by a third party. Indeed, and as a result, such users will always be vulnerable to specific risks like sudden bans, i.e. when the hosting service becomes adversarial. The only full protection is to own your own domain off a neutral TLD, with protocols that use DNS to describe how traffic should be routed. But, because most users don't have domains (as you pointed out), the state-of-the-art can still be improved upon with partial flexibility and protections, when the hosting service is cooperative. This project allows people to keep their Bluesky handle (because they don't own a domain) while (hypothetically) moving their data hosting to a different provider, unlike current Big Social where your data is stuck on Facebook/X/Instagram/TikTok/YouTube forever. Bluesky has an interest in this because it also allows people to set up their own handle and move their hosting to Bluesky. Sometimes we improve upon the existing state of the art not by delivering perfect solutions, but by delivering improvements upon limitations that we accept as a given (like the fact that most users will not set up their own domains).

braebo 1y ago
Nobody owns their domain — it still bugs me that we just lease them on yearly renewals by the good grace of the anointed registrars who may, at the will of governments or through sheer negligence, relieve us of such “ownership”.
danabramov 1y ago
I responded to this here (https://news.ycombinator.com/item?id=45471337 https://news.ycombinator.com/item?id=45471337) but I want to emphasize this: your domain is "just" a handle. If something happens to it, you still control your identity, so you can point it at a different domain. Apps just display "invalid handle" instead of your handle but your posts/follows/data stay intact. You can go through a "change handle" flow then and fix it. Unlike with web redirects, you don't need cooperation from whoever owns the old domain because it's the DID Document that controls which handle you use, and you still control the DID Document even if you lose your handle. (That's part of what my article tried to explain by showing the flow: domain is resolved to DID, DID is resolved to hosting, links are stored with the DID.) When you change your handle, all your followers/posts/etc stay with you, it just seamlessly updates in the apps you use.

astrobe_ 1y ago

Owning a private key is the best way to prove your identity. As for hosting, I think BitTorrent is the most rock-solid? So maybe store your content in a Git repo, sign your commits, and publish on Torrent. And NNTP or RSS to notify users/followers of updates? Problems though are discoverability and passivity (e.g. no user comments from blogs etc.).

danabramov 1y ago
That's more or less how AT works, minus the Torrent part. There's a private key you own (which is normally held on your hosting but you can also add a "higher priority" key that would override that one if your relationship with your hosting sours). The updates are broadcasted by WebSockets but you can think of it similar to RSS. The repo is MST but that's not too far from Git. The commits are signed. The publishing is done on traditional web though.

danabramov 1y ago

Neither of these is quite right. In AT, data is tied to identity (DID), not handles or hosting. That’s what my article tried to explain. If you lose the “handle” domain, all it means is that you won’t have a valid handle (which apps will tell you about) but your posts will remain up (they’re still addressable by your DID, which is how apps look things up). In the Bluesky app, for example, it would say “invalid handle” instead of your username. However, it’ll work. It’s the same situation as what happens if your domain expires or you delete your records. Your data is still there, you’re still “followed“ by the same people, etc. A handle is just an alias. All you’ll need to do is to change the handle, thereby attaching a new domain, through any app that has the “change handle” flow. (It’s enough to have one app that gives you free ones.) With hosting, it is similar (although there are barriers which need to be lowered). If your repo shuts down, you absolutely can move it somewhere else provided that you have a backup of it. Backups are trivial to automate on AT so this is something I expect hosting providers to offer. There are already third-party apps that regularly do backups for you. And you can export your repository from some clients as well (eg from the official Bluesky client). In the “happy” case, your hosting will cooperate with moving your repo to another host. See https://pdsmoover.com/info.html https://pdsmoover.com/info.html for the happy case. For the “unhappy” case where your old hosting doesn’t cooperate, you also can move if you saved a rotational key. See https://www.da.vidbuchanan.co.uk/blog/adversarial-pds-migration.html https://www.da.vidbuchanan.co.uk/blog/adversarial-pds-migrat.... This requires some technical knowledge today but you can imagine a backup solution having that feature also. And when your repo goes up again at a different host, the difference will be imperceptible to you or other users, since it's signed by the same identity. All your posts, followers, etc, will "come back" with no disruption or broken links. This is very different from email. Yes, there's some technical know-how in setting up protections if you expect to be adversarial to your hosting, but you do have that ability, and I expect with the AT ecosystem developing, it'll be much more user-friendly to set them up than it is today.

Denvercoder9 1y ago
> In AT, data is tied to identity (DID), not handles or hosting. But there's exactly two types of identity, one of which requires you to have a domain (did:web:), and the other relies on a centralized registry owned by a third party (did:plc:). Still the exact same problem.

BrandoElFollito 1y ago

> you have your own domain Until you don't. As opposed to a server you host (together with its data), for domains you are at the mercy of the registrar. This was one (tiny, to be honest) of the considerations I had when choosing a registrar in my country, we are under one legislation, so my hope is a bit higher to recover it if needed.

extraduder_ire 1y ago
For comparison, how does mastodon or activitypub in general deal with losing a domain name? It's included in every user's handle. I heard about that happening with a popular server under .af, but didn't see a follow up.
- OneDeuxTriSeiGo 1y ago
  With atproto if you use did:web, if you lose or change your domain you are fucked. That's one of the main reason people say "don't use did:web". But with atproto using did:plc, if you lose your domain, your handle stops working but your account works just fine (since your actual account id is a did:plc identifier) and you just change the handle to a domain you have control of (or live without @s by refusing to set up a handle).
- WhyNotHugo 1y ago
  Much like the protocol described in this article, Mastodon and ActivityPub also can’t handle losing control of the domain. Er, unless you rely on a centralised registry, but then you’re depending on their good will. You’re back to the same situation as using a centralised service.