> 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.
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.
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?
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.
> 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?
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.
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!)
>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?
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....
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'm reporting what I'm hearing when asking people I don't know about what they like / dislike about current social
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:
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.
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 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.
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 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 if you don't want to read the entire thing: https://overreacted.io/open-social/#the-big-picture
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 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.
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.
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.
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?
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.
> 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?
There’s also tools that can help automate this: https://pdsmoover.com/
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?
Edit: I'm wrong; see below
This is chicken and egg stuff. I don't get it and I've picked on the intro of the explainer. Why would I want "the JSON"?
Yes, I did skim the "read this" link.
It's not for me.
In short, at:// protocol lets you build apps that can deeply interop and query/embed each other's information, allow the user to have a shared user identity between apps, and allow the user to self-host their content (or move their hosting) without impacting the apps. It does this by giving bits of JSON permanent URIs that aren't tied to a specific user handle or hosting server, but instead are rooted in identity. The article describes how that works (and what an "identity" is) in technical detail.
Here's a concrete example: a blogging app (https://leaflet.pub) automatically "sees" mentions of a Leaflet post on a different microblogging app (https://bsky.app) and can display them: https://bsky.app/profile/o.simardcasanova.net/post/3luujudlr.... This is not done by hitting an API; it's just that both apps aggregate the same information from the open network into their respective databases.
To your "This is not done by hitting an API" point; if I understand correctly, I'd argue that the _endpoints_ that you detail in your post _are_ the API. The whole point is that there's no single _central_ API, but each server that wants to be part of the network participates by hosting an API that meets the standard outlined in the protocol.
In a way it's semantics, but I'd be interested in yours thoughts on that. To either correct or confirm my understanding.
This is 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".
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
Basically, there's two main roles in the system:
- A user's personal repository -- that's sort of like Git hosting, with a server that can serve a JSON record or a stream of commits. That's PDS. It's application-agnostic. Bluesky's open source implementation of PDS does in fact use sqlite (per each user :). Each user has exactly one repo that stores data of all apps.
- An app -- that's any arbitrary app backend. Could be literally anything. These write data to user's personal repo (for the stuff user creates). They can directly ask a particular user's repo for data (like explained in the article) or they can subscribe to the commit stream and mirror the data they care about in a local database. Then it can be queried and retrieved with no delays, and also can be aggregated (e.g. calculate count of likes for a given post, even though they "live" in different users' repos).
Does this make sense?
This is oversimplified but is a decent question to prompt an explanation for someone new to DNS, HTTP, TLS, etc.
This all seems unnecessarily fragile.
> Bluesky is currently moving PLC to an independent legal entity in Switzerland to address some of these concerns. The AT community is also thinking and experimenting.
(The article has links there.)
The PLC is arguably equivalent to a proof-of-authority ledger
I do think some DHT like things could help. On AT if you lose your domain it's a disaster (right?) I'm foggy on the move to new domain for identity process.
So, DNS?
We picked the same DID systems for https://fair.pm/ to decentralise WordPress plugin distribution (and general management for user-facing packages; think App Store rather than Cargo).
The Bluesky folks (especially Bryan) were super helpful in helping us out - even shipping Ed25519 key support so we could use libsodium.
(We’re designing our protocol on top of DIDs and using Bluesky’s stackable moderation, but chose not to use atproto directly - but the great thing is that DIDs are a W3C standard, and PLC isn’t tied to atproto.)
(More info on the linked site; I don’t want to hijack the thread too much.)
Isn’t PLC (a did method created by bluesky) tied to bluesky (or some other central authority)?
Why do they call it a did when it’s centralised?
As did:plc isnt portable, why didn’t they just use did:web, and decorate the identity docs with PLC-like behaviour?
Why isn’t the method-specific-id part of the did something deterministic/portable, like a hash of a public key that can at least permit some revolver-driven portability?
Why didn’t they use some mechanism for decentralisation, like a DHT (e.g. did:pkarr)?
It seems to me that PLC is thinly veiled attempt for another master to exert control.
>Isn’t PLC tied to bluesky (or some other central authority)?
Yes, PLC is currently tied to Bluesky, and is in the process of moving out into a separate legal entity (https://docs.bsky.app/blog/plc-directory-org). It would indeed remain centralized.
>Why didn’t they use some mechanism for decentralisation, like a DHT (e.g. did:pkarr)?
AFAIK Bluesky is open to supporting more did methods in atproto in the future as long as they can act as permanent identifiers. I found a response from Bryan about `did:dht` here: https://github.com/bluesky-social/atproto/discussions/2705#d...:
>did:dht is interesting and maybe could work, for atproto, but there have been many DHT projects in the history of decentralized computing, and only a small handful have really worked out. AKA, been resilient to abuse, attacks, neglect, etc, over years and decades. magnet links are cool but kind of the exception to the rule. I think if the W3C standardized did:dht it could be a real contender, but somebody needs to carry the flag and demonstrate it working "in real life" with millions of users, and I suspect that will be difficult, and I would not expect Bluesky to lead that charge (we already have our own pet DID method to maintain and support).
The method specific ID for PLC is a hash of the genesis operation, so it’s not just an arbitrary ID that the PLC server creates.
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.
The ID is deterministic, you can reconstruct it by hashing the genesis entry in the audit log.
If you lose your domain, you lose your account. The PLC doesn't have this particular issue
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.
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
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
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
Yes, some centralization was exchanged for not being blockchain based, an acceptable tradeoff imho
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
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.
> 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
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.
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.
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?
>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.
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.
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...
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.
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.
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.
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.
- 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.
Your hosting/PDS does not control your DID.
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.
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.
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.
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
hence why it is called the "activity transfer protocol"
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.
You can change your domain with no cooperation from whoever owns your current domain. And you can change your host, provided you have a backup of your data. (If the old hosting doesn't cooperate, you'd also need a rotational key.)
Approximately 0% of email users could change email host, and prove their identity between the old messages and the new messages.
The value is it caps bluesky's "window of abuse".
Platforms like Facebook or Twitter have dialed up the enshitification far beyond what I find acceptable, but many people are still on there.
A competitor to bluesky can decide how to approach it. Like staying (partially) compatible, and decide to compete on UI, repo storage, or user admin.
Indeed, and as a result, such users will always be vulnerable to specific risks like sudden bans, i.e. when the hosting service becomes adversarial. The only full protection is to own your own domain off a neutral TLD, with protocols that use DNS to describe how traffic should be routed.
But, because most users don't have domains (as you pointed out), the state-of-the-art can still be improved upon with partial flexibility and protections, when the hosting service is cooperative. This project allows people to keep their Bluesky handle (because they don't own a domain) while (hypothetically) moving their data hosting to a different provider, unlike current Big Social where your data is stuck on Facebook/X/Instagram/TikTok/YouTube forever. Bluesky has an interest in this because it also allows people to set up their own handle and move their hosting to Bluesky.
Sometimes we improve upon the existing state of the art not by delivering perfect solutions, but by delivering improvements upon limitations that we accept as a given (like the fact that most users will not set up their own domains).
Unlike with web redirects, you don't need cooperation from whoever owns the old domain because it's the DID Document that controls which handle you use, and you still control the DID Document even if you lose your handle. (That's part of what my article tried to explain by showing the flow: domain is resolved to DID, DID is resolved to hosting, links are stored with the DID.)
When you change your handle, all your followers/posts/etc stay with you, it just seamlessly updates in the apps you use.
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.
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.
Yes, via DNS, of which you have lost control if you use did:web, unless you decide to have your did:web links resolve to a secondary domain under a separate TLD, registrar, and payment method, which only the most paranoid individuals will accept the overhead of doing.
Because you lost control of DNS, the new domain controller may decide to take those DIDs offline, or direct them to a different server for which the domain controller will receive a valid web PKI cert from the likes of Let's Encrypt since domain control is used to determine ownership. This will break pre-existing links.
Your claims are true only when using did:plc, under which your identity is ultimately controlled by a third party, with associated risks, see original post. Yes, domain control is also controlled by third parties (either the TLD owner or a registrar could steal your domain), and there's a good-faith debate to be had over which is safer, which is why the reigning advice is to use a neutral TLD and boring registrar with a good reputation.
Wait until the Chinese, etc. start to come in and threaten to start to block ATProto-based social sites en-masse (Bluesky in particular but other ones as well) until plc.directory takes down the DID links to dissident content, then we'll see how small the risks of did:plc really are.
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.
In AT, data is tied to identity (DID), not handles or hosting. That’s what my article tried to explain.
If you lose the “handle” domain, all it means is that you won’t have a valid handle (which apps will tell you about) but your posts will remain up (they’re still addressable by your DID, which is how apps look things up). In the Bluesky app, for example, it would say “invalid handle” instead of your username. However, it’ll work. It’s the same situation as what happens if your domain expires or you delete your records. Your data is still there, you’re still “followed“ by the same people, etc. A handle is just an alias.
All you’ll need to do is to change the handle, thereby attaching a new domain, through any app that has the “change handle” flow. (It’s enough to have one app that gives you free ones.)
With hosting, it is similar (although there are barriers which need to be lowered). If your repo shuts down, you absolutely can move it somewhere else provided that you have a backup of it. Backups are trivial to automate on AT so this is something I expect hosting providers to offer. There are already third-party apps that regularly do backups for you. And you can export your repository from some clients as well (eg from the official Bluesky client).
In the “happy” case, your hosting will cooperate with moving your repo to another host. See https://pdsmoover.com/info.html for the happy case.
For the “unhappy” case where your old hosting doesn’t cooperate, you also can move if you saved a rotational key. See https://www.da.vidbuchanan.co.uk/blog/adversarial-pds-migrat.... This requires some technical knowledge today but you can imagine a backup solution having that feature also.
And when your repo goes up again at a different host, the difference will be imperceptible to you or other users, since it's signed by the same identity. All your posts, followers, etc, will "come back" with no disruption or broken links.
This is very different from email. Yes, there's some technical know-how in setting up protections if you expect to be adversarial to your hosting, but you do have that ability, and I expect with the AT ecosystem developing, it'll be much more user-friendly to set them up than it is today.
But there's exactly two types of identity, one of which requires you to have a domain (did:web:), and the other relies on a centralized registry owned by a third party (did:plc:). Still the exact same problem.
So I wonder if the protocol could be extended to allow migrating from a did:plc to a did:web. Or maybe to did:plcalt (alternative plc server. I just made this up but I think you get the idea).
If I understand correctly, it should be trivial to prove you own a plc identity, even if the plc is rejecting further changes to your id, so long as you can tell the network in some way an alternative place to look.
Edit: as per https://updates.microcosm.blue/3lz7nwvh4zc2u it seems like there are some theoretical mitigations to an adversarial plc, but overall it seems like if a plc was adversarial starting today it would damage the ATmosphere quite a lot.
If you own the domain, that’s fine. If it’s a thirst party domain and they refuse to cooperate: you’re screwed.
Until you don't. As opposed to a server you host (together with its data), for domains you are at the mercy of the registrar.
This was one (tiny, to be honest) of the considerations I had when choosing a registrar in my country, we are under one legislation, so my hope is a bit higher to recover it if needed.
I heard about that happening with a popular server under .af, but didn't see a follow up.
Er, unless you rely on a centralised registry, but then you’re depending on their good will. You’re back to the same situation as using a centralised service.
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.
Sure would be tough, because it makes name distinction a lot harder, and it's going to be a lot more granular?
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
[1]: https://pdsls.dev/at://did:plc:fpruhuo22xkm5o7ttr2ktxdo/app....
[2]: https://pdsls.dev/at://did:plc:4v4y5r3lwsbtmsxhile2ljac/com....
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
I see GitHub as the successor to SourceForge, not a requirement for using git.
Prior to that there were a few Subversions, a Perforce, MS's thing (TFS?).
Coincidentally I have seen that becoming more and more common in my circles since last November.
I havent published to gh in nearly a decade and use git daily.
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.
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.
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.
> 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.
Even with having a cache as explained.
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.
Most protocols already support usernames: user@domain. All you need to do is make the part after @ optional like it is for email.
https://did:plc:fpruhuo22xkm5o7ttr2ktxdo@/sh.tangled.feed.star/3m23ddgjpgn22
https://did:plc:fpruhuo22xkm5o7ttr2ktxdo@morel.us-east.host.bsky.network/sh.tangled.feed.star/3m23ddgjpgn22
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
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.
It doesn't have an algorithm, it only shows you who you follow in chronological order.
It's not for profit, so it isn't trying to drive engagement. Chasing engagement just leads to feeds full of spam, clickbait and ragebait.
I'd personally recommend the "For You" feed (https://bsky.app/profile/spacecowboy17.bsky.social/feed/for-...) which learns likes faster and doesn't push random content.
"Dev Trending" (https://bsky.app/profile/hawkticehurst.com/feed/dev-trending) is another good one.
IMO Tumblr's constraints were quite unique in the social space: a userbase that one could quite naturally (and with a badge of pride) describe as "rabid" in its expectations that their historical dash experience be preserved in much the way it had been in the early 2010s (with or without a ball pit included); a legacy PHP codebase without the benefits of Meta's resources; and ownership under various companies throughout the years that (from an outsider's perspective) did not prioritize algorithmic optimization of its feeds as a C-suite-driven priority, unlike practically every other social network at scale.
The result is systems like https://github.com/Automattic/stream-builder that enabled Tumblr product teams to define Following, For You, Your Tags, Popular etc. feeds with complex but deterministic and predictable specifications, where each feed would round-robin each slot from a mixture of well-defined component streams.
I'm not as familiar with Bluesky's implementation, but I imagine it has a similarly predictable algorithm for these user-defined feeds.
I would encourage anyone building any kind of discovery experience to look at this repo, at least at its readme and guide, for inspiration. You can, and should, build magical experiences without needing to make your feed algorithms inscrutable. Not everything needs to be TikTok, and I think the world can be a bit more sane if we don't have that as our base assumption as engineers.
IMHO this is how "social-media" should work instead of being forced-feed with some automatic crap
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.
Maybe it's not instant? Maybe it needs some time to generate and cache new results for you and the millions (?) of other users?
I use https://graze.social
I went back to Mastodon, it’s much better to follow tech people.
And feedly for RSS to get all the news I can dream of.
Not sure what the point of Bluesky is anymore, it’s just twitter but on the left side of politics. Sad, the tech stack was interesting as an evolution of Nostr.
I don't know how it is on Bluesky, but on Mastodon I only see posts from people I follow, including posts they've boosted. When I see interesting boosts or replies, I check if those are people I want to follow. Works great.
Follow people. Carefully curate who you follow. Your feed will be exactly what you pick. It's a lot like old-school Twitter before it went algorithmic.
To me this is where the entire model breaks down and becomes 100% centralized.
At the very least, I would expect that there would be a configurable list of such trusted directories, entirely decoupled from the protocol itself, similarly to DNS roots or CAs.
Remember all the chat services that supported XMPP before they killed that? Same level of guarantee here. If most users are expected to choose the centralized option it might as well be the only one.
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.
See also https://blog.muni.town/atproto-isnt-what-you-think/ which goes into more detail on the consequences of this approach.
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 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.
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.
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 have a web app that produces atproto records, app.cartes.comment.
My server listens to Jetstream and builds its DB based on this. But what about if my server goes down for say 4 days ? How can I rebuild my DB to catch up those days ?
It looks like Jetstream cannot work for this.
My need is simple : give me all the records of the collection on the whole atmosphere. How to do this ?
But besides even whether it would ever make business sense, I worry about basic things like:
- If you own your data, can't you change it at any time? I can make perfectly reasonable posts that lots of people agree with, then change it to vile stuff. Even if existing sites at the time store hashes and prevent updates, a new site loading the post will never know it was once different.
- How are things like upvotes tracked? If every upvote is an object stored by the person upvoting, how do you even find the people upvoting? And doesn't it become trivial to create tons of fake profiles upvoting everything you do?
- And how is moderation/spam even handled? Now if sites are supposed to be showing replies to posts made from everyone across any platform, not just their own, how is moderation handled when you don't know anything about these accounts making replies?
I just don't understand how all of the necessary work around transparency, accountability, moderation, and spam can be done in a world where users store their own data, and therefore can fake their own data.
As for the identity moderation part, if you read up about DID, it tells you how to know who they are and you can block them or do whatever you need to do. The point isn’t that this is some blockchain, it’s just a federated method to share data when you own the data. Poison well attacks aside.
In the end, it’s a way to say this person, generated this data, at this location, in case you’re interested. If you care about the things you mentioned, you might not be interested at all.
Because you are being adversarial and trying to trick people.
> if you read up about DID, it tells you how to know who they are
But it doesn't tell you're they're not a spammer. I don't see anything about reputation.
> in case you’re interested
But that's the point. You're interested in legitimate upvotes to try to find useful content. You're not interested in spam upvotes. In a decentralized world, how does anyone tell the difference?
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:
permalinks: https://verdverm.com/blog/permalinks-and-editing-on-whitewin...
editing: https://verdverm.com/blog/adding-record-editing-with-history...
> How are things like upvotes tracked?
You crawl the network to look for pointers and do something like: https://jazco.dev/2024/04/20/roaring-bitmaps/
> And how is moderation/spam even handled?
It's way cooler than any other system out there: https://bsky.social/about/blog/03-12-2024-stackable-moderati...
People are talking of turning both labelers and feedgens into DAGs (i.e. how do we combine each and use set operations to make interesting combinations)
> can fake their own data
Fake can be seen subjectively here, if it's my data and I can put anything I want in there, what is fake about it?
If it's about changes, the CID hash is how we know if a record has been altered
I'm still left wondering how you prevent the problem of somebody creating hundreds of accounts to upvote all their own posts.
I see how the labelers work for content, but I don't see anything about user reputation. So I'm still struggling to understand what the protections are against bots? I'm struggling to understand how upvote/recommendation numbers can be trusted at all, when you want to see what's liked across the whole network and not just by your friends, but without it all being spam likes.
>> can fake their own data
> Fake can be seen subjectively here, if it's my data and I can put anything I want in there, what is fake about it?
So it seems like the hashes (cid) are a big help, thank you. Is there anything preventing you from backdating things? Making it look like you said something or posted a photo of something last month that you didn't actually until just now? Because that seems like the other big category of content faking.
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)
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
The record format should be something widely used and implemented for sending over the wire. There are lots of languages and ecosystems participating.
> The record format should be something widely used and implemented for sending over the wire.
I was mainly speaking more generally than atproto. Most APIs talk JSON these days
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?
Kye•4mo ago
rmccue•4mo ago
It’s kind of annoying that a huge number of DID methods are specific to cryptocurrencies and are practically abandoned.