Inspired by another recent post on ATProto I signed up for bsky, but all I see is endless American politics. I relentlessly click "less like this" but it doesn't seem to budge. Is this just what the platform is like? Being constantly barraged by the same predictable takes on today's bizarre overseas controversy is not very conducive to mental peace...
To add a (positive) point of comparison: The concept of multiple named "feeds" with various degrees of "algorithm-ness" to them, including ones largely controlled by the user's explicit signals, is something that Tumblr implemented in a fascinating way.
IMO Tumblr's constraints were quite unique in the social space: a userbase that one could quite naturally (and with a badge of pride) describe as "rabid" in its expectations that their historical dash experience be preserved in much the way it had been in the early 2010s (with or without a ball pit included); a legacy PHP codebase without the benefits of Meta's resources; and ownership under various companies throughout the years that (from an outsider's perspective) did not prioritize algorithmic optimization of its feeds as a C-suite-driven priority, unlike practically every other social network at scale.
The result is systems like https://github.com/Automattic/stream-builder that enabled Tumblr product teams to define Following, For You, Your Tags, Popular etc. feeds with complex but deterministic and predictable specifications, where each feed would round-robin each slot from a mixture of well-defined component streams.
I'm not as familiar with Bluesky's implementation, but I imagine it has a similarly predictable algorithm for these user-defined feeds.
I would encourage anyone building any kind of discovery experience to look at this repo, at least at its readme and guide, for inspiration. You can, and should, build magical experiences without needing to make your feed algorithms inscrutable. Not everything needs to be TikTok, and I think the world can be a bit more sane if we don't have that as our base assumption as engineers.
Hmm... I found a couple of accounts I liked and completely removed "Discovery" tab and then I extend the followers list organically by the shared interactions (see some interesting comment in followers posting) or by following account from blogs/websites…
IMHO this is how "social-media" should work instead of being forced-feed with some automatic crap
It does thankfully have a functioning non-algorithmic feed that only shows who you've followed, which I feel is the only way to maintain sanity on any of these platforms.
I imagine myself switching over to that pretty quickly if I do stick with the platform (I also use YouTube that way) but that doesn't address the discovery problem.
It's just really sad that you give people a platform to say whatever they want to the world and most people seem to have little to say beyond "here's what made me unhappy today"...
I made the mistake of selecting "art" as one of my topics of interest during the account setup process and my feed is full of drawings of furries and comic book superhero nonsense.
I tried bsky for one year, and I agree that I was getting mostly American politics… which as a European is just noise for me.
I went back to Mastodon, it’s much better to follow tech people.
And feedly for RSS to get all the news I can dream of.
Not sure what the point of Bluesky is anymore, it’s just twitter but on the left side of politics. Sad, the tech stack was interesting as an evolution of Nostr.
I would recommend not using an algorithmic home feed.
I don't know how it is on Bluesky, but on Mastodon I only see posts from people I follow, including posts they've boosted. When I see interesting boosts or replies, I check if those are people I want to follow. Works great.
Also go to Settings > Contents and Media > Your Interests and turn off News and Politics. If you were wanting news and politics but just non-American I don't have suggestions.
Do you follow anyone? If so, who? If not, you're in an edge-case for users who haven't yet started following anyone.
Follow people. Carefully curate who you follow. Your feed will be exactly what you pick. It's a lot like old-school Twitter before it went algorithmic.
Unpopular opinion: you do not need Twitter-style social media in your life. In fact, it is actively harmful for your mental well-being.
I signed up for bsky, had the same experience, and realised my life is qualitatively better without constant exposure to manufactured drama, ragebait and American politics. I deleted my account. Life is still meh, but could be much worse.
Use the "Following" feed and select what you want to see as a most recent of what you've followed. The client will stay on the Following feed until you logout. It should be the default, but you aren't forced into an algorithmic feed on bsky.
It's not just who you follow, it feels like the way people post changed as well: I follow mostly the same people as I did on twitter but most act different now, more hot takes and opinions, less signal. To be honest I'm not fond of the popularity contest vibe, but that's irrelevant to the protocol itself.
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.
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 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-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.
> 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.
You DID has to be hosted to some provider. Whoever controls that domain controls to which location your content resolves. There’s one extra layer of indirection, but the exact same issue is still there.
If you own the domain, that’s fine. If it’s a thirst party domain and they refuse to cooperate: you’re screwed.
> 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).
I responded to this here (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.
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”.
Who knows what will happen with at, but with e-mail owning your own domain is no longer sufficient to participate in e-mail federation. I have a domain, which I use for e-mail and multiple times per year I need to use gmail to get reliable delivery of e-mail.
My mom is even caught in a Kafkaesque bind with one company where they told her that to access her account, she needs to change her e-mail, as they refuse to deliver to domains registered with GoDaddy (yes, registered, regardless of e-mail host), but she can't log in without getting a security code to her e-mail.
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.
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.).
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.
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.)
Excellent explanation as always from Dan, and timely with the latest news from Bluesky on moving the PLC management.
We picked the same DID systems for https://fair.pm/ to decentralise WordPress plugin distribution (and general management for user-facing packages; think App Store rather than Cargo).
The Bluesky folks (especially Bryan) were super helpful in helping us out - even shipping Ed25519 key support so we could use libsodium.
(We’re designing our protocol on top of DIDs and using Bluesky’s stackable moderation, but chose not to use atproto directly - but the great thing is that DIDs are a W3C standard, and PLC isn’t tied to atproto.)
Not gonna lie I can't resist asking for more info on who is "we" (and a link with more about the "what"), it sounds like a technical solution is coming down the pipe vs. all the WordPress drama.
Isn’t PLC (a did method created by bluesky) tied to bluesky (or some other central authority)?
Why do they call it a did when it’s centralised?
As did:plc isnt portable, why didn’t they just use did:web, and decorate the identity docs with PLC-like behaviour?
Why isn’t the method-specific-id part of the did something deterministic/portable, like a hash of a public key that can at least permit some revolver-driven portability?
Why didn’t they use some mechanism for decentralisation, like a DHT (e.g. did:pkarr)?
It seems to me that PLC is thinly veiled attempt for another master to exert control.
I think they're saying using PLC as an identity method is not tied to buying into the whole AT spec. So you can use it for something else.
>Isn’t PLC tied to bluesky (or some other central authority)?
Yes, PLC is currently tied to Bluesky, and is in the process of moving out into a separate legal entity (https://docs.bsky.app/blog/plc-directory-org). It would indeed remain centralized.
>Why didn’t they use some mechanism for decentralisation, like a DHT (e.g. did:pkarr)?
>did:dht is interesting and maybe could work, for atproto, but there have been many DHT projects in the history of decentralized computing, and only a small handful have really worked out. AKA, been resilient to abuse, attacks, neglect, etc, over years and decades. magnet links are cool but kind of the exception to the rule. I think if the W3C standardized did:dht it could be a real contender, but somebody needs to carry the flag and demonstrate it working "in real life" with millions of users, and I suspect that will be difficult, and I would not expect Bluesky to lead that charge (we already have our own pet DID method to maintain and support).
DIDs are a W3C standard, not invented by Bluesky. The PLC method specifically is currently hosted by them, but they’re working on moving it, as Dan says.
The method specific ID for PLC is a hash of the genesis operation, so it’s not just an arbitrary ID that the PLC server creates.
To me this is where the entire model breaks down and becomes 100% centralized.
At the very least, I would expect that there would be a configurable list of such trusted directories, entirely decoupled from the protocol itself, similarly to DNS roots or CAs.
And few enough people will do that so Bluesky can just kill off support for it when the service becomes popular and they move to the extraction phase without much opposition.
Remember all the chat services that supported XMPP before they killed that? Same level of guarantee here. If most users are expected to choose the centralized option it might as well be the only one.
So any server storing such at:// links will need to do some DNS/HTTPS dance to get the canonical representation, or permalink as the author calls it.
Doesn't that make it quite fragile without functioning DNSSEC?
Haven't really thought it through but my immediate reaction is DNS poisoning seems like it could do some damage here, allowing bad actors to post in my name, given the public key is part of the DID that you found from the DNS entry. Or?
DNS poisoning is a concern in some situations, but not always.
The common case with at:// strings is to put in the DID in the "authority" slot, not the handle. In that case, whether resolving a did:plc or did:web, there are regular HTTPS hostnames involved, and web PKI. So the DNS poisoning attacks are the same as most web browsing.
If you start from a handle, you do use DNS. If the resolution is HTTPS well-known, then web PKI is there, but TXT records are supported and relatively common.
What we currently recommend is for folks to resolve handles server-side, not on end devices. Or if they do need to resolve locally, use DoH to a trusted provider. This isn't perfect (server hosting environments could still be vulnerable to poisoning), but cuts the attack surface down a lot.
DNSSEC is the current solution to this problem. But we feel like mandating it would be a big friction. We have also had pretty high-profile incidents in our production network caused by DNSSEC problems by third parties. For example, many active US Senators use NAME.senate.gov as a form of identity verification. The senate.gov DNS server uses DNSSEC, and this mostly all worked fine, until their DNSSEC configuration broke, which resulted in dozens of senators showing up in the Bluesky app as "invalid handle". This was a significant enough loss of trust in the DNSSEC ecosystem that we haven't pushed on it since. I think if we saw another application-layer protocol require it, and get successful adoption, we'd definite reconsider.
They'd need the private key to post as you. The DNS record just points to where the DID document is, but there's a verification check that the DID document points back, and this is automatically performed as a part of the resolution process.
DNSSEC would add additional security around DNS record changes, but not having it wouldn't allow someone to impersonate you, because your server would need to agree with that.
This is a bit beyond my understanding (I'll ping someone who may be able to answer), but https://atproto.com/specs/handle#dns-txt-method mentions "DNSSEC is not required" (though I'm also not sure that's what you're asking).
>allowing bad actors to post in my name, given the public key is part of the DID that you found from the DNS entry. Or?
DNS only resolves the Handle->DID, but you still need to verify DID->Handle mapping by getting the DID Document. It's bidirectional.
I guess I need to study that in more detail, as I don't immediately see how it's preventing DNS attacks.
> DNS only resolves the Handle->DID, but you still need to verify DID->Handle mapping by getting the DID Document. It's bidirectional.
Yes but if I've already hijacked the DNS to point to my own DID, what's stopping me from saying I go by your handle?
Sure older posts wouldn't verify, but a new post would be signed by the keypair I've put in the DID I hijacked, no? Or is that some other key in the DID?
New to AT so perhaps this is a non-issue. Main concern of mine is that DNSSEC seems to not have a very bright future, so not something new stuff should rely on IMHO.
In short, at:// protocol lets you build apps that can deeply interop and query/embed each other's information, allow the user to have a shared user identity between apps, and allow the user to self-host their content (or move their hosting) without impacting the apps. It does this by giving bits of JSON permanent URIs that aren't tied to a specific user handle or hosting server, but instead are rooted in identity. The article describes how that works (and what an "identity" is) in technical detail.
Here's a concrete example: a blogging app (https://leaflet.pub) automatically "sees" mentions of a Leaflet post on a different microblogging app (https://bsky.app) and can display them: https://bsky.app/profile/o.simardcasanova.net/post/3luujudlr.... This is not done by hitting an API; it's just that both apps aggregate the same information from the open network into their respective databases.
I'm pretty new to the at:// protocol, and I like what I'm reading, thanks for the write-up.
To your "This is not done by hitting an API" point; if I understand correctly, I'd argue that the _endpoints_ that you detail in your post _are_ the API. The whole point is that there's no single _central_ API, but each server that wants to be part of the network participates by hosting an API that meets the standard outlined in the protocol.
In a way it's semantics, but I'd be interested in yours thoughts on that. To either correct or confirm my understanding.
But besides even whether it would ever make business sense, I worry about basic things like:
- If you own your data, can't you change it at any time? I can make perfectly reasonable posts that lots of people agree with, then change it to vile stuff. Even if existing sites at the time store hashes and prevent updates, a new site loading the post will never know it was once different.
- How are things like upvotes tracked? If every upvote is an object stored by the person upvoting, how do you even find the people upvoting? And doesn't it become trivial to create tons of fake profiles upvoting everything you do?
- And how is moderation/spam even handled? Now if sites are supposed to be showing replies to posts made from everyone across any platform, not just their own, how is moderation handled when you don't know anything about these accounts making replies?
I just don't understand how all of the necessary work around transparency, accountability, moderation, and spam can be done in a world where users store their own data, and therefore can fake their own data.
Why not publish the changes too? The data of the resulting json can include whatever you wish. That data is your data. So if an app developer wants to include the history of changes, that would be the place to do it. Or link to previous at:// addresses for it. Walk it back like a linked list.
As for the identity moderation part, if you read up about DID, it tells you how to know who they are and you can block them or do whatever you need to do. The point isn’t that this is some blockchain, it’s just a federated method to share data when you own the data. Poison well attacks aside.
In the end, it’s a way to say this person, generated this data, at this location, in case you’re interested. If you care about the things you mentioned, you might not be interested at all.
Because you are being adversarial and trying to trick people.
> if you read up about DID, it tells you how to know who they are
But it doesn't tell you're they're not a spammer. I don't see anything about reputation.
> in case you’re interested
But that's the point. You're interested in legitimate upvotes to try to find useful content. You're not interested in spam upvotes. In a decentralized world, how does anyone tell the difference?
There is a hash that is stored with the record, and a real permalink is called a "strongRef". Dan did not mention this in his permalink section, hopefully he reads this and adds some more words to his post. You normally store a strongRef and can then detect when a record content no longer matches what you expect. Bluesky does not support edits specifically for the reason you mention, adversarial edits, i.e. the social part is hard, the technical not so much.
I wrote up some experiments with record editing and permalink I did:
People are talking of turning both labelers and feedgens into DAGs (i.e. how do we combine each and use set operations to make interesting combinations)
> can fake their own data
Fake can be seen subjectively here, if it's my data and I can put anything I want in there, what is fake about it?
If it's about changes, the CID hash is how we know if a record has been altered
I'm still left wondering how you prevent the problem of somebody creating hundreds of accounts to upvote all their own posts.
I see how the labelers work for content, but I don't see anything about user reputation. So I'm still struggling to understand what the protections are against bots? I'm struggling to understand how upvote/recommendation numbers can be trusted at all, when you want to see what's liked across the whole network and not just by your friends, but without it all being spam likes.
>> can fake their own data
> Fake can be seen subjectively here, if it's my data and I can put anything I want in there, what is fake about it?
So it seems like the hashes (cid) are a big help, thank you. Is there anything preventing you from backdating things? Making it look like you said something or posted a photo of something last month that you didn't actually until just now? Because that seems like the other big category of content faking.
To strongman the article, I imagine that's the reason behind:
> Bluesky is currently moving PLC to an independent legal entity in Switzerland to address some of these concerns. The AT community is also thinking and experimenting.
Readit News
I'd personally recommend the "For You" feed (https://bsky.app/profile/spacecowboy17.bsky.social/feed/for-...) which learns likes faster and doesn't push random content.
"Dev Trending" (https://bsky.app/profile/hawkticehurst.com/feed/dev-trending) is another good one.
IMO Tumblr's constraints were quite unique in the social space: a userbase that one could quite naturally (and with a badge of pride) describe as "rabid" in its expectations that their historical dash experience be preserved in much the way it had been in the early 2010s (with or without a ball pit included); a legacy PHP codebase without the benefits of Meta's resources; and ownership under various companies throughout the years that (from an outsider's perspective) did not prioritize algorithmic optimization of its feeds as a C-suite-driven priority, unlike practically every other social network at scale.
The result is systems like https://github.com/Automattic/stream-builder that enabled Tumblr product teams to define Following, For You, Your Tags, Popular etc. feeds with complex but deterministic and predictable specifications, where each feed would round-robin each slot from a mixture of well-defined component streams.
I'm not as familiar with Bluesky's implementation, but I imagine it has a similarly predictable algorithm for these user-defined feeds.
I would encourage anyone building any kind of discovery experience to look at this repo, at least at its readme and guide, for inspiration. You can, and should, build magical experiences without needing to make your feed algorithms inscrutable. Not everything needs to be TikTok, and I think the world can be a bit more sane if we don't have that as our base assumption as engineers.
IMHO this is how "social-media" should work instead of being forced-feed with some automatic crap
It's just really sad that you give people a platform to say whatever they want to the world and most people seem to have little to say beyond "here's what made me unhappy today"...
I went back to Mastodon, it’s much better to follow tech people.
And feedly for RSS to get all the news I can dream of.
Not sure what the point of Bluesky is anymore, it’s just twitter but on the left side of politics. Sad, the tech stack was interesting as an evolution of Nostr.
I don't know how it is on Bluesky, but on Mastodon I only see posts from people I follow, including posts they've boosted. When I see interesting boosts or replies, I check if those are people I want to follow. Works great.
Follow people. Carefully curate who you follow. Your feed will be exactly what you pick. It's a lot like old-school Twitter before it went algorithmic.
See: https://github.com/bluesky-social/feed-generator
I signed up for bsky, had the same experience, and realised my life is qualitatively better without constant exposure to manufactured drama, ragebait and American politics. I deleted my account. Life is still meh, but could be much worse.
Deleted Comment
Maybe it's not instant? Maybe it needs some time to generate and cache new results for you and the millions (?) of other users?
I use https://graze.social
Dead Comment
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.
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 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-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.
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.
If you own the domain, that’s fine. If it’s a thirst party domain and they refuse to cooperate: you’re screwed.
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).
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.
My mom is even caught in a Kafkaesque bind with one company where they told her that to access her account, she needs to change her e-mail, as they refuse to deliver to domains registered with GoDaddy (yes, registered, regardless of e-mail host), but she can't log in without getting a security code to her e-mail.
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.
I heard about that happening with a popular server under .af, but didn't see a follow up.
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.)
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.
We picked the same DID systems for https://fair.pm/ to decentralise WordPress plugin distribution (and general management for user-facing packages; think App Store rather than Cargo).
The Bluesky folks (especially Bryan) were super helpful in helping us out - even shipping Ed25519 key support so we could use libsodium.
(We’re designing our protocol on top of DIDs and using Bluesky’s stackable moderation, but chose not to use atproto directly - but the great thing is that DIDs are a W3C standard, and PLC isn’t tied to atproto.)
(More info on the linked site; I don’t want to hijack the thread too much.)
Deleted Comment
Isn’t PLC (a did method created by bluesky) tied to bluesky (or some other central authority)?
Why do they call it a did when it’s centralised?
As did:plc isnt portable, why didn’t they just use did:web, and decorate the identity docs with PLC-like behaviour?
Why isn’t the method-specific-id part of the did something deterministic/portable, like a hash of a public key that can at least permit some revolver-driven portability?
Why didn’t they use some mechanism for decentralisation, like a DHT (e.g. did:pkarr)?
It seems to me that PLC is thinly veiled attempt for another master to exert control.
>Isn’t PLC tied to bluesky (or some other central authority)?
Yes, PLC is currently tied to Bluesky, and is in the process of moving out into a separate legal entity (https://docs.bsky.app/blog/plc-directory-org). It would indeed remain centralized.
>Why didn’t they use some mechanism for decentralisation, like a DHT (e.g. did:pkarr)?
AFAIK Bluesky is open to supporting more did methods in atproto in the future as long as they can act as permanent identifiers. I found a response from Bryan about `did:dht` here: https://github.com/bluesky-social/atproto/discussions/2705#d...:
>did:dht is interesting and maybe could work, for atproto, but there have been many DHT projects in the history of decentralized computing, and only a small handful have really worked out. AKA, been resilient to abuse, attacks, neglect, etc, over years and decades. magnet links are cool but kind of the exception to the rule. I think if the W3C standardized did:dht it could be a real contender, but somebody needs to carry the flag and demonstrate it working "in real life" with millions of users, and I suspect that will be difficult, and I would not expect Bluesky to lead that charge (we already have our own pet DID method to maintain and support).
The method specific ID for PLC is a hash of the genesis operation, so it’s not just an arbitrary ID that the PLC server creates.
If you lose your domain, you lose your account. The PLC doesn't have this particular issue
To me this is where the entire model breaks down and becomes 100% centralized.
At the very least, I would expect that there would be a configurable list of such trusted directories, entirely decoupled from the protocol itself, similarly to DNS roots or CAs.
Remember all the chat services that supported XMPP before they killed that? Same level of guarantee here. If most users are expected to choose the centralized option it might as well be the only one.
Doesn't that make it quite fragile without functioning DNSSEC?
Haven't really thought it through but my immediate reaction is DNS poisoning seems like it could do some damage here, allowing bad actors to post in my name, given the public key is part of the DID that you found from the DNS entry. Or?
The common case with at:// strings is to put in the DID in the "authority" slot, not the handle. In that case, whether resolving a did:plc or did:web, there are regular HTTPS hostnames involved, and web PKI. So the DNS poisoning attacks are the same as most web browsing.
If you start from a handle, you do use DNS. If the resolution is HTTPS well-known, then web PKI is there, but TXT records are supported and relatively common.
What we currently recommend is for folks to resolve handles server-side, not on end devices. Or if they do need to resolve locally, use DoH to a trusted provider. This isn't perfect (server hosting environments could still be vulnerable to poisoning), but cuts the attack surface down a lot.
DNSSEC is the current solution to this problem. But we feel like mandating it would be a big friction. We have also had pretty high-profile incidents in our production network caused by DNSSEC problems by third parties. For example, many active US Senators use NAME.senate.gov as a form of identity verification. The senate.gov DNS server uses DNSSEC, and this mostly all worked fine, until their DNSSEC configuration broke, which resulted in dozens of senators showing up in the Bluesky app as "invalid handle". This was a significant enough loss of trust in the DNSSEC ecosystem that we haven't pushed on it since. I think if we saw another application-layer protocol require it, and get successful adoption, we'd definite reconsider.
DNSSEC would add additional security around DNS record changes, but not having it wouldn't allow someone to impersonate you, because your server would need to agree with that.
>allowing bad actors to post in my name, given the public key is part of the DID that you found from the DNS entry. Or?
DNS only resolves the Handle->DID, but you still need to verify DID->Handle mapping by getting the DID Document. It's bidirectional.
I guess I need to study that in more detail, as I don't immediately see how it's preventing DNS attacks.
> DNS only resolves the Handle->DID, but you still need to verify DID->Handle mapping by getting the DID Document. It's bidirectional.
Yes but if I've already hijacked the DNS to point to my own DID, what's stopping me from saying I go by your handle?
Sure older posts wouldn't verify, but a new post would be signed by the keypair I've put in the DID I hijacked, no? Or is that some other key in the DID?
New to AT so perhaps this is a non-issue. Main concern of mine is that DNSSEC seems to not have a very bright future, so not something new stuff should rely on IMHO.
Deleted Comment
Deleted Comment
This is chicken and egg stuff. I don't get it and I've picked on the intro of the explainer. Why would I want "the JSON"?
Yes, I did skim the "read this" link.
It's not for me.
In short, at:// protocol lets you build apps that can deeply interop and query/embed each other's information, allow the user to have a shared user identity between apps, and allow the user to self-host their content (or move their hosting) without impacting the apps. It does this by giving bits of JSON permanent URIs that aren't tied to a specific user handle or hosting server, but instead are rooted in identity. The article describes how that works (and what an "identity" is) in technical detail.
Here's a concrete example: a blogging app (https://leaflet.pub) automatically "sees" mentions of a Leaflet post on a different microblogging app (https://bsky.app) and can display them: https://bsky.app/profile/o.simardcasanova.net/post/3luujudlr.... This is not done by hitting an API; it's just that both apps aggregate the same information from the open network into their respective databases.
To your "This is not done by hitting an API" point; if I understand correctly, I'd argue that the _endpoints_ that you detail in your post _are_ the API. The whole point is that there's no single _central_ API, but each server that wants to be part of the network participates by hosting an API that meets the standard outlined in the protocol.
In a way it's semantics, but I'd be interested in yours thoughts on that. To either correct or confirm my understanding.
This is oversimplified but is a decent question to prompt an explanation for someone new to DNS, HTTP, TLS, etc.
But besides even whether it would ever make business sense, I worry about basic things like:
- If you own your data, can't you change it at any time? I can make perfectly reasonable posts that lots of people agree with, then change it to vile stuff. Even if existing sites at the time store hashes and prevent updates, a new site loading the post will never know it was once different.
- How are things like upvotes tracked? If every upvote is an object stored by the person upvoting, how do you even find the people upvoting? And doesn't it become trivial to create tons of fake profiles upvoting everything you do?
- And how is moderation/spam even handled? Now if sites are supposed to be showing replies to posts made from everyone across any platform, not just their own, how is moderation handled when you don't know anything about these accounts making replies?
I just don't understand how all of the necessary work around transparency, accountability, moderation, and spam can be done in a world where users store their own data, and therefore can fake their own data.
As for the identity moderation part, if you read up about DID, it tells you how to know who they are and you can block them or do whatever you need to do. The point isn’t that this is some blockchain, it’s just a federated method to share data when you own the data. Poison well attacks aside.
In the end, it’s a way to say this person, generated this data, at this location, in case you’re interested. If you care about the things you mentioned, you might not be interested at all.
Because you are being adversarial and trying to trick people.
> if you read up about DID, it tells you how to know who they are
But it doesn't tell you're they're not a spammer. I don't see anything about reputation.
> in case you’re interested
But that's the point. You're interested in legitimate upvotes to try to find useful content. You're not interested in spam upvotes. In a decentralized world, how does anyone tell the difference?
There is a hash that is stored with the record, and a real permalink is called a "strongRef". Dan did not mention this in his permalink section, hopefully he reads this and adds some more words to his post. You normally store a strongRef and can then detect when a record content no longer matches what you expect. Bluesky does not support edits specifically for the reason you mention, adversarial edits, i.e. the social part is hard, the technical not so much.
I wrote up some experiments with record editing and permalink I did:
permalinks: https://verdverm.com/blog/permalinks-and-editing-on-whitewin...
editing: https://verdverm.com/blog/adding-record-editing-with-history...
> How are things like upvotes tracked?
You crawl the network to look for pointers and do something like: https://jazco.dev/2024/04/20/roaring-bitmaps/
> And how is moderation/spam even handled?
It's way cooler than any other system out there: https://bsky.social/about/blog/03-12-2024-stackable-moderati...
People are talking of turning both labelers and feedgens into DAGs (i.e. how do we combine each and use set operations to make interesting combinations)
> can fake their own data
Fake can be seen subjectively here, if it's my data and I can put anything I want in there, what is fake about it?
If it's about changes, the CID hash is how we know if a record has been altered
I'm still left wondering how you prevent the problem of somebody creating hundreds of accounts to upvote all their own posts.
I see how the labelers work for content, but I don't see anything about user reputation. So I'm still struggling to understand what the protections are against bots? I'm struggling to understand how upvote/recommendation numbers can be trusted at all, when you want to see what's liked across the whole network and not just by your friends, but without it all being spam likes.
>> can fake their own data
> Fake can be seen subjectively here, if it's my data and I can put anything I want in there, what is fake about it?
So it seems like the hashes (cid) are a big help, thank you. Is there anything preventing you from backdating things? Making it look like you said something or posted a photo of something last month that you didn't actually until just now? Because that seems like the other big category of content faking.
This all seems unnecessarily fragile.
> Bluesky is currently moving PLC to an independent legal entity in Switzerland to address some of these concerns. The AT community is also thinking and experimenting.
(The article has links there.)