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...
For You is based on your likes. If you get an empty feed then you probably haven't liked anything yet. Try liking a couple of posts in Discover feed and get back to For You.
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"...
The real problem is the expectation of immediate discovery. People have gotten used to "give me something new now", and the algorithm complies but then quality is low.
Slow, organic discovery is where it's at. Seed your feed by following people you already know, then slowly add other people you come across. If your feed is half empty for weeks, that's a feature, not a bug.
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 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.
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.
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.
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.
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.
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.
> 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.
You are insisting here on talking about the "handle" part, though isn't the crucial part of the complete chain weather we use either did:web or did:plc?
So as you outlined yourself in the article. If you a) use did:web b) ever loose access to that domain you are cooked. No amount of handle changes can help here. If one looses a handle domain one can loose a did:web domain also, so that just moved the problem to a more opaque place.
So your identity is always either a) attached to a domain you might loose b) to some plc provider that might stop work for you.
Please correct me if i get anything wrong here, as that is just how i understand it.
The PLC is being spun out into a separate entity independent of Bluesky. The intention is for it to become something analogous to ICANN. So hopefully, with time, even Bluesky shutting down wouldn’t affect it.
It’s also very simple software and is not difficult to run. People are already running PLC mirrors (e.g. https://plc.wtf/). So if push comes to shove it should be possible to figure out the next step. Although this does require trust and coordination across the ecosystem which is tricky.
What happens if whoever has the old domain now connects a DID with it? Is this where the rotational key + the fact that everything is signed with it comes in? My concern here is with embeds and links on the wider web that have no notion of ATProto DIDs and only know example.com/@example.com
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.
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”.
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.
The PLC DID method is absolutely created by bluesky.
I never said the id they use is arbitrary, I said why not use something deterministic, so it can be handled by alternate resolvers - something that is absolutely possible while still maintaining plc integrity.
I’m not even suggesting people use their own did:web - for that very reason.
I am saying that Bluesky could have used a did:web that uses the plc domain with exactly the same effect.
As is all did:plc resolution is effectively hardcoded to https://plc.directory so what exactly does having its own method change (given they could decorate the docs with any additional functionality)?
I don’t think did:web is the way forward either, as any domain “ownership” is temporary - including plc.directory.
Even extending did:key (so the identity is actually owned by the user via a keypair) and providing a doc resolver (users could register with multiple “resolvers” including bluesky controlled ones) would at least mean an id not tied to a central authority - but they chose to use their own assigned method specific identifiers.
I run my own PLC read-only mirror and do resolution that way, the main PLC is not hardcoded and is a variable you can configure in the official packages
There is also talk of supporting the did:webvh (or something like that) which addresses the domain loss iirc.
> multiple “resolvers
As an ATProto developer, how many authorities would I have to consult? Where would that list come from and live?
More builders are welcome if you want to work on this problem. I'm working on private data and permissions for ATProto
At present you would have one - bluesky. Just as with PLC.
I would hope that some form of truly distributed resolvers would become commonplace - such as those that leverage mainline DHT - and bluesky could then switch to that as well.
Where do these discussions take place? I’d love to get involved somehow.
fyi, the PLC is moving to an independent foundation and governance. It is unlikely to go away or change significantly in the near-term.
fyi2, there are two methods already, did:plc and did:web. The most likely next addition would be did:webvh, but I'm also not involved in any of that stuff. I don't think there is much work on this front because "if it ain't broke, don't fix it". The PLC is useful, even if too "centralized" for some people's preferences
Word of caution, please don't go into a new ecosystem and start by telling them what you think needs to be changed.
First understand why things are they way they are today. ATProto has attracted developers precisely because it's not a purist dominated ecosystem. The underlying ethos to everything is user choice and agency
The last sentence is most likely, also blockchain is looked down upon here as it has never lived up to the supposed benefits. They come with a host of problems something like the proof-of-authority ledger the PLC uses does not have.
Yes, some centralization was exchanged for not being blockchain based, an acceptable tradeoff imho
There are lots of options not using blockchain - I never even mentioned blockchain once.
The proof of authority ledger that PLC uses can still be used via canonical resolution of actual decentralised did methods. Right now it’s not a did (decentralised identifier) - it’s just a centralised bluesky plc id masquerading as a did.
DHT is effectively synonymous with blockchain if you need to have distributed, permissionless writes. How do you envision the DHT being updated and not being blockchain based?
Also, commenting about downvoting will get you more downvotes
> How do you envision the DHT being updated and not being blockchain based?
By being a DHT, not a blockchain? There are many ways for permissionless updates, such as those employed by BEP-44 on mainline DHT (BitTorrent - not blockchain based), IPNS (part of IPFS - also not blockchain based).
I don’t really care about the downvotes - I just want people to comment why, because I’ve said little that isn’t true.
There are lots that have been done to reduce the impact of Sybil attacks on all major DHTs - deterministic node ids, replication, signed payloads, key abuse detection and mitigation, iterative lookups through trusted nodes, etc.
Those complications are why Bluesky chose something simpler for the PLC that gave them the features they needed given the resources they have available to manage this part of the protocol and infra.
Again, and as I said, DHT resolution is just one of many options.
As for “the complications”, those “complications” are just software - as implemented in dozens of libs - and already running on hundreds of thousands (if not millions) of nodes on some of the larger DHTs.
The “features” they needed were equally solved with did:web using plc.directory - which could absolutely be backed by the PLC transparently.
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.
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.
If you did hijack the DNS and say `TXT _atproto.<handle>` points to `did:web:mycontrol.example` then that's a plausible attack, I guess, against did:web, but not against did:plc. And it'd assume that software in between hasn't cached the previous mappings, which typically it has.
I should note though, that for many implementations, that'd mean poisoning a large DNS provider like google, cloudflare or quad8, since those are the DNS servers typically queried from servers, instead of going directly to the authoritative server itself.
1. I hijack the DNS entry so "_atproto.ruuuuu.de" TXT record now returns "did=did:web:iam.evilhacker.de" to the the actor doing the at protocol resolution.
That is a risk for did:web, just as loosing control of your domain is a risk; The did method that is most widely used on AT Protocol is did:plc, which is https://web.plc.directory/
There's also did:webvh which isn't yet supported by AT Protocol, but may provide some better security, but is likely still susceptible to DNS poisoning.
However, the resolution of handle to DID happens at many different layers in the stack, so you'd have to manage to attack all of them at once. Handle resolution isn't something that typically happens on the end-users' machine, but rather on a server running a PDS, Relay or AppView. Those environments tend to be much harder to carry out DNS poisoning attacks.
The article is very light on details about the key used to sign changes of the DID (when the article says "all changes to their data" I guess it refers to the DID?)
But suppose I'm user foobar.bsky.social (appologies to the actual foobar). I've created this identity on bluesky, I do not remember having uploaded a key, or being ofered to download one. Where is that key exactly? Who owns it? And how/when is it used?
Also, if the did is hosted on plc.directory, what mechanism prevent whoever controls that website to overwrite my did and impersonate me?
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?
That's a hard problem obviously. In ATProto, we are using labelers for verification, anyone can run and validate anyone, apps can decide which verifiers they trust. Bluesky runs their own, let's the NYTs verify their contributors, and has allowed one well known, independent user who's been verifying people. These all show a badge in the app
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.
re: account spam, yea hard problem for everyone, even HN fights this
Even before they become active accounts more than half of the PLC ops are spam / adversarial now (evidence indicates one individual or group from MAGA and Nostr each, should I be surprised these are the ones attacking Bluesky and ATProto?)
Labelers can apply labels to accounts as well as specific records. Much of the adult content is handled this way
Backdating is handled by keeping an indexedAt field in the database, both the PDS and Bsky's internal, network wide OLTP for serving queries efficiently. You can see people complain about this when the migrate over a bunch of old content with old dates and flood their feed or followers. The Bsky app now shows both indexedAt(app controlled) and createdAt (user controlled)
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.
No, that’s really not the case. The Leaflet app “knows” about Bluesky posts by reading Leaflet's own database on the Leaflet servers. It doesn’t need Bluesky’s cooperation to use “Bluesky’s” public data. It doesn’t need to hit Bluesky’s API for that. And if Bluesky shut down its API completely, it would still work.
This is because a stream of all public data from all apps is being subscribed to by all apps. Whatever you care about, you save into your app’s database. Each app’s database serves as an app-specific index of the data on the network. If you want to query Bluesky posts later, you just save them as they stream in.
So every app can piggyback on data created by other apps. And anyone can run a "retransmitter" (aka a relay) like this. It's an application-agnostic aggregator over websockets. The one operated by Bluesky-the-company is most popular one, but https://atproto.africa/ is another one, and you can get one running yourself for about $30/mo; the implementations are open source.)
I explain this in more detail in https://overreacted.io/open-social/, Ctrl+F to "to a stream that retransmits events from all known repositories on the network".
Thanks for the info, that does help me understand what's going on in the protocol.
I suppose I was thinking about the app responsible for getting the data into, say, Leaflet's local database in the first place. For that app, the data structures you describe are the APIs that it consumes, for the sole purpose of populating its own database.
That gets my cogs whirring about how good a use-case this would be for SQLite. I suppose it would be somewhat appropriate for a small, private, PDS? Although, if I understand correctly, I wouldn't need to worry about that anyway if I'm using some off-the shelf PDS software, e.g. https://atproto.com/guides/self-hosting
Reminds me of the various crypto protocols talking about theoretical decentralization while entirely bound to 1 platform with no other useful apps in sight.
It's an early time but https://tangled.org/ (sort of like GitHub) and https://leaflet.pub/ (sort of like Medium) are pretty cool and useful, in my opinion. As it gets easier to start new apps (e.g. with tools like https://slices.network/ that take care of indexing the network) I think we'll see more apps built on AT.
In my article, I tried to explain how that works and what makes it possible. "Making it possible" is usually a prerequisite to the kind of broad adoption you're talking about.
What I agree about 100% is that "normal" users don't care about any of this. They just want good apps. The interesting thing about Bluesky, in my opinion, and what makes it different from crypto in your analogy, is that the vast majority of Bluesky users are "normies" in that sense. They couldn't care less about "decentralization" and some are even actively against the idea. But the decentralized nature doesn't directly "show up" in the product much, just like it doesn't "show up" when you browse the web and hop between servers. I think that's key to adoption--it needs to "just work" behind the scenes.
Many (likely a majority) of crypto users are "normal" in that sense too, they just want to transfer funds and don't care about concepts like decentralization or privacy.
I attended DevCon and few other crypto dev events this year for work, and it was hilarious how few actual products were present.
I hope that AT / Bluesky doesn't fall into this same trap of iterating over the details of a protocol vs shipping apps that people actually want to use.
For me personally a slightly less toxic twitter isn't that app, but when something comes along that is I'll likely setup a domain for AT.
Yeah, that’s a really odd take. Git is completely usable apart from GitHub and I would wager that the majority of Git usage happens without GitHub. I personally have far more personal repos hosted on a NAS than anything in GitHub, and while I did work for one company that used GitHub professionally, I can’t imagine it’s anywhere near ubiquitous. Prior to that I worked at a company with 10s of thousands of internal git repos and before their migration to git used a git front end for perforce. Prior to that (and prior to GitHub), I used a git front end for subversion.
I see GitHub as the successor to SourceForge, not a requirement for using git.
I guess we are just in very different professional circles. I've worked with dozens of teams over the last 10 years or so, and I've never come across anyone that self-hosts a repository. The vast majority use Github, and there's been a couple of Bitbuckets, and a couple of GitLabs. That's it.
Prior to that there were a few Subversions, a Perforce, MS's thing (TFS?).
You'll run into them if you ever work for organizations that have strict IP constraints or have no interest hosting their code on a platform in the US.
Coincidentally I have seen that becoming more and more common in my circles since last November.
So is the protocol sort of like a big public kafka topic?
If you want to create a new web app, say, you don't actually store the data yourself. You basically set up a listener to "the big topic in the sky" and ask your users to save all their data in their own respective places, which the protocol will propagate out into the world such that your app's listener will hear about and cache it. Do I have that right? It's a very interesting concept for how to build a web app while the users still own their data.
I don't have a great understanding of the process, though. Are their "offsets" or something to make sure you don't miss updates? Partitions for scalability? Maybe I'm pattern matching too hard to Kafka here.
I wonder, how rigidly has the JSON format been baked into the protocol.
It feels like a shortsighted choice, just because it's prevalent in recent decades.
It took years to implement performant parsers for it and it has a lot of quirks, missing features and the tons of double quotes and mandatory commas significantly harm its human readability...
Not sure what would I recommend instead, but personally I would prefer using EDN instead, as a Clojure programmer
We're all sending JSON around all the time, it's not really that big a performance hit, especially in context of the formats transiting networks today (it's the same, lots and lots of JSON)
Re: what is this even about, see my comment here: https://news.ycombinator.com/item?id=45469167. Sorry I didn't write an elaborate intro to the article; I kind of meant it for a narrower audience of people looking for an answer to a technical question (how at:// resolves).
I'll say this preemptively — actually resolving at:// URIs isn't something you'd do much as an app author because the usual model for apps is to listen to all data commits over the network via websocket (like https://pdsls.dev/jetstream?instance=wss%3A%2F%2Fjetstream1....), and to write to a local database whatever you're interested in. So you'd mostly use at:// URIs as unique global identifiers for pieces of data, but you probably won't actually resolve them since the data will be pushed to you. But it's nice that you can always fetch it on demand too.
I focused on resolving in this article because I think "following along" the resolution procedure is a really good way to understand how handles, identity and hosting are tied up.
I might be pre-empting some future articles of yours, and I'm happy to await either those, or me diving into ATProto deeper by myself some time in the future, but: can any app write any data to a PDS?
And if so, the more interesting question: what if it pretends to write data in the Bluesky format, but e.g. leaves out a field that the Bluesky Appview expects, or writes data in a different format than it expects?
Great questions! Yeah, this is something I want to write about it in the future.
An app can write to PDS if the user grants it access via OAuth. Currently this access is very coarse (which is bad!) although backing up the entire repo is easy (which is good! but should be made more accessible to normies).
There is an active workstream on OAuth Scopes (already partially deployed) which will let apps request more granular access (e.g. apps can write to "their own" collections but also ask to write e.g. Bluesky posts). In UI, this is done through sort of "bundles" of permissions. See https://github.com/bluesky-social/atproto/discussions/4118 for tracking issue.
> what if it pretends to write data in the Bluesky format, but e.g. leaves out a field that the Bluesky Appview expects, or writes data in a different format than it expects?
Atproto data is governed by "lexicons" which are essentially type definitions used by app authors. E.g. `app.bsky.feed.post` type definition is maintained by the Bluesky team. There's a codegen that generates validation code from that definition. If validation doesn't pass, the Bluesky app server will just ignore that record. Records are generally treated by apps as untrusted input, similar to form submissions. They can be validated during ingestion or in the process of usage later.
Not sure if you already replied to a similar question but regarding this quote
> the actual server storing my data is currently https://morel.us-east.host.bsky.network. I’m happy to keep hosting it there but I’m thinking of moving it to a host I control in the future
Is the process of moving hosts documented somewhere?
> Whoever’s hosting the data could change over time…
But the fundamental fact remains that when you host your data on someone else’s system (without a binding agreement), it can vanish or become inaccessible at any time for any reason. And you won’t have any control over who can access it or why.
Yes, which is already the case with every app you use. But like I explain in the second half of https://news.ycombinator.com/item?id=45471337, you’d still be able to restore your account from a backup to a different host without losing reach or breaking any links.
This is a nice write-up. I recently added post-to-bluesky support to my ongoing social-media-scheduler project [1], thinking it would be the simplest of the services to work on, but I ended up getting really confused instead.
DID and handle resolution was the easiest part of ATProto---as the author says, a library can do the job easily. For Ruby it's DIDKit [2]. Where ATProto really threw me was the seeming non-ownership of record types. Bluesky uses "app.bsky.feed.post" for its records, as seen in the article; there seem to be a lot of these record types, but there doesn't seem to be a central index of these like there are for DIDs, or a standard way of documenting them... and as far as I've been able to find, there's no standard method of turning an at:// URI into an http:// URL.
When my app makes a post on behalf of a user, Bluesky only sends an at:// URI back, which I have to convert myself into an http:// URL to Bluesky. I can only do that with string manipulation, and only because I know, externally, what format the URL should be in. There's no canonical resolution.
> I have to convert myself into an http:// URL to Bluesky
at:// URIs and specific lexicon are not limited to a single app. The NSID (app.bsky.feed.post) has authority based on domain, but Bluesky cannot prevent anyone from reading / writing records of that type.
There are alternative apps that read the same at:// but put them under a different https://...
tl;dr, there is not a 1-1 mapping between at:// and https://, it's 1-N
The recommendation to resolve from handles to DIDs for "permalinks" is concerning to me:
- My handle is something _I_ control. I can make it point at a different PDS at any time.
- My DID is something my PDS controls.
I could solve this by indirecting through a web DID under my control, but there's no recommendation anywhere in Bluesky's documentation. Is that something everyone needs to do to ensure real identity portability?
edit: I'm not sure this CAN be solved without running a PDS given that I can't use my own keys. What am I missing here?
What you control is your identity (i.e. DID Document). As long as you control your identity, you can change either your handle or your hosting aka PDS.
What stebalien might be referring to is that your DID document for PLC specifically is controlled by anyone with the rotation key.
In the Bluesky implementation, this is Bluesky for convenience’s sake, to make it possible for users to easily sign up. (I’m not sure internally if it’s part of the PDS or held separately.)
PLC has a mechanism allowing “higher” keys to override “lower” ones within a certain time window, so being able to add your own rotation key that “outranks” Bluesky’s would solve this issue.
Alternatively, use web DIDs and then it’s fully self-managed just as DNS would be.
This is mostly separate to the PDS - Bluesky is more like the client here (albeit, they also currently run the PLC service). It’s part of your DID document which they manage for you mostly, but there’s ways to take ownership of your PLC DID - see Dan’s links for that.
For our non-atproto uses of the PLC directory, we have similar needs, and we’ll likely let users provide their own public key before we create their document to help solve this. We have a technical audience though, so that solution may not make sense for Bluesky - but there’s a lot of people thinking about how to improve this in the atmosphere.
From my reading of your blog post, it sounds like the DID is the ultimate authority and not my domain name, which sounds like a pretty big problem for user portability.
Ah, that's exactly what I was looking for. Thanks!
I guess I get why it works that way (avoids some issues with domain expiration) but... honestly, I'd rather have my domain name in control. Even after registering my own rotation key, I'm still at the mercy of the centralized PLC directory.
Unfortunately, it looks like it's not possible to migrate to a web DID without starting over.
Yeah, you can't migrate a DID. You could bulk-import the content (and even fix internal links within it) but that wouldn't change the links pointing at the old DID.
So the reason to have the DID in control is for users that say sign up for Bluesky and have a bluesky handle which is a domain they don't control and want to move to a different provider without breaking everything. If your handle was the thing in control then you must own a domain to own your account and move providers. That kinds of defeats the purpose of migratable PDSs for the "rest of us" use case.
This is verbose and unclear. An article like this should always start by explaining what problem it tries to solve before going into technical details.
What you might see as verbose, I think is exceptionally clear. Also, the article comes with an entire other article explaining the problem, so not sure what you are on. If you cannot even click on a link, maybe you shouldn't complain about verbosity in the first place.
Which article are you talking about? I think https://overreacted.io/open-social/ (which is what I linked to) gives a pretty detailed explanation if that's what you wanted. As for the article in today's submission, I meant it for the audience that's already interested in the topic, and did not pad it out with a motivational section. I'm glad GPT was useful to you.
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.
The content can be mirrored, and being content-addressed with an algorithm the client verifies, the mirror can’t tamper with any of it. Switching to another DID method like did:ipfs is also a possibility. It’s not a perfect solution to every possible disruption, but it’s a system designed to evolve in response.
To make bluesky really lift of and become widely accepted for decentral social media there should be a simple solution to self host your postings. E.g. something you can easily host on a webhosting with php or so. The docker container provided is great but one step to high for broad usage.
Yeah, it needs to be easier to do. It's already getting more accessible with tools like https://pdsmoover.com/ and communities like Blacksky offering hosting. Ideally there would be many such providers.
This seems to fill the same function as DNS, but adds a layer of abstraction on top of it, while also adding a dependency on a service provided by Bluesky. I fail to see how this improves things on the whole.
It builds on top of DNS (in at least in two places) so it’s not equivalent — and it fills a different function to it. See https://news.ycombinator.com/item?id=45469296 for a breakdown.
PLC is being spun out into an independent entity, the longer term goal is for it to operate somewhat similar to ICANN. Its code is easy to run so something else could conceivably replace it. It’s also possible for AT to allow other `did` methods in the future as long as they’re persistent and can be performantly resolved.
Can you clarify what the proposed change is? I don't quite follow. For example, what does `at://did:plc:fpruhuo22xkm5o7ttr2ktxdo/sh.tangled.feed.star/3m23ddgjpgn22` become ?
After 3 years on Mastodon and some lurking on bsky, I believe the main issue is not technical but getting and keeping interesting content on a platform. This is a social issue as bubbles ruin everything over time. OTOH using algorithms to mix some „foreign“ content into the feeds causes outrages. Sure we can all go web3 and self-hosted but nobody will read. Mastodon is the posterchild of a failed experiment. I‘m interested in the creative, productive, inspiring long-tail content on all platforms instead of migrating the peer group over to a new platform every couple of years. I know them already, I have better ways to communicate with my direct peers and the rest is like having 500 contacts on LinkedIn: A social illusion. I appreciate and respect the technical efforts behind atproto, but yet I can‘t see that it solves the problem described above.
> instead of migrating the peer group over to a new platform every couple of years
> I appreciate and respect the technical efforts behind atproto, but yet I can‘t see that it solves the problem described above.
If I am correctly reading backwards from "does atproto solve this core problem I see" ...
ATProto is a fabric where your data lives and Bluesky is just one app that sits on top of this. Your network and data stays with you if you move platforms or try out completely different apps. Same account, same data, same social graph (if you want to reuse it for other apps or not). Similarly, other apps can access all or some of your data (if you let them), so you don't have to start from scratch and they can provide more interesting content for new to them users (but not new to atproto)
In this sense, as people try out and move around different apps, they don't lose things. Users can even be on different apps, but using the same underlying data, transparent to them. This is called the "credible exit" around the atmosphere (atproto ecosystem nickname) and means (1) you can leave a bad company without them preventing you from taking your data (2) enables real competition in social apps, re: the aforementioned features.
Yeah it's solving a wrong problem. What's needed is means to get enough bandwidth of data, not giving yet another blog site you can post to.
The kind of content that wins the Internet is never the kind that'll be "popular", despite all objective data, so whoever to run the platform has to "algorithm" the system to prefer "popular" contents which destroys the community as well as greater society in matters of decades.
Backward names are not used for the "server". (I presume that by "server" you mean hosting, which is determined by the `serviceEndpoint` in the DID document rather than by something in the AT URI, as the article explains.)
If you're asking about “app.bsky.” in the AT URI, it doesn’t indicate a server you’re going to connect to. As stated in the post, it indicates a data format. Think of it as a file extension which describes who governs the schema of that JSON.
Formats (called "lexicons" in AT) use a reverse-namespace scheme so that formats governed by the same app appears next to each other alphabetically. That might remind you of Java.
As stated near the end of the article, this isn’t something you’d do much as an app developer. The article describes how to pull but the predominant model for building apps is to have the data pushed to you. So in practice you’d use at:// URIs as unique identifiers for the data you’re receiving and indexing on your backend, not something you actually need to resolve. You wouldn't need to resolve them because you'd be receiving the JSON itself via the websocket.
To add, it's largely required for an app to listen to the event stream because a user may write a record you care about directly (not through your app), and you likely want to know about that as "real-time" as possible. Crawling will never get you close to that
I've never really gotten AT protocol. It just seems like reïnventing the web. I guess it's a little more secure than the normal web because there's no JS, and you can make it seem more integrated because users won't have custom styles, but neither of these are particularly appealing to me. HTML + RSS does basically the same job, and then link aggregator sites like news.ycombinator.com recommend content much better than the algorithms you get in social media.
I guess the big advantage is reposts and comments, but practically you could achieve these in the regular web through indexing with backlinks. The conceptual service Bluesky is providing is essentially just a web-index of items published using the AT protocol.
I tried to make a pretty extensive case for it at https://overreacted.io/open-social/#open-social, I'd suggest reading it with an open mind to form an opinion. I think there's quite a few interesting aspects there, like apps being able to "piggyback on" data from other apps.
I wouldn't call AT a "reinvention" of the web, personally I see it as a minor bump that codifies some conventions that let apps interoperate while keeping the source of user data outside those apps. New products can be started from data of other (even defunct) products and remix it. That's pretty powerful.
how can it be hacked? can i impersonate someone else? whats to stop me from making posts with someone elses handle. how secure is the data? or does it just ride over tls and use that for protection.
Every commit in your repo is signed with your private key which stays on your hosting. (You also can get another special key for your identity that would let you force-change hosting if your hosting gets adversarial.) Changes from your hosted repository get transmitted as signed commits (kind of like Git) so they can be verified by those receiving the retransmission against your public key.
Here's another article answering this question: https://overreacted.io/open-social/. The one you're commenting on links to it in the first paragraph with "if not, read this!" for that exact reason--I can't explain the motivation and technical details in the same post, or to repeat the same explanation from post to post.
I read this article the other day and I am not sure what the breakthrough is with AT/bsky. It seems like the functionality "This blurs the boundaries between apps. Every open social app can use, remix, link to, and riff on data from every other open social app." is already provided on the web through hyperlinks.
There is seemingly nothing in the AT protocol that prevents sites from defederating and enabling vendor lock-in, just like how every other social media site has switched to requiring you to log in to see links.
There is seemingly nothing usefully decentralized about it. There is some sort of psuedo-distribution where you can host on your own domain. But like email, I imagine these types of users will be effectively blocked due to spam filtering.
It's like P2P if it was invented by people who know nothing about P2P, but just want to create a version of twitter that is immune to the company being bought out by someone they don't like and instituting a different censorship regime.
Yeah except there’s no guarantee of structured data there! With AT, each record is specified using a corresponding lexicon—making for much more straightforward interop.
> There is seemingly nothing in the AT protocol that prevents sites from defederating and enabling vendor lock-in, just like how every other social media site has switched to requiring you to log in to see links.
And that’s fine! Any site can choose to do whatever they please—but the underlying AT records always remain accessible to other consumers (apps, users, …).
> I imagine these types of users will be effectively blocked due to spam filtering.
Blocked by whom? If the relay (which pulls records from your PDS) “blocks” your PDS, you can simply switch to one that doesn’t. The beauty of AT infra is every piece of it can be run separately. That’s “meaningful” decentralization.
>Blocked by whom? If the relay (which pulls records from your PDS) “blocks” your PDS, you can simply switch to one that doesn’t.
Blocked by pretty much everyone, in the case of email. If most people use gmail or hotmail, and these mail providers block mail from new domains regardless of DMARC/DKIM/etc. then you are effectively blocked from sending email to most people. It's inevitable that this happens because there is no sybil resistance built in to the network layer, so providers have to be blocky to prevent spam.
> The beauty of AT infra is every piece of it can be run separately. That’s “meaningful” decentralization.
So kind of like how in the web, every website can be run separately?
You can switch, but everyone else won't coordinate to switch at the same time. So you have been deplatformed. It is the same with the web, where if you get banned from a forum (perhaps one that changes its rules to suit sponsors), you can switch to using a forum that no one uses due to network effects.
>There is seemingly nothing in the AT protocol that prevents sites from defederating and enabling vendor lock-in, just like how every other social media site has switched to requiring you to log in to see links.
Note there is no "federation" in the Mastodon sense; sites don't "talk to" each other. They just all aggregate data from the web. Yes, an app doing that could potentially stop "posting to" and "aggregating from" the web in the future and move the source of truth to a local database. But by doing that, it mostly just loses interoperability--and someone else could start a new app with the already existing data on the network, effectively forking their product with its users/data.
>It's like P2P if it was invented by people who know nothing about P2P
Listen I'm not a crazy huge fan of a lot of new tech, but this is pretty transformational. When reading the first article [1] I was struck by the fact that it granted so much new freedom to your "social identity" on the internet. The comparison to hosting providers was incredible, because imagine you building a website and posting your thoughts there or starting a business there...and then immediately being shut down and all your data lost because of some arbitrary change of policy at your "host".
Everyone always talks about how your Google account being tied to logins is scary because you can get arbitrarily locked out. This protocol makes something like functionally impossible since /you/ control your data.
> Bob, however, isn’t technical. He doesn’t even know that there is a “repository” with his “data”. He got a repository behind the scenes when he signed up for his first open social app.
> Bob uses a free hosting service that came by default with his first open social app.
> If she owns alice.com, she can point at://alice.com at any server.
But does Bob own bob.com? That sounds beyond Bob's abilities and interest level. So Bob is stuck on one platform, in practice, and it's full other Bobs who are also stuck. The "free hosting service" (why is it free?) is now the gatekeeper. It may let him switch platforms.
Technically sure, but (1) apps that Bob uses have no power over that database, and (2) if someone were to remove that row, Bob could change his handle to something else without losing his identity, data, or reach.
It seems to mean that Bob's free hosting service has to be a relatively benign and permanent institution like ICANN, and not some ropey old operation like Photobucket.
Others on this thread are talking about Decentralized IDs, https://en.wikipedia.org/wiki/Decentralized_identifier . Looks like those are stored in several competing systems. There's a blockchain one, a Chinese one that wants to know your real name, and a Microsoft one that wants to store your photo. This all has, uh, implications, which sound much less liberating than this at:// protocol does at first.
You could do it with top-level domain names alone, but that would require users to buy domain names and retain control over them forever. It means you have to trust your domain registrar and pay them fees. This is too big a burden for new Bluesky users.
You could do it more cheaply with subdomains, but then you have to trust the owner of the parent domain.
So instead, they created a new registry and a way for users to cryptographically sign their registry documents. Since this is all done behind the scenes, most users are still fully trusting the central Bluesky infrastructure. But in theory, they could migrate off of it.
Here's a TLDR on the problem it solves: https://overreacted.io/open-social/#the-big-picture. I've linked to this article in the intro. In short, it's a different model where apps participate host user data on the web under user's control. This enables some interesting use cases, like all apps can deeply interoperate by default. It's hard to explain this concisely, the article I linked to is my best attempt.
I understand, appreciate, and share the desire for a decentralized and censorship-resistant social graph. I'm just not sure what problem the new URL scheme solves. Is DNS not already decentralized? It's not that I don't see the value in what you're trying to do --- it's that don't understand what problem you're solving that we can't solve with hypertext, RSS, and data attributes.
> The advantage of storing structured app-specific entities, such as posts and likes, instead of HTML documents is obvious.
Agreed.
> This allows you to create many projections of the same data—a profile page, a list of posts, an individual post with comments.
WE HAD THIS! In some sense, we still do. XSLT exists. The dream was always that XML documents linked together with defined schemas would be the source of truth for an information web and we'd style them dynamically to provide for different UIs.
I mean, look. Maybe the XML-centric semantic web was just an idea before its time. Maybe at:// will succeed where it didn't due to timing, real-world social context, or just the force of will of its proponents.
But from a technical POV, I'm just not seeing why I'd want to use this instead of reviving those older but proven technologies.
For identity, you want some kind of a global login, or a "handle", that you can remember. at:// uses domains for that (e.g. my "handle" is danabra.mov). That is literally DNS.
However, you also want somebody to hold your data. Most people don't want to host their own data. (I don't.) So that's where the notion of hosting comes into play. My current host, as explained in the article, is https://morel.us-east.host.bsky.network. (That's also resolved through DNS.)
Finally, the important bit is that I (as an identity) should be able to change both my handle (i.e. how people refer to me) and my hosting (i.e. where my data is stored) without breaking any links to my data from other data ("links between JSON" is how we represent "reply to a post", "like to a reply", "follow of a person", etc). This is why links are tied to an identity rather than to hosting or to handle. The identity document also contains my public key which is important to allow trustless caching and retransmission of the data.
That's about it.
>But from a technical POV, I'm just not seeing why I'd want to use this instead of reviving those older but proven technologies.
I think everything being signed is a big one. There is no need to trust anyone retransmitting the data because it's transferring signed commits. But yes, this is essentially a fusion of something like Git with something like RSS, but for JSON and on top of DNS, HTTPS, CBOR, and WebSocket.
Compared to RSS, the novel parts is that you don't need to trust the retransmitters, that it's pushed via WebSockets, that it scales to real-time communication for millions of users (in production today), and that it's application-agnostic but the data formats are application-controlled. E.g. we have different apps like Tangled.org (GitHub on atproto), Leaflet.pub (Medium on atproto), etc, all able to "see" each other's data and interop.
> why do I want a global login? that sounds like hell
Ask social media users if they would like one account or separate accounts for every platform, they think that later is the hell
OAuth is one piece of evidence that confirms this general pattern among online users. Fewer accounts are easier to manage, just give me a click to login button on your site for an account I already have and manage elsewhere
I don't socialize with other nerds IRL. I know what you're getting at, but I think it's at the point right now where "normal people" have paranoia of getting locked out of their google/apple accounts, because it has happened to pretty much everyone I know at least once.
They both send you through the loop of assuming you have a device, so if you lose your device you're screwed.
For example, you can even see memes like this are very popular:
>why do I want a global login? that sounds like hell.
You can still have many distinct identities if you want to, the point is just that you also don't have to for cases when you want to have shared data flowing and interlinking between apps.
>How is websockets better than XHR in this case?
Websockets are used for retransmitting changes from millions of repositories to a bunch of apps that want to aggregate over that data and create app-specific indexes. I'm not sure what XHR has to do with that or how it helps there. Have a look at the data stream: https://pdsls.dev/jetstream?instance=wss%3A%2F%2Fjetstream1....
> Finally, the important bit is that I (as an identity) should be able to change both my handle (i.e. how people refer to me) and my hosting (i.e. where my data is stored) without breaking any links to my data from other data
But that's how the web already works. If I own example.com I can change its target from, say, 1.2.2.2 to 2.3.3.3 any time I want. My identity doesn't change even while my host does. What's the difference?
If you want another layer of indirection, add a CNAME or a 30X redirect.
> The identity document also contains my public key which is important to allow trustless caching and retransmission of the data.
We have a perfectly good web built out of normal, boring stateless HTTP requests and text formats. I'm skeptical of switching to stateful sockets and binary formats. I prefer my technologies to be minimal deltas built atop stable, proven foundations, and my NIH spidey sense is tingling when I read about stuff like this.
Why wouldn't adding per-update signature data to RSS (including previous entries, blockchain-style, in the hash) do exactly what this stack does but without all the new technology?
DID is basically one extra level of abstraction, allowing for different methods.
did:web: eg is literally HTTP, did:dns: is DNS, and there’s loads of others.
This extra level of abstraction allows of arbitrary IDs, which is what the PLC DIDs were created for.
Let’s say that I am currently known as rmccue.com.au. I move overseas and now want to be rmccue.scot - or worse, because I am no longer in .au, I can’t even keep my old domain name. How do you persist this identity?
With PLC, I can instead be an abstract did:plc:hv27plmlx6zkuv7bnzbqb6xr (an arbitrary hash of the genesis entry for my DID). I associate rmccue.com.au with this via a TXT record, and back the other direction by recording the domain as an alias.
If I change my handle, I’m still the same arbitrary handle everywhere, everyone keeps following me, and in theory old references to my alias could even continue resolving.
(Similarly, this solves the issue for trademark changes, name changes throughout a person’s life, and changing job roles.)
There’s some DHT-based DID methods so it’s possible - one of the nice things about the DID abstraction layer is that could be added.
As I understand, atproto is intentionally limiting to PLC and Web for now, and monitoring the ecosystem. Every method has to be implemented by every client, so you naturally want to be cautious in how many you support.
(I don’t work for or represent Bluesky, so can’t speak to any plans other than what they’ve stated publicly!)
>But that's how the web already works. If I own example.com I can change its target from, say, 1.2.2.2 to 2.3.3.3 any time I want. My identity doesn't change even while my host does. What's the difference?
To clarify, we're talking about generalizing the notion of a "username" or a "handle". E.g. I started with `danabramov.bsky.social` (given out to me) and then moved to `danabra.mov`. I might move to some other domain later. The idea is you should be able to do this as many times as you like without a chain of redirects where losing one domain in the chain loses all your links. (Also, "normal" people don't know what a redirect even is, much less how to set one up.) Hence, an indirection is "above" the chain rather than a part of the chain. The DID points at the domain.
In other words, "normal" people don't want their social media reply chains, or social media mentions, or their GitHub issues, or their Medium articles, to break when someone else swaps their user handle. We're using handles for domains so we need to add an affordance so they "act like handles".
>Sure. That's what DANE is for
Not familiar with it so can't comment unfortunately! But hopefully the above gives some context. We want to stay decoupled both from the handle and from the concrete hosting. Changing the handle and changing the hosting should be doable with zero cooperation from whoever holds your previous domain or previous hosting.
>We have a perfectly good web built out of normal, boring stateless HTTP requests and text formats.
Yes, and that still works — you can pull it on demand with plain HTTP as I show in the article. The CBOR/WebSocket stuff is for the high scale use case (have a look at https://pdsls.dev/jetstream?instance=wss%3A%2F%2Fjetstream1....), i.e. realtime large-scale social aggregation.
>I prefer my technologies to be minimal deltas built atop stable, proven foundations, and my NIH spidey sense is tingling when I read about stuff like this.
>Why wouldn't adding per-update signature data to RSS (including previous entries, blockchain-style, in the hash) do exactly what this stack does but without all the new technology?
I'm not sure how you'd represent arbitrary application data in RSS (e.g. Tangled.org is essentially "GitHub on atproto"), how you'd do high-scale fanout with RSS (realtime to millions of users), or how you'd have properties like ability to move hosting with no disruption to user-visible experience in downstream apps, and no reduction in trust in the data.
> To clarify, we're talking about generalizing the notion of a "username" or a "handle".
Name registries are hard. How do you handle collision avoidance and impersonation resistance?
You can do registration centrally and hierarchically like DNS.
You can generate collision-resistant tokens (e.g. GUIDs) and do some kind of content-addressed metadata lookup thing, perhaps via a DHT or something. These names are opaque though.
You could allow people to generate names consisting of a recognizable name _paired_ with an opaque token, but if you do that, you open yourself up to impersonation attacks --- quotemstr-B87FAEAB-9D34-418D-A6E9-B95BEBC9DD0B vs C243F0B4-AF9A-4F48-9880-8436B1C15293.
AIUI, the concept here is that DNS names can point to opaque tokens and that the token can remain stable without requiring continuity of DNS registration?
What do you think of Namecoin, which seems like what you get when you follow this line of thinking to its logical conclusion? Without something like NC, isn't any registration scheme not centrally gated subject to infinity sybil attacks?
There’s a bidirectional link between a user handle (domain) and their identity (a DID). But the data is logically rooted in the DID. Domain handle is an alias that can change over time — but your DID never changes. Links are stored with DID so that changing your handle doesn’t break existing links.
I'm with you this seems to be reimplementing the wheel but, recently XSLT has been widely deprecated. And the (sole?) maintainer of some very core infrastructure for that is paused or archived or something that will slow/block features and fixes.
So, is a revamp, new code with less baggage, doing the same-ish thing. Then in 20 years it will have the baggage and we'll get a new one.
Data sovereignty and distributed identity. It's trying to avoid a centralized authority on where data is stored or how to resolve and trust an identity other than DNS and using signatures to validate data that you didn't get directly from the author.
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...
The "Discover" feed isn't that great on a fresh account. It does get better with time based on likes and follows but still not super great.
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.
An I crazy out does that feed have nothing on it besides a request to favorite the feed?
For You is based on your likes. If you get an empty feed then you probably haven't liked anything yet. Try liking a couple of posts in Discover feed and get back to For You.
not as good as twitter
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"...
> that doesn't address the discovery problem.
The real problem is the expectation of immediate discovery. People have gotten used to "give me something new now", and the algorithm complies but then quality is low.
Slow, organic discovery is where it's at. Seed your feed by following people you already know, then slowly add other people you come across. If your feed is half empty for weeks, that's a feature, not a bug.
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 had the same but it wasn’t even edgy like on X, really just sad twee millennial American politics commentary
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.
Wow, sounds really awful, you selected art and got posts about art.
Not all art is slop
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.
I can check again when I get home but I'm fairly sure I didn't enable that when it prompted me for interests when signing up.
In theory, you can build your own ranking algorithm because the protocol is open.
See: https://github.com/bluesky-social/feed-generator
And see feeds that others have built https://blueskydirectory.com/feeds/all
Get into custom feeds, game changer.
I use https://graze.social
Twitters the same just in reverse
I think it's more a function of who you follow...
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 relentlessly click "less like this" but it doesn't seem to budge.
Maybe it's not instant? Maybe it needs some time to generate and cache new results for you and the millions (?) of other users?
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.
That's basically every social platform in my experience.
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 a thing specially on that website. This post explains it: https://www.natesilver.net/p/what-is-blueskyism
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.
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 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.
> 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.
> 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.
Thanks for trying to explain this to us.
You are insisting here on talking about the "handle" part, though isn't the crucial part of the complete chain weather we use either did:web or did:plc?
So as you outlined yourself in the article. If you a) use did:web b) ever loose access to that domain you are cooked. No amount of handle changes can help here. If one looses a handle domain one can loose a did:web domain also, so that just moved the problem to a more opaque place.
So your identity is always either a) attached to a domain you might loose b) to some plc provider that might stop work for you.
Please correct me if i get anything wrong here, as that is just how i understand it.
The PLC is being spun out into a separate entity independent of Bluesky. The intention is for it to become something analogous to ICANN. So hopefully, with time, even Bluesky shutting down wouldn’t affect it.
It’s also very simple software and is not difficult to run. People are already running PLC mirrors (e.g. https://plc.wtf/). So if push comes to shove it should be possible to figure out the next step. Although this does require trust and coordination across the ecosystem which is tricky.
See https://updates.microcosm.blue/3lz7nwvh4zc2u for some thoughts on that.
What happens if whoever has the old domain now connects a DID with it? Is this where the rotational key + the fact that everything is signed with it comes in? My concern here is with embeds and links on the wider web that have no notion of ATProto DIDs and only know example.com/@example.com
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.
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”.
Isn't the solution to the identity problem of domains just to use public/private key pairs like Nostr does?
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.
At least with email you can own a PGP/SMIME key and take it elsewhere, right? Isn't this something similar with ATproto?
Yes, see here: 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.)
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.
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.
“we” = group of long term contributors and core committers, including myself (I wrote the WP REST API), hosted by the Linux Foundation.
(More info on the linked site; I don’t want to hijack the thread too much.)
> PLC isn’t tied to atproto
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)?
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).
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.
The PLC DID method is absolutely created by bluesky.
I never said the id they use is arbitrary, I said why not use something deterministic, so it can be handled by alternate resolvers - something that is absolutely possible while still maintaining plc integrity.
It can be handled by alternative resolvers, like https://plc.wtf
Non-plc resolvers. This resolver you referenced is still using plc.directory upstream.
> why didn’t they just use did:web
If you lose your domain, you lose your account. The PLC doesn't have this particular issue
I’m not even suggesting people use their own did:web - for that very reason.
I am saying that Bluesky could have used a did:web that uses the plc domain with exactly the same effect.
As is all did:plc resolution is effectively hardcoded to https://plc.directory so what exactly does having its own method change (given they could decorate the docs with any additional functionality)?
I don’t think did:web is the way forward either, as any domain “ownership” is temporary - including plc.directory.
Even extending did:key (so the identity is actually owned by the user via a keypair) and providing a doc resolver (users could register with multiple “resolvers” including bluesky controlled ones) would at least mean an id not tied to a central authority - but they chose to use their own assigned method specific identifiers.
ATProto is great. PLC sucks.
Some interesting points in there you have made.
I run my own PLC read-only mirror and do resolution that way, the main PLC is not hardcoded and is a variable you can configure in the official packages
There is also talk of supporting the did:webvh (or something like that) which addresses the domain loss iirc.
> multiple “resolvers
As an ATProto developer, how many authorities would I have to consult? Where would that list come from and live?
More builders are welcome if you want to work on this problem. I'm working on private data and permissions for ATProto
At present you would have one - bluesky. Just as with PLC.
I would hope that some form of truly distributed resolvers would become commonplace - such as those that leverage mainline DHT - and bluesky could then switch to that as well.
Where do these discussions take place? I’d love to get involved somehow.
https://discord.atprotocol.dev is a great entrypoint
fyi, the PLC is moving to an independent foundation and governance. It is unlikely to go away or change significantly in the near-term.
fyi2, there are two methods already, did:plc and did:web. The most likely next addition would be did:webvh, but I'm also not involved in any of that stuff. I don't think there is much work on this front because "if it ain't broke, don't fix it". The PLC is useful, even if too "centralized" for some people's preferences
Thanks - I will join there and see if there’s any way I can promote decentralisation as a core tenet.
Word of caution, please don't go into a new ecosystem and start by telling them what you think needs to be changed.
First understand why things are they way they are today. ATProto has attracted developers precisely because it's not a purist dominated ecosystem. The underlying ethos to everything is user choice and agency
Also, show not tell, build then advocate
It seems like this comment is getting downvoted. For what exactly? If I am wrong about something then point it out.
The last sentence is most likely, also blockchain is looked down upon here as it has never lived up to the supposed benefits. They come with a host of problems something like the proof-of-authority ledger the PLC uses does not have.
Yes, some centralization was exchanged for not being blockchain based, an acceptable tradeoff imho
There are lots of options not using blockchain - I never even mentioned blockchain once.
The proof of authority ledger that PLC uses can still be used via canonical resolution of actual decentralised did methods. Right now it’s not a did (decentralised identifier) - it’s just a centralised bluesky plc id masquerading as a did.
> I never even mentioned blockchain once
DHT is effectively synonymous with blockchain if you need to have distributed, permissionless writes. How do you envision the DHT being updated and not being blockchain based?
Also, commenting about downvoting will get you more downvotes
> How do you envision the DHT being updated and not being blockchain based?
By being a DHT, not a blockchain? There are many ways for permissionless updates, such as those employed by BEP-44 on mainline DHT (BitTorrent - not blockchain based), IPNS (part of IPFS - also not blockchain based).
I don’t really care about the downvotes - I just want people to comment why, because I’ve said little that isn’t true.
What would you do about sybil attacks?
> because I’ve said little that isn’t true
You have said more than you realize in how you phrased the sequence of questions, and regardless of truthiness or not, they come off as combative.
Another commenter has pointed you towards a discussion where you can find conversations on these topics
> What would you do about sybil attacks?
There are lots that have been done to reduce the impact of Sybil attacks on all major DHTs - deterministic node ids, replication, signed payloads, key abuse detection and mitigation, iterative lookups through trusted nodes, etc.
Those complications are why Bluesky chose something simpler for the PLC that gave them the features they needed given the resources they have available to manage this part of the protocol and infra.
Again, and as I said, DHT resolution is just one of many options.
As for “the complications”, those “complications” are just software - as implemented in dozens of libs - and already running on hundreds of thousands (if not millions) of nodes on some of the larger DHTs.
The “features” they needed were equally solved with did:web using plc.directory - which could absolutely be backed by the PLC transparently.
>Essentially, you need to hit the https://plc.directory service with a GET
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.
But you can use did:web:fqdn if you want; it's explained in the article.
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.
Is there any reading material on the private-key recovery bits? I want to learn how AT manages failure scenarios, especially around key-loss.
The private key is normally stored on your PDS (hosting). See https://www.da.vidbuchanan.co.uk/blog/adversarial-pds-migrat... for how to be prepared for adversarial migration.
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.
> "DNSSEC is not required"
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.
>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?
The process of establishing "this handle points to this DID" consists of:
1. Resolving handle -> DID via HTTPS/DNS (part you're concerned about)
2. Downloading the DID Document from its host
3. Verifying that the DID Document contains the same handle
Hijacking the DNS does not help you with (2) and (3). The handle isn't considered associated with the DID until (2) and (3) are done.
If you did hijack the DNS and say `TXT _atproto.<handle>` points to `did:web:mycontrol.example` then that's a plausible attack, I guess, against did:web, but not against did:plc. And it'd assume that software in between hasn't cached the previous mappings, which typically it has.
This is noted in the did:web spec, which isn't from Bluesky PBC / AT Protocol: https://w3c-ccg.github.io/did-method-web/#dns-considerations
I should note though, that for many implementations, that'd mean poisoning a large DNS provider like google, cloudflare or quad8, since those are the DNS servers typically queried from servers, instead of going directly to the authoritative server itself.
There's more technical details here: https://github.com/bluesky-social/atproto/tree/main/packages...
I'm going off your post here.
1. I hijack the DNS entry so "_atproto.ruuuuu.de" TXT record now returns "did=did:web:iam.evilhacker.de" to the the actor doing the at protocol resolution.
2. To get the DID, the actor doing the at protocol resolution downloads the DID from "https://iam.evilhacker.de/.well-known/did.json", which I have full control over.
3. In the DID document, I put "alsoKnownAs": ["at://ruuuuu.de"], along with my own public key.
Wouldn't this make the actor doing the resolution associate me with your handle?
Again, maybe I'm missing something here. It just seemed to me this would allow me to hijack your posts when they are federated.
That is a risk for did:web, just as loosing control of your domain is a risk; The did method that is most widely used on AT Protocol is did:plc, which is https://web.plc.directory/
There's also did:webvh which isn't yet supported by AT Protocol, but may provide some better security, but is likely still susceptible to DNS poisoning.
However, the resolution of handle to DID happens at many different layers in the stack, so you'd have to manage to attack all of them at once. Handle resolution isn't something that typically happens on the end-users' machine, but rather on a server running a PDS, Relay or AppView. Those environments tend to be much harder to carry out DNS poisoning attacks.
(I added a reply up-thread here: https://news.ycombinator.com/item?id=45469667)
The article is very light on details about the key used to sign changes of the DID (when the article says "all changes to their data" I guess it refers to the DID?)
But suppose I'm user foobar.bsky.social (appologies to the actual foobar). I've created this identity on bluesky, I do not remember having uploaded a key, or being ofered to download one. Where is that key exactly? Who owns it? And how/when is it used?
Also, if the did is hosted on plc.directory, what mechanism prevent whoever controls that website to overwrite my did and impersonate me?
I'm fascinated by the idea of at://.
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.
> Why not publish the changes too?
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?
> I don't see anything about reputation
That's a hard problem obviously. In ATProto, we are using labelers for verification, anyone can run and validate anyone, apps can decide which verifiers they trust. Bluesky runs their own, let's the NYTs verify their contributors, and has allowed one well known, independent user who's been verifying people. These all show a badge in the app
> then change it to vile stuff
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
Thank you, that's very helpful.
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.
re: account spam, yea hard problem for everyone, even HN fights this
Even before they become active accounts more than half of the PLC ops are spam / adversarial now (evidence indicates one individual or group from MAGA and Nostr each, should I be surprised these are the ones attacking Bluesky and ATProto?)
Labelers can apply labels to accounts as well as specific records. Much of the adult content is handled this way
Backdating is handled by keeping an indexedAt field in the database, both the PDS and Bsky's internal, network wide OLTP for serving queries efficiently. You can see people complain about this when the migrate over a bunch of old content with old dates and flood their feed or followers. The Bsky app now shows both indexedAt(app controlled) and createdAt (user controlled)
"Given an at:// URI, how do you locate the corresponding JSON?"
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.
Yeah, sorry for abrupt intro.
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.
No, that’s really not the case. The Leaflet app “knows” about Bluesky posts by reading Leaflet's own database on the Leaflet servers. It doesn’t need Bluesky’s cooperation to use “Bluesky’s” public data. It doesn’t need to hit Bluesky’s API for that. And if Bluesky shut down its API completely, it would still work.
This is because a stream of all public data from all apps is being subscribed to by all apps. Whatever you care about, you save into your app’s database. Each app’s database serves as an app-specific index of the data on the network. If you want to query Bluesky posts later, you just save them as they stream in.
So every app can piggyback on data created by other apps. And anyone can run a "retransmitter" (aka a relay) like this. It's an application-agnostic aggregator over websockets. The one operated by Bluesky-the-company is most popular one, but https://atproto.africa/ is another one, and you can get one running yourself for about $30/mo; the implementations are open source.)
I explain this in more detail in https://overreacted.io/open-social/, Ctrl+F to "to a stream that retransmits events from all known repositories on the network".
Thanks for the info, that does help me understand what's going on in the protocol.
I suppose I was thinking about the app responsible for getting the data into, say, Leaflet's local database in the first place. For that app, the data structures you describe are the APIs that it consumes, for the sole purpose of populating its own database.
That gets my cogs whirring about how good a use-case this would be for SQLite. I suppose it would be somewhat appropriate for a small, private, PDS? Although, if I understand correctly, I wouldn't need to worry about that anyway if I'm using some off-the shelf PDS software, e.g. https://atproto.com/guides/self-hosting
Imagine it as analogous to “Given a https:// URI, how do you locate the corresponding HTML?”
This is oversimplified but is a decent question to prompt an explanation for someone new to DNS, HTTP, TLS, etc.
Reminds me of the various crypto protocols talking about theoretical decentralization while entirely bound to 1 platform with no other useful apps in sight.
It's an early time but https://tangled.org/ (sort of like GitHub) and https://leaflet.pub/ (sort of like Medium) are pretty cool and useful, in my opinion. As it gets easier to start new apps (e.g. with tools like https://slices.network/ that take care of indexing the network) I think we'll see more apps built on AT.
In my article, I tried to explain how that works and what makes it possible. "Making it possible" is usually a prerequisite to the kind of broad adoption you're talking about.
What I agree about 100% is that "normal" users don't care about any of this. They just want good apps. The interesting thing about Bluesky, in my opinion, and what makes it different from crypto in your analogy, is that the vast majority of Bluesky users are "normies" in that sense. They couldn't care less about "decentralization" and some are even actively against the idea. But the decentralized nature doesn't directly "show up" in the product much, just like it doesn't "show up" when you browse the web and hop between servers. I think that's key to adoption--it needs to "just work" behind the scenes.
Many (likely a majority) of crypto users are "normal" in that sense too, they just want to transfer funds and don't care about concepts like decentralization or privacy.
I attended DevCon and few other crypto dev events this year for work, and it was hilarious how few actual products were present.
I hope that AT / Bluesky doesn't fall into this same trap of iterating over the details of a protocol vs shipping apps that people actually want to use.
For me personally a slightly less toxic twitter isn't that app, but when something comes along that is I'll likely setup a domain for AT.
Much like Git and GitHub (at least for many years, it's improved a little bit now).
git is incredibly useful without github and has been the starting points of thousands of useful apps and clis.
I havent published to gh in nearly a decade and use git daily.
I don't see how. Many large projects have been running with git patches over emails for decades.
Yeah, that’s a really odd take. Git is completely usable apart from GitHub and I would wager that the majority of Git usage happens without GitHub. I personally have far more personal repos hosted on a NAS than anything in GitHub, and while I did work for one company that used GitHub professionally, I can’t imagine it’s anywhere near ubiquitous. Prior to that I worked at a company with 10s of thousands of internal git repos and before their migration to git used a git front end for perforce. Prior to that (and prior to GitHub), I used a git front end for subversion.
I see GitHub as the successor to SourceForge, not a requirement for using git.
I guess we are just in very different professional circles. I've worked with dozens of teams over the last 10 years or so, and I've never come across anyone that self-hosts a repository. The vast majority use Github, and there's been a couple of Bitbuckets, and a couple of GitLabs. That's it.
Prior to that there were a few Subversions, a Perforce, MS's thing (TFS?).
I’ve used Gitea at two companies. One had it on-prem the other in a VPS.
You'll run into them if you ever work for organizations that have strict IP constraints or have no interest hosting their code on a platform in the US.
Coincidentally I have seen that becoming more and more common in my circles since last November.
So is the protocol sort of like a big public kafka topic?
If you want to create a new web app, say, you don't actually store the data yourself. You basically set up a listener to "the big topic in the sky" and ask your users to save all their data in their own respective places, which the protocol will propagate out into the world such that your app's listener will hear about and cache it. Do I have that right? It's a very interesting concept for how to build a web app while the users still own their data.
I don't have a great understanding of the process, though. Are their "offsets" or something to make sure you don't miss updates? Partitions for scalability? Maybe I'm pattern matching too hard to Kafka here.
> So is the protocol sort of like a big public kafka topic?
yes, at least the firehose is that, and anyone can subscribe or run their own
https://atproto.com/articles/atproto-for-distsys-engineers
> to make sure you don't miss updates
Yes, the firehose and jetstreams have a cursor, though with limited time window depending on the instance. (1-3h -> 72h)
If you want the entire history you do what's called a backfill
I wonder, how rigidly has the JSON format been baked into the protocol.
It feels like a shortsighted choice, just because it's prevalent in recent decades.
It took years to implement performant parsers for it and it has a lot of quirks, missing features and the tons of double quotes and mandatory commas significantly harm its human readability...
Not sure what would I recommend instead, but personally I would prefer using EDN instead, as a Clojure programmer
https://github.com/edn-format/edn
You can write lexicon (the schema) in whatever language you want and then transform them to JSON for sharing.
The record format should be something widely used and implemented for sending over the wire. There are lots of languages and ecosystems participating.
We're all sending JSON around all the time, it's not really that big a performance hit, especially in context of the formats transiting networks today (it's the same, lots and lots of JSON)
Author here, happy to answer questions!
Re: what is this even about, see my comment here: https://news.ycombinator.com/item?id=45469167. Sorry I didn't write an elaborate intro to the article; I kind of meant it for a narrower audience of people looking for an answer to a technical question (how at:// resolves).
I'll say this preemptively — actually resolving at:// URIs isn't something you'd do much as an app author because the usual model for apps is to listen to all data commits over the network via websocket (like https://pdsls.dev/jetstream?instance=wss%3A%2F%2Fjetstream1....), and to write to a local database whatever you're interested in. So you'd mostly use at:// URIs as unique global identifiers for pieces of data, but you probably won't actually resolve them since the data will be pushed to you. But it's nice that you can always fetch it on demand too.
I focused on resolving in this article because I think "following along" the resolution procedure is a really good way to understand how handles, identity and hosting are tied up.
I might be pre-empting some future articles of yours, and I'm happy to await either those, or me diving into ATProto deeper by myself some time in the future, but: can any app write any data to a PDS?
And if so, the more interesting question: what if it pretends to write data in the Bluesky format, but e.g. leaves out a field that the Bluesky Appview expects, or writes data in a different format than it expects?
Great questions! Yeah, this is something I want to write about it in the future.
An app can write to PDS if the user grants it access via OAuth. Currently this access is very coarse (which is bad!) although backing up the entire repo is easy (which is good! but should be made more accessible to normies).
There is an active workstream on OAuth Scopes (already partially deployed) which will let apps request more granular access (e.g. apps can write to "their own" collections but also ask to write e.g. Bluesky posts). In UI, this is done through sort of "bundles" of permissions. See https://github.com/bluesky-social/atproto/discussions/4118 for tracking issue.
> what if it pretends to write data in the Bluesky format, but e.g. leaves out a field that the Bluesky Appview expects, or writes data in a different format than it expects?
Atproto data is governed by "lexicons" which are essentially type definitions used by app authors. E.g. `app.bsky.feed.post` type definition is maintained by the Bluesky team. There's a codegen that generates validation code from that definition. If validation doesn't pass, the Bluesky app server will just ignore that record. Records are generally treated by apps as untrusted input, similar to form submissions. They can be validated during ingestion or in the process of usage later.
Let's say I need to resolve @example.com and we use the HTTPS GET method. So we will query https:// example.com/.well-known/atproto-did
Will it work if that link redirects to says https:// example.com/did.txt or even to a different host say https:// foo.bar/some/thing/did?
I don’t think it would follow redirects. See https://atproto.com/specs/handle#https-well-known-method
Edit: I'm wrong; see below
It says "HTTP redirects (eg, 301, 302) are allowed, up to a reasonable number of redirect hops."
Ah my bad, you're right! I glossed over that.
Not sure if you already replied to a similar question but regarding this quote
> the actual server storing my data is currently https://morel.us-east.host.bsky.network. I’m happy to keep hosting it there but I’m thinking of moving it to a host I control in the future
Is the process of moving hosts documented somewhere?
Yep, here: https://atproto.com/guides/account-migration
There’s also tools that can help automate this: https://pdsmoover.com/
> Whoever’s hosting the data could change over time…
But the fundamental fact remains that when you host your data on someone else’s system (without a binding agreement), it can vanish or become inaccessible at any time for any reason. And you won’t have any control over who can access it or why.
Yes, which is already the case with every app you use. But like I explain in the second half of https://news.ycombinator.com/item?id=45471337, you’d still be able to restore your account from a backup to a different host without losing reach or breaking any links.
See also https://blog.muni.town/atproto-isnt-what-you-think/ which goes into more detail on the consequences of this approach.
This is a nice write-up. I recently added post-to-bluesky support to my ongoing social-media-scheduler project [1], thinking it would be the simplest of the services to work on, but I ended up getting really confused instead.
DID and handle resolution was the easiest part of ATProto---as the author says, a library can do the job easily. For Ruby it's DIDKit [2]. Where ATProto really threw me was the seeming non-ownership of record types. Bluesky uses "app.bsky.feed.post" for its records, as seen in the article; there seem to be a lot of these record types, but there doesn't seem to be a central index of these like there are for DIDs, or a standard way of documenting them... and as far as I've been able to find, there's no standard method of turning an at:// URI into an http:// URL.
When my app makes a post on behalf of a user, Bluesky only sends an at:// URI back, which I have to convert myself into an http:// URL to Bluesky. I can only do that with string manipulation, and only because I know, externally, what format the URL should be in. There's no canonical resolution.
[1]: https://toucanpost.com [2]: https://github.com/mackuba/didkit
Record types are now "on protocol", you resolve them via a similar mechanism as in the article. https://atproto.com/specs/lexicon#lexicon-publication-and-re...
As an example of that, if you open any `app.bsky.feed.post` in pdsls, the "Info" tab[1] links has a link to the "Lexicon document" for it:
[1]: https://pdsls.dev/at://did:plc:fpruhuo22xkm5o7ttr2ktxdo/app....
[2]: https://pdsls.dev/at://did:plc:4v4y5r3lwsbtmsxhile2ljac/com....
> I have to convert myself into an http:// URL to Bluesky
at:// URIs and specific lexicon are not limited to a single app. The NSID (app.bsky.feed.post) has authority based on domain, but Bluesky cannot prevent anyone from reading / writing records of that type.
There are alternative apps that read the same at:// but put them under a different https://...
tl;dr, there is not a 1-1 mapping between at:// and https://, it's 1-N
The recommendation to resolve from handles to DIDs for "permalinks" is concerning to me:
- My handle is something _I_ control. I can make it point at a different PDS at any time.
- My DID is something my PDS controls.
I could solve this by indirecting through a web DID under my control, but there's no recommendation anywhere in Bluesky's documentation. Is that something everyone needs to do to ensure real identity portability?
edit: I'm not sure this CAN be solved without running a PDS given that I can't use my own keys. What am I missing here?
This doesn't look right to me.
What you control is your identity (i.e. DID Document). As long as you control your identity, you can change either your handle or your hosting aka PDS.
Your hosting/PDS does not control your DID.
What stebalien might be referring to is that your DID document for PLC specifically is controlled by anyone with the rotation key.
In the Bluesky implementation, this is Bluesky for convenience’s sake, to make it possible for users to easily sign up. (I’m not sure internally if it’s part of the PDS or held separately.)
PLC has a mechanism allowing “higher” keys to override “lower” ones within a certain time window, so being able to add your own rotation key that “outranks” Bluesky’s would solve this issue.
Alternatively, use web DIDs and then it’s fully self-managed just as DNS would be.
Is there any documentation on how to do this without running a custom appserver and/or PDS? Can I create my own DID and delegate to another DID?
This is mostly separate to the PDS - Bluesky is more like the client here (albeit, they also currently run the PLC service). It’s part of your DID document which they manage for you mostly, but there’s ways to take ownership of your PLC DID - see Dan’s links for that.
For our non-atproto uses of the PLC directory, we have similar needs, and we’ll likely let users provide their own public key before we create their document to help solve this. We have a technical audience though, so that solution may not make sense for Bluesky - but there’s a lot of people thinking about how to improve this in the atmosphere.
Ah yes, this might be relevant then: https://www.da.vidbuchanan.co.uk/blog/adversarial-pds-migrat...
I control my domain name and its DNS but I don't have the keys used to sign my DID. I followed the instructions here: https://bsky.social/about/blog/4-28-2023-domain-handle-tutor...
From my reading of your blog post, it sounds like the DID is the ultimate authority and not my domain name, which sounds like a pretty big problem for user portability.
Right, I see. You can get a key that overrides your PDS if you're worried about your PDS going rogue. See https://www.da.vidbuchanan.co.uk/blog/adversarial-pds-migrat... and https://whtwnd.com/bnewbold.net/3lj7jmt2ct72r. This is more complicated than I'd like it to be.
Ah, that's exactly what I was looking for. Thanks!
I guess I get why it works that way (avoids some issues with domain expiration) but... honestly, I'd rather have my domain name in control. Even after registering my own rotation key, I'm still at the mercy of the centralized PLC directory.
Unfortunately, it looks like it's not possible to migrate to a web DID without starting over.
Yeah, you can't migrate a DID. You could bulk-import the content (and even fix internal links within it) but that wouldn't change the links pointing at the old DID.
So the reason to have the DID in control is for users that say sign up for Bluesky and have a bluesky handle which is a domain they don't control and want to move to a different provider without breaking everything. If your handle was the thing in control then you must own a domain to own your account and move providers. That kinds of defeats the purpose of migratable PDSs for the "rest of us" use case.
This is verbose and unclear. An article like this should always start by explaining what problem it tries to solve before going into technical details.
What you might see as verbose, I think is exceptionally clear. Also, the article comes with an entire other article explaining the problem, so not sure what you are on. If you cannot even click on a link, maybe you shouldn't complain about verbosity in the first place.
This is a technical explanation for an audience already interested in the topic.
The motivation ("explaining the problem") is described in the article linked in the very first sentence. Here's a tldr: https://news.ycombinator.com/item?id=45469167
Thanks. It's quite shocking however that GPT did a better job at explaining this to me than the original article.
Which article are you talking about? I think https://overreacted.io/open-social/ (which is what I linked to) gives a pretty detailed explanation if that's what you wanted. As for the article in today's submission, I meant it for the audience that's already interested in the topic, and did not pad it out with a motivational section. I'm glad GPT was useful to you.
What about when Bluesky goes out of business and plc.directory is shut down?
This all seems unnecessarily fragile.
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.
(The article has links there.)
I've also linked to https://updates.microcosm.blue/3lz7nwvh4zc2u and https://plc.wtf/ which are relevant. These are good questions to ask!
What happens when the independent legal entity stops getting funding and has to shut down?
The content can be mirrored, and being content-addressed with an algorithm the client verifies, the mirror can’t tamper with any of it. Switching to another DID method like did:ipfs is also a possibility. It’s not a perfect solution to every possible disruption, but it’s a system designed to evolve in response.
Need a PLC+DHT thing maybe? Or maybe someone will try to blockchain?
What happens when the blockchain goes out of business, doesn't have enough hash to ensure security, or rugpulls?
The PLC is arguably equivalent to a proof-of-authority ledger
This is no different then how the web works. So not a great argument against this protocol.
How does it improve over the existing system, other than slapping the word "decentralized" on?
To make bluesky really lift of and become widely accepted for decentral social media there should be a simple solution to self host your postings. E.g. something you can easily host on a webhosting with php or so. The docker container provided is great but one step to high for broad usage.
Yeah, it needs to be easier to do. It's already getting more accessible with tools like https://pdsmoover.com/ and communities like Blacksky offering hosting. Ideally there would be many such providers.
This seems to fill the same function as DNS, but adds a layer of abstraction on top of it, while also adding a dependency on a service provided by Bluesky. I fail to see how this improves things on the whole.
It builds on top of DNS (in at least in two places) so it’s not equivalent — and it fills a different function to it. See https://news.ycombinator.com/item?id=45469296 for a breakdown.
PLC is being spun out into an independent entity, the longer term goal is for it to operate somewhat similar to ICANN. Its code is easy to run so something else could conceivably replace it. It’s also possible for AT to allow other `did` methods in the future as long as they’re persistent and can be performantly resolved.
I don't see why you need another URI scheme at all.
Most protocols already support usernames: user@domain. All you need to do is make the part after @ optional like it is for email.
Can you clarify what the proposed change is? I don't quite follow. For example, what does `at://did:plc:fpruhuo22xkm5o7ttr2ktxdo/sh.tangled.feed.star/3m23ddgjpgn22` become ?
If you put the data host in the URL, what happens to existing links if I move to a new PDS?
the at:// is effectively content addressing, using the DID as the pseudo-host allows for (1) changing handle (2) changing PDS
Your example does not look like a valid URL to me
That's not a valid HTTPs URL though, is it? Since there's no specific location to hit. Maybe I'm missing something.
Then i did not understand the article, I thought morel.us-east.host.bsky.network was the specific location after resolving the DID.
After 3 years on Mastodon and some lurking on bsky, I believe the main issue is not technical but getting and keeping interesting content on a platform. This is a social issue as bubbles ruin everything over time. OTOH using algorithms to mix some „foreign“ content into the feeds causes outrages. Sure we can all go web3 and self-hosted but nobody will read. Mastodon is the posterchild of a failed experiment. I‘m interested in the creative, productive, inspiring long-tail content on all platforms instead of migrating the peer group over to a new platform every couple of years. I know them already, I have better ways to communicate with my direct peers and the rest is like having 500 contacts on LinkedIn: A social illusion. I appreciate and respect the technical efforts behind atproto, but yet I can‘t see that it solves the problem described above.
> keeping interesting content on a platform
> instead of migrating the peer group over to a new platform every couple of years
> I appreciate and respect the technical efforts behind atproto, but yet I can‘t see that it solves the problem described above.
If I am correctly reading backwards from "does atproto solve this core problem I see" ...
ATProto is a fabric where your data lives and Bluesky is just one app that sits on top of this. Your network and data stays with you if you move platforms or try out completely different apps. Same account, same data, same social graph (if you want to reuse it for other apps or not). Similarly, other apps can access all or some of your data (if you let them), so you don't have to start from scratch and they can provide more interesting content for new to them users (but not new to atproto)
In this sense, as people try out and move around different apps, they don't lose things. Users can even be on different apps, but using the same underlying data, transparent to them. This is called the "credible exit" around the atmosphere (atproto ecosystem nickname) and means (1) you can leave a bad company without them preventing you from taking your data (2) enables real competition in social apps, re: the aforementioned features.
Yeah it's solving a wrong problem. What's needed is means to get enough bandwidth of data, not giving yet another blog site you can post to.
The kind of content that wins the Internet is never the kind that'll be "popular", despite all objective data, so whoever to run the platform has to "algorithm" the system to prefer "popular" contents which destroys the community as well as greater society in matters of decades.
We just needed an RSS with a local algorithm.
In what way is Mastodon a failed experiment? Low number of active users or something else?
"They’ll figure out the physical server where its JSON is currently hosted, and show that JSON for you"
So, DNS?
A combination of DNS and HTTPS (as described further in the post).
Why do they use forward names for the username, but backward names for the server? That's inconsistent.
Backward names are not used for the "server". (I presume that by "server" you mean hosting, which is determined by the `serviceEndpoint` in the DID document rather than by something in the AT URI, as the article explains.)
If you're asking about “app.bsky.” in the AT URI, it doesn’t indicate a server you’re going to connect to. As stated in the post, it indicates a data format. Think of it as a file extension which describes who governs the schema of that JSON.
Formats (called "lexicons" in AT) use a reverse-namespace scheme so that formats governed by the same app appears next to each other alphabetically. That might remind you of Java.
Finally, some love for for did:web.
webvh seems to be getting some love as well recently, which addresses at least one of the downsides of it.
It’s kind of annoying that a huge number of DID methods are specific to cryptocurrencies and are practically abandoned.
Performance worries me when reading that.
Even with having a cache as explained.
As stated near the end of the article, this isn’t something you’d do much as an app developer. The article describes how to pull but the predominant model for building apps is to have the data pushed to you. So in practice you’d use at:// URIs as unique identifiers for the data you’re receiving and indexing on your backend, not something you actually need to resolve. You wouldn't need to resolve them because you'd be receiving the JSON itself via the websocket.
To add, it's largely required for an app to listen to the event stream because a user may write a record you care about directly (not through your app), and you likely want to know about that as "real-time" as possible. Crawling will never get you close to that
I've never really gotten AT protocol. It just seems like reïnventing the web. I guess it's a little more secure than the normal web because there's no JS, and you can make it seem more integrated because users won't have custom styles, but neither of these are particularly appealing to me. HTML + RSS does basically the same job, and then link aggregator sites like news.ycombinator.com recommend content much better than the algorithms you get in social media.
I guess the big advantage is reposts and comments, but practically you could achieve these in the regular web through indexing with backlinks. The conceptual service Bluesky is providing is essentially just a web-index of items published using the AT protocol.
I tried to make a pretty extensive case for it at https://overreacted.io/open-social/#open-social, I'd suggest reading it with an open mind to form an opinion. I think there's quite a few interesting aspects there, like apps being able to "piggyback on" data from other apps.
I wouldn't call AT a "reinvention" of the web, personally I see it as a minor bump that codifies some conventions that let apps interoperate while keeping the source of user data outside those apps. New products can be started from data of other (even defunct) products and remix it. That's pretty powerful.
So what you need is a sort of document or object-level DNS?
Sure would be tough, because it makes name distinction a lot harder, and it's going to be a lot more granular?
So the atmosphere is in the cloud
how can it be hacked? can i impersonate someone else? whats to stop me from making posts with someone elses handle. how secure is the data? or does it just ride over tls and use that for protection.
Every commit in your repo is signed with your private key which stays on your hosting. (You also can get another special key for your identity that would let you force-change hosting if your hosting gets adversarial.) Changes from your hosted repository get transmitted as signed commits (kind of like Git) so they can be verified by those receiving the retransmission against your public key.
I don’t understand what this is or why I might need this beyond the blue app echo chamber.
Here's another article answering this question: https://overreacted.io/open-social/. The one you're commenting on links to it in the first paragraph with "if not, read this!" for that exact reason--I can't explain the motivation and technical details in the same post, or to repeat the same explanation from post to post.
Here's a tldr if you don't want to read the entire thing: https://overreacted.io/open-social/#the-big-picture
I read this article the other day and I am not sure what the breakthrough is with AT/bsky. It seems like the functionality "This blurs the boundaries between apps. Every open social app can use, remix, link to, and riff on data from every other open social app." is already provided on the web through hyperlinks.
There is seemingly nothing in the AT protocol that prevents sites from defederating and enabling vendor lock-in, just like how every other social media site has switched to requiring you to log in to see links.
There is seemingly nothing usefully decentralized about it. There is some sort of psuedo-distribution where you can host on your own domain. But like email, I imagine these types of users will be effectively blocked due to spam filtering.
It's like P2P if it was invented by people who know nothing about P2P, but just want to create a version of twitter that is immune to the company being bought out by someone they don't like and instituting a different censorship regime.
> already provided on the web through hyperlinks.
Yeah except there’s no guarantee of structured data there! With AT, each record is specified using a corresponding lexicon—making for much more straightforward interop.
> There is seemingly nothing in the AT protocol that prevents sites from defederating and enabling vendor lock-in, just like how every other social media site has switched to requiring you to log in to see links.
And that’s fine! Any site can choose to do whatever they please—but the underlying AT records always remain accessible to other consumers (apps, users, …).
> I imagine these types of users will be effectively blocked due to spam filtering.
Blocked by whom? If the relay (which pulls records from your PDS) “blocks” your PDS, you can simply switch to one that doesn’t. The beauty of AT infra is every piece of it can be run separately. That’s “meaningful” decentralization.
>Blocked by whom? If the relay (which pulls records from your PDS) “blocks” your PDS, you can simply switch to one that doesn’t.
Blocked by pretty much everyone, in the case of email. If most people use gmail or hotmail, and these mail providers block mail from new domains regardless of DMARC/DKIM/etc. then you are effectively blocked from sending email to most people. It's inevitable that this happens because there is no sybil resistance built in to the network layer, so providers have to be blocky to prevent spam.
> The beauty of AT infra is every piece of it can be run separately. That’s “meaningful” decentralization.
So kind of like how in the web, every website can be run separately?
You can switch, but everyone else won't coordinate to switch at the same time. So you have been deplatformed. It is the same with the web, where if you get banned from a forum (perhaps one that changes its rules to suit sponsors), you can switch to using a forum that no one uses due to network effects.
>There is seemingly nothing in the AT protocol that prevents sites from defederating and enabling vendor lock-in, just like how every other social media site has switched to requiring you to log in to see links.
Note there is no "federation" in the Mastodon sense; sites don't "talk to" each other. They just all aggregate data from the web. Yes, an app doing that could potentially stop "posting to" and "aggregating from" the web in the future and move the source of truth to a local database. But by doing that, it mostly just loses interoperability--and someone else could start a new app with the already existing data on the network, effectively forking their product with its users/data.
>It's like P2P if it was invented by people who know nothing about P2P
Ironically quite a few people on the team come from the P2P world, which is also why they have experience with where P2P doesn't work. Give https://atproto.com/articles/atproto-for-distsys-engineers a read.
If you don't know the difference between a protocol and an application you're going to want to start with something more elementary than this.
If you don’t know the difference between an ad hominem and any other answer, I can’t even begin to tell you what you’re going to have to start with.
The at protocol seems a little Nebraskan Church Excel doc complex: https://xkcd.com/1667/
this may help see it as an "anyone can participate at any point" event stream
hence why it is called the "activity transfer protocol"
https://atproto.com/articles/atproto-for-distsys-engineers
ATProto is even more overhyped than Rust. I'll stick to Twitter and Usenet, thanks.
This is some newfangled shit to be sure. I guess it’s time for some old dogs to learn some new tricks of this new web..
I fail to see what problem this thing solves.
Listen I'm not a crazy huge fan of a lot of new tech, but this is pretty transformational. When reading the first article [1] I was struck by the fact that it granted so much new freedom to your "social identity" on the internet. The comparison to hosting providers was incredible, because imagine you building a website and posting your thoughts there or starting a business there...and then immediately being shut down and all your data lost because of some arbitrary change of policy at your "host".
Everyone always talks about how your Google account being tied to logins is scary because you can get arbitrarily locked out. This protocol makes something like functionally impossible since /you/ control your data.
[1] https://overreacted.io/open-social/
> Bob, however, isn’t technical. He doesn’t even know that there is a “repository” with his “data”. He got a repository behind the scenes when he signed up for his first open social app.
> Bob uses a free hosting service that came by default with his first open social app.
> If she owns alice.com, she can point at://alice.com at any server.
But does Bob own bob.com? That sounds beyond Bob's abilities and interest level. So Bob is stuck on one platform, in practice, and it's full other Bobs who are also stuck. The "free hosting service" (why is it free?) is now the gatekeeper. It may let him switch platforms.
Even if bob "owned" bob.com, that amounts to a row in some centralized database somewhere.
Technically sure, but (1) apps that Bob uses have no power over that database, and (2) if someone were to remove that row, Bob could change his handle to something else without losing his identity, data, or reach.
It seems to mean that Bob's free hosting service has to be a relatively benign and permanent institution like ICANN, and not some ropey old operation like Photobucket.
Others on this thread are talking about Decentralized IDs, https://en.wikipedia.org/wiki/Decentralized_identifier . Looks like those are stored in several competing systems. There's a blockchain one, a Chinese one that wants to know your real name, and a Microsoft one that wants to store your photo. This all has, uh, implications, which sound much less liberating than this at:// protocol does at first.
ICANN is relatively benign but not benign.
Did they invent the idea of a keypair?
You could do it with top-level domain names alone, but that would require users to buy domain names and retain control over them forever. It means you have to trust your domain registrar and pay them fees. This is too big a burden for new Bluesky users.
You could do it more cheaply with subdomains, but then you have to trust the owner of the parent domain.
So instead, they created a new registry and a way for users to cryptographically sign their registry documents. Since this is all done behind the scenes, most users are still fully trusting the central Bluesky infrastructure. But in theory, they could migrate off of it.
Here's a TLDR on the problem it solves: https://overreacted.io/open-social/#the-big-picture. I've linked to this article in the intro. In short, it's a different model where apps participate host user data on the web under user's control. This enables some interesting use cases, like all apps can deeply interoperate by default. It's hard to explain this concisely, the article I linked to is my best attempt.
I understand, appreciate, and share the desire for a decentralized and censorship-resistant social graph. I'm just not sure what problem the new URL scheme solves. Is DNS not already decentralized? It's not that I don't see the value in what you're trying to do --- it's that don't understand what problem you're solving that we can't solve with hypertext, RSS, and data attributes.
> The advantage of storing structured app-specific entities, such as posts and likes, instead of HTML documents is obvious.
Agreed.
> This allows you to create many projections of the same data—a profile page, a list of posts, an individual post with comments.
WE HAD THIS! In some sense, we still do. XSLT exists. The dream was always that XML documents linked together with defined schemas would be the source of truth for an information web and we'd style them dynamically to provide for different UIs.
I mean, look. Maybe the XML-centric semantic web was just an idea before its time. Maybe at:// will succeed where it didn't due to timing, real-world social context, or just the force of will of its proponents.
But from a technical POV, I'm just not seeing why I'd want to use this instead of reviving those older but proven technologies.
This is building on top of DNS.
At the center of at:// is a question of identity.
For identity, you want some kind of a global login, or a "handle", that you can remember. at:// uses domains for that (e.g. my "handle" is danabra.mov). That is literally DNS.
However, you also want somebody to hold your data. Most people don't want to host their own data. (I don't.) So that's where the notion of hosting comes into play. My current host, as explained in the article, is https://morel.us-east.host.bsky.network. (That's also resolved through DNS.)
Finally, the important bit is that I (as an identity) should be able to change both my handle (i.e. how people refer to me) and my hosting (i.e. where my data is stored) without breaking any links to my data from other data ("links between JSON" is how we represent "reply to a post", "like to a reply", "follow of a person", etc). This is why links are tied to an identity rather than to hosting or to handle. The identity document also contains my public key which is important to allow trustless caching and retransmission of the data.
That's about it.
>But from a technical POV, I'm just not seeing why I'd want to use this instead of reviving those older but proven technologies.
I think everything being signed is a big one. There is no need to trust anyone retransmitting the data because it's transferring signed commits. But yes, this is essentially a fusion of something like Git with something like RSS, but for JSON and on top of DNS, HTTPS, CBOR, and WebSocket.
Compared to RSS, the novel parts is that you don't need to trust the retransmitters, that it's pushed via WebSockets, that it scales to real-time communication for millions of users (in production today), and that it's application-agnostic but the data formats are application-controlled. E.g. we have different apps like Tangled.org (GitHub on atproto), Leaflet.pub (Medium on atproto), etc, all able to "see" each other's data and interop.
why do I want a global login? that sounds like hell.
>however, you also want somebody to hold your data
No I don't. hosting the data isn't that hard in a P2P network. See syncthing, bittorrent, etc. Convincing someone else to host my data will be harder.
How is websockets better than XHR in this case?
> why do I want a global login? that sounds like hell
Ask social media users if they would like one account or separate accounts for every platform, they think that later is the hell
OAuth is one piece of evidence that confirms this general pattern among online users. Fewer accounts are easier to manage, just give me a click to login button on your site for an account I already have and manage elsewhere
Even the people I know IRL seem to avoid linking all of their accounts, and are pretty frustrated at getting locked out of google/apple whatever.
we tend to select similar people into our IRL circles, what do strangers say?
I'm reporting what I'm hearing when asking people I don't know about what they like / dislike about current social
I don't socialize with other nerds IRL. I know what you're getting at, but I think it's at the point right now where "normal people" have paranoia of getting locked out of their google/apple accounts, because it has happened to pretty much everyone I know at least once.
They both send you through the loop of assuming you have a device, so if you lose your device you're screwed.
For example, you can even see memes like this are very popular:
https://www.youtube.com/watch?v=pBcPOx8_YKw
>why do I want a global login? that sounds like hell.
You can still have many distinct identities if you want to, the point is just that you also don't have to for cases when you want to have shared data flowing and interlinking between apps.
>How is websockets better than XHR in this case?
Websockets are used for retransmitting changes from millions of repositories to a bunch of apps that want to aggregate over that data and create app-specific indexes. I'm not sure what XHR has to do with that or how it helps there. Have a look at the data stream: https://pdsls.dev/jetstream?instance=wss%3A%2F%2Fjetstream1....
> Finally, the important bit is that I (as an identity) should be able to change both my handle (i.e. how people refer to me) and my hosting (i.e. where my data is stored) without breaking any links to my data from other data
But that's how the web already works. If I own example.com I can change its target from, say, 1.2.2.2 to 2.3.3.3 any time I want. My identity doesn't change even while my host does. What's the difference?
If you want another layer of indirection, add a CNAME or a 30X redirect.
> The identity document also contains my public key which is important to allow trustless caching and retransmission of the data.
Sure. That's what DANE (https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...) is for!
> on top of CBOR, and WebSocket
We have a perfectly good web built out of normal, boring stateless HTTP requests and text formats. I'm skeptical of switching to stateful sockets and binary formats. I prefer my technologies to be minimal deltas built atop stable, proven foundations, and my NIH spidey sense is tingling when I read about stuff like this.
Why wouldn't adding per-update signature data to RSS (including previous entries, blockchain-style, in the hash) do exactly what this stack does but without all the new technology?
DID is basically one extra level of abstraction, allowing for different methods.
did:web: eg is literally HTTP, did:dns: is DNS, and there’s loads of others.
This extra level of abstraction allows of arbitrary IDs, which is what the PLC DIDs were created for.
Let’s say that I am currently known as rmccue.com.au. I move overseas and now want to be rmccue.scot - or worse, because I am no longer in .au, I can’t even keep my old domain name. How do you persist this identity?
With PLC, I can instead be an abstract did:plc:hv27plmlx6zkuv7bnzbqb6xr (an arbitrary hash of the genesis entry for my DID). I associate rmccue.com.au with this via a TXT record, and back the other direction by recording the domain as an alias.
If I change my handle, I’m still the same arbitrary handle everywhere, everyone keeps following me, and in theory old references to my alias could even continue resolving.
(Similarly, this solves the issue for trademark changes, name changes throughout a person’s life, and changing job roles.)
The core of it is basic tech:
1. Look up _atproto.rmccue.io for a TXT record
2. If it’s did:plc:… send a HTTP request to the directory - eg https://plc.directory/hv27plmlx6zkuv7bnzbqb6xr
3. Parse the JSON response to get my signing keys and where I’m hosted.
Ah, thanks. Might you consider going full DHT for name lookup then?
There’s some DHT-based DID methods so it’s possible - one of the nice things about the DID abstraction layer is that could be added.
As I understand, atproto is intentionally limiting to PLC and Web for now, and monitoring the ecosystem. Every method has to be implemented by every client, so you naturally want to be cautious in how many you support.
(I don’t work for or represent Bluesky, so can’t speak to any plans other than what they’ve stated publicly!)
>But that's how the web already works. If I own example.com I can change its target from, say, 1.2.2.2 to 2.3.3.3 any time I want. My identity doesn't change even while my host does. What's the difference?
To clarify, we're talking about generalizing the notion of a "username" or a "handle". E.g. I started with `danabramov.bsky.social` (given out to me) and then moved to `danabra.mov`. I might move to some other domain later. The idea is you should be able to do this as many times as you like without a chain of redirects where losing one domain in the chain loses all your links. (Also, "normal" people don't know what a redirect even is, much less how to set one up.) Hence, an indirection is "above" the chain rather than a part of the chain. The DID points at the domain.
In other words, "normal" people don't want their social media reply chains, or social media mentions, or their GitHub issues, or their Medium articles, to break when someone else swaps their user handle. We're using handles for domains so we need to add an affordance so they "act like handles".
>Sure. That's what DANE is for
Not familiar with it so can't comment unfortunately! But hopefully the above gives some context. We want to stay decoupled both from the handle and from the concrete hosting. Changing the handle and changing the hosting should be doable with zero cooperation from whoever holds your previous domain or previous hosting.
>We have a perfectly good web built out of normal, boring stateless HTTP requests and text formats.
Yes, and that still works — you can pull it on demand with plain HTTP as I show in the article. The CBOR/WebSocket stuff is for the high scale use case (have a look at https://pdsls.dev/jetstream?instance=wss%3A%2F%2Fjetstream1....), i.e. realtime large-scale social aggregation.
>I prefer my technologies to be minimal deltas built atop stable, proven foundations, and my NIH spidey sense is tingling when I read about stuff like this.
I hear ya! Someday it might become boring too. (See https://datatracker.ietf.org/doc/draft-newbold-at-architectu..., https://datatracker.ietf.org/doc/draft-holmgren-at-repositor...). I personally find the additions tasteful and minimal for what they try to accomplish.
>Why wouldn't adding per-update signature data to RSS (including previous entries, blockchain-style, in the hash) do exactly what this stack does but without all the new technology?
I'm not sure how you'd represent arbitrary application data in RSS (e.g. Tangled.org is essentially "GitHub on atproto"), how you'd do high-scale fanout with RSS (realtime to millions of users), or how you'd have properties like ability to move hosting with no disruption to user-visible experience in downstream apps, and no reduction in trust in the data.
Ah. Thanks for the explanation
> To clarify, we're talking about generalizing the notion of a "username" or a "handle".
Name registries are hard. How do you handle collision avoidance and impersonation resistance?
You can do registration centrally and hierarchically like DNS.
You can generate collision-resistant tokens (e.g. GUIDs) and do some kind of content-addressed metadata lookup thing, perhaps via a DHT or something. These names are opaque though.
You could allow people to generate names consisting of a recognizable name _paired_ with an opaque token, but if you do that, you open yourself up to impersonation attacks --- quotemstr-B87FAEAB-9D34-418D-A6E9-B95BEBC9DD0B vs C243F0B4-AF9A-4F48-9880-8436B1C15293.
AIUI, the concept here is that DNS names can point to opaque tokens and that the token can remain stable without requiring continuity of DNS registration?
What do you think of Namecoin, which seems like what you get when you follow this line of thinking to its logical conclusion? Without something like NC, isn't any registration scheme not centrally gated subject to infinity sybil attacks?
There’s a bidirectional link between a user handle (domain) and their identity (a DID). But the data is logically rooted in the DID. Domain handle is an alias that can change over time — but your DID never changes. Links are stored with DID so that changing your handle doesn’t break existing links.
I'm with you this seems to be reimplementing the wheel but, recently XSLT has been widely deprecated. And the (sole?) maintainer of some very core infrastructure for that is paused or archived or something that will slow/block features and fixes.
So, is a revamp, new code with less baggage, doing the same-ish thing. Then in 20 years it will have the baggage and we'll get a new one.
Queue the Xkcd about infrastructure.
Data sovereignty and distributed identity. It's trying to avoid a centralized authority on where data is stored or how to resolve and trust an identity other than DNS and using signatures to validate data that you didn't get directly from the author.
It’s Web3 reanimated.
I like to think of it as Web3, the good parts.