[HN Gopher] Where it's at://
___________________________________________________________________
Where it's at://
Author : steveklabnik
Score : 379 points
Date : 2025-10-02 20:31 UTC (2 days ago)
(HTM) web link (overreacted.io)
(TXT) w3m dump (overreacted.io)
| Kye wrote:
| Finally, some love for for did:web.
| rmccue wrote:
| 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.
| indigodaddy wrote:
| 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..
| quotemstr wrote:
| I fail to see what problem this thing solves.
| robmccoll wrote:
| 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.
| danabramov wrote:
| 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.
| quotemstr wrote:
| 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.
| danabramov wrote:
| 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.
| quotemstr wrote:
| > 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?
| danabramov wrote:
| _> 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.
| quotemstr wrote:
| 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?
| danabramov wrote:
| 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.
| rmccue wrote:
| 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.
| quotemstr wrote:
| Ah, thanks. Might you consider going full DHT for name
| lookup then?
| rmccue wrote:
| 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!)
| beeflet wrote:
| 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?
| danabramov wrote:
| _> 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....
| verdverm wrote:
| > 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
| beeflet wrote:
| 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.
| verdverm wrote:
| 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
| beeflet wrote:
| 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
| verdverm wrote:
| I'm the goto person in my friends/family for things like
| this and not one has ever asked about being locked out of
| a google/apple account. I don't know anyone this has ever
| happened to, so when people say it's some widespread
| problem at top of mind, forgive me for being extremely
| skeptical. These stories tend to be told by people it has
| happened to and extended beyond the bounds they are
| actually a worry for most people.
| edoceo wrote:
| 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.
| doytch wrote:
| 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/
| card_zero wrote:
| > 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.
| beeflet wrote:
| Even if bob "owned" bob.com, that amounts to a row in
| some centralized database somewhere.
| card_zero wrote:
| 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.
| beeflet wrote:
| ICANN is relatively benign but not benign.
| danabramov wrote:
| 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.
| beeflet wrote:
| Did they invent the idea of a keypair?
| tolerance wrote:
| It's Web3 reanimated.
| danabramov wrote:
| I like to think of it as Web3, the good parts.
| skybrian wrote:
| 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.
| ape4 wrote:
| So the atmosphere is in the cloud
| sigfubar wrote:
| [flagged]
| danabramov wrote:
| 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
| beeflet wrote:
| 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.
| icy wrote:
| > 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.
| beeflet wrote:
| >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.
| danabramov wrote:
| _> 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.
| add-sub-mul-div wrote:
| [flagged]
| tomhow wrote:
| Please don't reply to a bad comment with another bad comment.
| HN is for curious conversation, not snark, even in response
| to snark from others.
| tomhow wrote:
| Please don't post snarky dismissals like this on HN. The
| guidelines ask us to avoid shallow dismissals and snark. Please
| make an effort to observe them when participating here.
|
| https://news.ycombinator.com/newsguidelines.html
| danabramov wrote:
| 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.
| Vinnl wrote:
| 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?
| danabramov wrote:
| 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.
| yapfrog wrote:
| 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?
| mozzius wrote:
| Yep, here: https://atproto.com/guides/account-migration
|
| There's also tools that can help automate this:
| https://pdsmoover.com/
| psnehanshu wrote:
| 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?
| danabramov wrote:
| I don't think it would follow redirects. See
| https://atproto.com/specs/handle#https-well-known-method
|
| _Edit: I 'm wrong; see below_
| psnehanshu wrote:
| It says "HTTP redirects (eg, 301, 302) are allowed, up to a
| reasonable number of redirect hops."
| danabramov wrote:
| Ah my bad, you're right! I glossed over that.
| gerdesj wrote:
| "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.
| danabramov wrote:
| 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: http
| s://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.
| baliex wrote:
| 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.
| danabramov wrote:
| 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"_.
| baliex wrote:
| 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
| danabramov wrote:
| I'm not quite sure I'm following what you're saying.
|
| 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?
| rmccue wrote:
| 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.
| mmbizzle wrote:
| What about when Bluesky goes out of business and plc.directory is
| shut down?
|
| This all seems unnecessarily fragile.
| mempko wrote:
| This is no different then how the web works. So not a great
| argument against this protocol.
| beeflet wrote:
| How does it improve over the existing system, other than
| slapping the word "decentralized" on?
| Vinnl wrote:
| 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.)
| danabramov wrote:
| I've also linked to
| https://updates.microcosm.blue/3lz7nwvh4zc2u and
| https://plc.wtf/ which are relevant. These are good questions
| to ask!
| xmprt wrote:
| What happens when the independent legal entity stops getting
| funding and has to shut down?
| edoceo wrote:
| Need a PLC+DHT thing maybe? Or maybe someone will try to
| blockchain?
| verdverm wrote:
| 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
| chuckadams wrote:
| 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.
| hyperhello wrote:
| "They'll figure out the physical server where its JSON is
| currently hosted, and show that JSON for you"
|
| So, DNS?
| danabramov wrote:
| A combination of DNS and HTTPS (as described further in the
| post).
| globalnode wrote:
| 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.
| danabramov wrote:
| 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.
| Oper_52 wrote:
| ATProto is even more overhyped than Rust. I'll stick to Twitter
| and Usenet, thanks.
| rmccue wrote:
| 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.)
| password4321 wrote:
| 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.
| rmccue wrote:
| "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.)
| supermatt wrote:
| > 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.
| danabramov wrote:
| 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)._
| rmccue wrote:
| 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.
| supermatt wrote:
| 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.
| Retr0id wrote:
| It can be handled by alternative resolvers, like
| https://plc.wtf
| supermatt wrote:
| Non-plc resolvers. This resolver you referenced is still
| using plc.directory upstream.
| verdverm wrote:
| > 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
| supermatt wrote:
| 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.
| verdverm wrote:
| 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
| supermatt wrote:
| 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.
| verdverm wrote:
| 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
| supermatt wrote:
| Thanks - I will join there and see if there's any way I
| can promote decentralisation as a core tenet.
| verdverm wrote:
| 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
| supermatt wrote:
| It seems like this comment is getting downvoted. For what
| exactly? If I am wrong about something then point it out.
| verdverm wrote:
| 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
| supermatt wrote:
| 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.
| verdverm wrote:
| > 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
| supermatt wrote:
| > 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.
| verdverm wrote:
| 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
| supermatt wrote:
| > 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.
| verdverm wrote:
| 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.
| supermatt wrote:
| 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.
| magicalhippo wrote:
| 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?
| danabramov wrote:
| 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.
| magicalhippo wrote:
| > "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.
| danabramov wrote:
| _> 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.
| thisismissem wrote:
| 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...
| magicalhippo wrote:
| 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.
| bnewbold wrote:
| (I added a reply up-thread here:
| https://news.ycombinator.com/item?id=45469667)
| thisismissem wrote:
| 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.
| thisismissem wrote:
| 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.
| captn3m0 wrote:
| Is there any reading material on the private-key recovery
| bits? I want to learn how AT manages failure scenarios,
| especially around key-loss.
| danabramov wrote:
| 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.
| bnewbold wrote:
| 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.
| stebalien wrote:
| 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?
| danabramov wrote:
| 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.
| rmccue wrote:
| 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.
| danabramov wrote:
| Ah yes, this might be relevant then:
| https://www.da.vidbuchanan.co.uk/blog/adversarial-pds-
| migrat...
| stebalien wrote:
| 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?
| rmccue wrote:
| 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.
| stebalien wrote:
| 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.
| danabramov wrote:
| 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.
| stebalien wrote:
| 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.
| danabramov wrote:
| 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.
| Spivak wrote:
| 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.
| drnick1 wrote:
| 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.
| danabramov wrote:
| 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
| drnick1 wrote:
| Thanks. It's quite shocking however that GPT did a better job
| at explaining this to me than the original article.
| danabramov wrote:
| 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.
| auggierose wrote:
| 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.
| drsanta wrote:
| The at protocol seems a little Nebraskan Church Excel doc
| complex: https://xkcd.com/1667/
| verdverm wrote:
| 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
| drnick1 wrote:
| I still don't understand how this project meaningfully addresses
| the problem of identity and data ownership.
|
| When it come to identities, either you have your own domain, or
| you use someone else's domain (say, Bluesky). Most people don't
| have domains, and so their identity will be owned by a third
| party.
|
| You also have the same problem when it comes to the data itself.
| The moment Bluesky or some other server bans you, your repo is
| shut down and you lose the ability to move the data somewhere
| else.
|
| In short, this is exactly like email. Unless you have your own
| domain and server you don't control anything.
| password4321 wrote:
| At least with email you can own a PGP/SMIME key and take it
| elsewhere, right? Isn't this something similar with ATproto?
| danabramov wrote:
| 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.)
| athrowaway3z wrote:
| I'm not a user, but I do think there is a need for these type
| of schemes.
|
| Approximately 0% of email users could change email host, and
| prove their identity between the old messages and the new
| messages.
|
| The value is it caps bluesky's "window of abuse".
|
| Platforms like Facebook or Twitter have dialed up the
| enshitification far beyond what I find acceptable, but many
| people are still on there.
|
| A competitor to bluesky can decide how to approach it. Like
| staying (partially) compatible, and decide to compete on UI,
| repo storage, or user admin.
| solatic wrote:
| > Most people don't have domains, and so their identity will be
| owned by a third party.
|
| Indeed, and as a result, such users will always be vulnerable
| to specific risks like sudden bans, i.e. when the hosting
| service becomes adversarial. The only full protection is to own
| your own domain off a neutral TLD, with protocols that use DNS
| to describe how traffic should be routed.
|
| _But_ , because most users don't have domains (as you pointed
| out), the state-of-the-art can still be improved upon with
| _partial_ flexibility and protections, when the hosting service
| is cooperative. This project allows people to keep their
| Bluesky handle (because they don 't own a domain) while
| (hypothetically) moving their data hosting to a different
| provider, unlike current Big Social where your data is stuck on
| Facebook/X/Instagram/TikTok/YouTube forever. Bluesky has an
| interest in this because it also allows people to set up their
| own handle and move their hosting to Bluesky.
|
| Sometimes we improve upon the existing state of the art not by
| delivering perfect solutions, but by delivering improvements
| upon limitations that we accept as a given (like the fact that
| most users will not set up their own domains).
| braebo wrote:
| Nobody owns their domain -- it still bugs me that we just
| lease them on yearly renewals by the good grace of the
| anointed registrars who may, at the will of governments or
| through sheer negligence, relieve us of such "ownership".
| danabramov wrote:
| 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.
| vollbrecht wrote:
| 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.
| danabramov wrote:
| 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.
| Kye wrote:
| 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
| danabramov wrote:
| Yes, that's why did-based links are better for web
| permalinks. But that's not different from usernames being
| recycled on other social sites.
| kevinak wrote:
| Isn't the solution to the identity problem of domains just to
| use public/private key pairs like Nostr does?
| aidenn0 wrote:
| 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.
| astrobe_ wrote:
| Owning a private key is the best way to prove your identity. As
| for hosting, I think BitTorrent is the most rock-solid? So
| maybe store your content in a Git repo, sign your commits, and
| publish on Torrent. And NNTP or RSS to notify users/followers
| of updates? Problems though are discoverability and passivity
| (e.g. no user comments from blogs etc.).
| danabramov wrote:
| That's more or less how AT works, minus the Torrent part.
| There's a private key you own (which is normally held on your
| hosting but you can also add a "higher priority" key that
| would override that one if your relationship with your
| hosting sours). The updates are broadcasted by WebSockets but
| you can think of it similar to RSS. The repo is MST but
| that's not too far from Git. The commits are signed. The
| publishing is done on traditional web though.
| danabramov wrote:
| 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.
| Denvercoder9 wrote:
| > In AT, data is tied to identity (DID), not handles or
| hosting.
|
| But there's exactly two types of identity, one of which
| requires you to have a domain (did:web:), and the other
| relies on a centralized registry owned by a third party
| (did:plc:). Still the exact same problem.
| danabramov wrote:
| See https://news.ycombinator.com/item?id=45472568
| BrandoElFollito wrote:
| > you have your own domain
|
| Until you don't. As opposed to a server you host (together with
| its data), for domains you are at the mercy of the registrar.
|
| This was one (tiny, to be honest) of the considerations I had
| when choosing a registrar in my country, we are under one
| legislation, so my hope is a bit higher to recover it if
| needed.
| extraduder_ire wrote:
| For comparison, how does mastodon or activitypub in general
| deal with losing a domain name? It's included in every user's
| handle.
|
| I heard about that happening with a popular server under .af,
| but didn't see a follow up.
| teddyh wrote:
| 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.
| danabramov wrote:
| 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.
| AtlasBarfed wrote:
| 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?
| angerson wrote:
| 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
| Tomuus wrote:
| 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...
| danabramov wrote:
| 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....
| verdverm wrote:
| > 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
| thrown-0825-1 wrote:
| Reminds me of the various crypto protocols talking about
| theoretical decentralization while entirely bound to 1 platform
| with no other useful apps in sight.
| stevage wrote:
| Much like Git and GitHub (at least for many years, it's
| improved a little bit now).
| porridgeraisin wrote:
| I don't see how. Many large projects have been running with
| git patches over emails for decades.
| jonhohle wrote:
| 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.
| stevage wrote:
| 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?).
| thrown-0825-1 wrote:
| 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.
| BirAdam wrote:
| I've used Gitea at two companies. One had it on-prem the
| other in a VPS.
| thrown-0825-1 wrote:
| 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.
| danabramov wrote:
| 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.
| thrown-0825-1 wrote:
| 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.
| rmoriz wrote:
| 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.
| zoul wrote:
| In what way is Mastodon a failed experiment? Low number of
| active users or something else?
| numpad0 wrote:
| 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.
| verdverm wrote:
| > 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.
| jiehong wrote:
| Performance worries me when reading that.
|
| Even with having a cache as explained.
| danabramov wrote:
| 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.
| verdverm wrote:
| 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
| 1718627440 wrote:
| Why do they use forward names for the username, but backward
| names for the server? That's inconsistent.
| danabramov wrote:
| 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.
| 1718627440 wrote:
| 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.
| danabramov wrote:
| Can you clarify what the proposed change is? I don't quite
| follow. For example, what does `at://did:plc:fpruhuo22xkm5o7ttr
| 2ktxdo/sh.tangled.feed.star/3m23ddgjpgn22` become ?
| 1718627440 wrote:
| https://did:plc:fpruhuo22xkm5o7ttr2ktxdo@/sh.tangled.feed.sta
| r/3m23ddgjpgn22
|
| which then resolves to:
| https://did:plc:fpruhuo22xkm5o7ttr2ktxdo@morel.us-
| east.host.bsky.network/sh.tangled.feed.star/3m23ddgjpgn22
|
| There might be conflicts there with a specification of
| passwords, so you need to use another separator than :.
| danabramov wrote:
| That's not a valid HTTPs URL though, is it? Since there's
| no specific location to hit. Maybe I'm missing something.
| 1718627440 wrote:
| Then i did not understand the article, I thought
| morel.us-east.host.bsky.network was the specific location
| after resolving the DID.
| danabramov wrote:
| No, I mean that ` https://did:plc:fpruhuo22xkm5o7ttr2ktxd
| o@/sh.tangled.feed.star/3m23ddgjpgn22 ` (that's your
| proposal?) isn't a valid URI for https:// scheme. The
| need for the new scheme comes from being unable to
| express an identity-rooted URI in other schemes.
| verdverm wrote:
| 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
| akk0 wrote:
| 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...
| rcxdude wrote:
| 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.
| akk0 wrote:
| 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"...
| downsplat wrote:
| > 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.
| danabramov wrote:
| 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/p
| rofile/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.
| crowbahr wrote:
| An I crazy out does that feed have nothing on it besides a
| request to favorite the feed?
| lonk11 wrote:
| 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.
| dorianmariecom wrote:
| not as good as twitter
| arccy wrote:
| I think it's more a function of who you follow...
| wildpeaks wrote:
| 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.
| ktosobcy wrote:
| 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
| sph wrote:
| 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.
| rco8786 wrote:
| That's basically every social platform in my experience.
| reaperducer wrote:
| _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?
| teddy-smith wrote:
| Twitters the same just in reverse
| furyofantares wrote:
| 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.
| akk0 wrote:
| 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.
| didibus wrote:
| In theory, you can build your own ranking algorithm because the
| protocol is open.
|
| See: https://github.com/bluesky-social/feed-generator
| madeofpalk wrote:
| And see feeds that others have built
| https://blueskydirectory.com/feeds/all
| daveguy wrote:
| 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.
| rchaud wrote:
| 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.
| wredcoll wrote:
| Wow, sounds really awful, you selected art and got posts
| about art.
| bowsamic wrote:
| Not all art is slop
| wredcoll wrote:
| Lacking any useful deities to give us an objective
| definition of art, we're going to have to go with the
| majority opinion here: pictures people create with their
| hands and brain are art.
| verdverm wrote:
| Get into custom feeds, game changer.
|
| I use https://graze.social
| internet2000 wrote:
| It's a thing specially on that website. This post explains it:
| https://www.natesilver.net/p/what-is-blueskyism
| paride5745 wrote:
| 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.
| bowsamic wrote:
| I had the same but it wasn't even edgy like on X, really just
| sad twee millennial American politics commentary
| ulrischa wrote:
| 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.
| danabramov wrote:
| 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.
| brap wrote:
| >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.
| redleader55 wrote:
| But you can use did:web:fqdn if you want; it's explained in the
| article.
| tempodox wrote:
| > 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.
| danabramov wrote:
| 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.
| James_K wrote:
| I've never really gotten AT protocol. It just seems like
| reinventing 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.
| danabramov wrote:
| 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.
| losvedir wrote:
| 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.
| verdverm wrote:
| > 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
| crazygringo wrote:
| 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.
| reactordev wrote:
| 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.
| crazygringo wrote:
| > _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?
| verdverm wrote:
| > 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
| verdverm wrote:
| > 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
| crazygringo wrote:
| 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.
| verdverm wrote:
| 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)
| onetom wrote:
| 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
| verdverm wrote:
| 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.
| rixed wrote:
| > The record format should be something widely used and
| implemented for sending over the wire.
|
| That's just one of the parameters. It should also be
| something efficient if it's going to be sent over the wire at
| scale.
| verdverm wrote:
| 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)
| danabramov wrote:
| Note that it's CBOR being sent over WebSockets (afaik).
| rixed wrote:
| 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?
___________________________________________________________________
(page generated 2025-10-04 23:01 UTC)