[HN Gopher] ATProto and the ownership of identity
___________________________________________________________________
ATProto and the ownership of identity
Author : icy
Score : 70 points
Date : 2025-01-18 13:15 UTC (9 hours ago)
(HTM) web link (anirudh.fi)
(TXT) w3m dump (anirudh.fi)
| bryanrasmussen wrote:
| sounds like XRI and XDI and all the associated layers of
| standards that never went anywhere but produced a lot of
| architectural spacefaring https://www.oasis-
| open.org/committees/xdi/charter.php
|
| on edit: some things just bring out my cynical side.
| oDot wrote:
| Is ATProto fully implementable by third parties? I last read
| there were still closed source parts
| verdverm wrote:
| Generally, the core components are open source. There are a few
| things like private DMs and mutes that do not get saved to your
| PDS, but are accessible with an authenticated client. The open
| source PDS implementation is still beta auiu. There is a limit
| of 10 accounts per server while it gets tested in the wild,
| last I saw
|
| One thing to consider is that you do not have to reimplement
| the entire spec if you are only interested in building a feed
| or recommendation system. ATproto makes the core components
| plug-n-play, so users can use the Bluesky app while picking 3rd
| party providers for moderation and algo feeds
|
| There is also an independent group with their own governance
| working to define a number of common lexicons for shared usage
| across applications
|
| https://github.com/lexicon-community/lexicon
| xeonmc wrote:
| Is it possible to implement a functional subset of just
| serving one's own DID identities using serverless functions?
| Then that would enable every average Joe to make their own
| with Cloudflare Pages Workers
| verdverm wrote:
| You shouldn't need that much for a single DID. If you want
| to serve an org DID, like a bunch of users under the same
| domain, you need to do something like this.
|
| https://atproto.com/guides/identity
| xeonmc wrote:
| where are you supposed to put the DID document on your
| domain? All documentation describes putting the .well-
| known/atproto-did file but not the actual DID document.
| verdverm wrote:
| From https://atproto.com/specs/handle section "HTTPS
| well-known Method"
|
| It is unclear where the handle query goes
|
| However, you don't need a document per day. It can be
| dynamically generated by a handler or server less
| function on that route. This is important as employees at
| an org change, this information could be obtained from a
| database
|
| You can for example: `curl
| https://verdverm.bsky.social/.well-known/atproto-did`
|
| So for an organization, one might have a single handler
| responding to `*.atproto.company.com/.well-known/atproto-
| did` with the subdomain becoming the primary input
| variable
| xeonmc wrote:
| no, like I said I already know that .well-known/atproto-
| did returns the DID value, but there doesn't seem to be
| any documentation for where the inquirer will next expect
| to fetch the actual DID document to complete the circular
| verification.
| verdverm wrote:
| This peer-thread might offer us some clues:
| https://news.ycombinator.com/item?id=42750241
|
| `curl -s "https://plc.directory/$(curl -s
| https://verdverm.bsky.social/.well-known/atproto-did)" |
| jq .`
| verdverm wrote:
| This concept of multiple applications and companies sharing the
| same social graph is what makes ATProto and the adoption
| exciting. ATProto brings real competition to social media and
| removes the switching cost for users. As OAuth matures, it will
| become even easier, and that the money is now interested adds
| another point of legitimacy.
| xeonmc wrote:
| And I hope alternative lexicon for chat apps built atop ATproto
| will be able to challenge Discord by leveraging the network
| effect of transferable identities.
| verdverm wrote:
| 100%, the main challenge will be privacy and e2e encryption.
| There is prior art we can draw on.
|
| Similar if we want something akin to FB groups with private
| membership, events, and content
| shrink wrote:
| I like the domain name identity model used by AT (so much so I
| built handles.net[1] for managing domain name based handles) but
| during my time reading opinions on Bluesky it has become apparent
| there's a lot more confusion about and distrust towards domain
| names amongst non-technical people than I previously thought.
|
| I thought that people generally understood that domain names are
| owned and that their provenance can be independently verified
| (which is why they're valuable for identity) but there's a fairly
| large and vocal contingent of Bluesky users that are _frustrated_
| by domain names, so much so there are multiple efforts to
| establish a private verification system on Bluesky like
| verified.quest[2].
|
| A lot of people do not want to look at and understand domain
| names, instead they want to see a name and a check mark. They
| want a central authority to tell them who is trustworthy and who
| is not. Domain names are a great solution for technology-adjacent
| people and I hope that they become more widely accepted, but I'm
| not too optimistic.
|
| I am optimistic and hopeful that AT has a bright future ahead of
| it. I think AT has a lot going for it... but I do not think that
| identity will be a part of that. I suspect many apps built on AT
| will not bother with handles and will just use local display
| names.
|
| [1] https://handles.net [2] https://verified.quest
| verdverm wrote:
| There is an amount of legitimacy to the domain issue, at least
| to me if one considers how certain phishing attempts leverage
| human (lack of) observation patterns. Like if someone had a
| bunch of identities under goog1e.com
|
| I see having independent, from Bluesky, and multiple methods of
| verification as a strength of the network and architecture.
| spencerflem wrote:
| for sure- or for someone less famous than one of the hundred
| domains we all memorize - is philjamesson.com or
| pjamesson.com or philjamessoncomedy.com or philjamesson.net
| the real one etc.
| xp84 wrote:
| Yeah. One of the most pervasive problems I'd argue of the
| "web" era is the conflicting needs for canonicalism (e.g. I
| want to know when I see a "Jack Nicholson" account that
| it's _that_ Jack Nicholson) with the fact that very few
| people have unique names or other obvious identifiers. And
| half of companies don't either (e.g. the Beatles' record
| label Apple Corps vs Apple, Inc. -- which owns Apple.co.uk?
| Whoever grabbed it first, of course!)
|
| Every service with handles is just another microcosm of the
| DNS system's same problem, just usually with even fewer
| affordances for disambiguating (the DNS's country codes and
| things like .org vs .com offer a single crude sorting
| system, but we've seen it solve very little since the move
| is to "buy 'em all" if you're big, witness how WWF the
| charity couldn't peaceably coexist with WWF, now WWE just
| by using .org and .com)
| ryan29 wrote:
| I think that once you have domains as an identity, you can
| solve a lot of problems with the idea of 'just add money'. If
| $1000 gets me a gold check mark, it changes the economics of
| impersonation. Is it worth it to spend $1000 to get a gold
| check mark on 'goog1e.com' if a brand monitoring system is
| going to get that moderated out of existence in a couple of
| hours?
|
| That's also why domain verification systems need to have
| continuous re-validation with more frequent re-validation for
| new identities. For example, if '@goog1e.com' is a new
| identity, it should be re-validated after 1h, 4h, 8h, 16h (up
| to a maximum). Additionally, you could let other validated
| users with aged accounts trigger a re-validation (with shared
| rate limits for a target domain).
|
| The great thing about domains is that those of us that are
| good faith participants can build a ton of value on them and
| that value can be used as a signal for trustworthiness. The
| hard part is conveying that value to regular users in a way
| that's simple to understand.
|
| We could also have systems that use some type of collateral
| attestation. For example, if I donate $1000 to the EFF, maybe
| I could attribute that donation to my domain 'example.com'
| and the EFF could attest to the fact that I've spent $1000 in
| the name of 'example.com'.
|
| You probably have to gate that though some type of authority,
| but I can imagine a system where domain registrars could do
| that. I would love to buy reputation from my registrar by
| donating money to charity.
| immibis wrote:
| In the latter case, if you _are_ the EFF, or any other
| recognized charity (and if you allow a lot of charities
| that 's a lot of people) you can assign a trillion dollars
| to any domain you like, which is usually cited as a reason
| to avoid this type of system.
|
| And if the EFF turns bad in the future you can't get a
| verification badge without supporting bad guys.
| derektank wrote:
| I don't even think it's the technical barriers per se that
| makes people distrust domain names as a form of verification. I
| think the idea of competing sources of truth creates some
| uncomfortable cognitive dissonance for a large number of people
| which drives the demand you identified for a central authority.
| lxgr wrote:
| But domains could be that central authority, in a way that
| regular "verified names" can't be.
|
| With social media handles, it's the eternal game of finding
| something that's available everywhere, or doing the awkward
| dance of "i'm @foo (except for platforms B and C, where i'm
| @_foo)".
|
| I wonder if there is a future for a service mapping domains
| to human-interpretable names, though?
| verdverm wrote:
| Both domain and non-domain, or 3rd party, based verifiers
| have a trust relationship, which can be undermined by
| breaking the expectations. Musk Social certainly did this
| when they made it pay-to-play and removed the blue check on
| well known accounts the overlord became displeased with.
|
| ATProto specifically advises against shortening domains
| into some "human readable" format. For example,
| @foo.bar.com and @foo.baz.com could easily look the same.
| The full path is unique. What Bluesky provides is a
| "display name" in addition to your handle. Multiple people
| can have the same display name, but it always appears next
| to the full handle
|
| https://atproto.com/specs/handle#usage-and-implementation-
| gu...
| ryan29 wrote:
| The platform owners have spent two decades de-emphasizing
| domains, so it's not too surprising that most people struggle
| to understand how they work. I think that can change with
| education and awareness if domains as identity start to catch
| on. It just takes time.
|
| For now, I think wider adoption of things like DomainConnect
| [1] would make a difference. It works really well to set up an
| MS365 account with DNS hosted at Cloudflare, but it would need
| a workflow that supports sending requests to your DNS admin
| rather than assuming everyone is a DNS admin.
|
| > A lot of people do not want to look at and understand domain
| names, instead they want to see a name and a check mark. They
| want a central authority to tell them who is trustworthy and
| who is not.
|
| I think 'trustworthy' is a key word there and would add that I
| think a lot of regular people conflate identity verification
| with moderation. It's important to keep those separate because
| as soon as an identity system becomes a moderation system, it's
| worthless.
|
| That's what makes domains so great for identity, especially
| with the way the AT protocol works. It helps to create a clear
| separation between identity verification and moderation.
| Moderation is much harder than identity verification, so having
| a clear line between the two should make it easier to develop
| technical systems that perform identity verification.
|
| For pure identity verification, I think BIMI [2] is sitting on
| a solution they don't even realize they have. They're too
| tunnel visioned on email verification, but the system they've
| built with VMC (verified mark certificates) works as a
| decentralized system of logo verification. For example, I can
| tell you this logo [3] is trademarked and owned by 'cnn.com'
| and I can do it via technical means starting with the domain
| name: dig default._bimi.cnn.com TXT
|
| Seeing a 3rd party URL in the TXT value makes me think the
| implementation is weak since that would be better as a CNAME
| pointing to a TXT record managed by a 3rd party, but I've never
| looked into the details enough to know if it'll follow CNAMEs
| (like ACME or DKIM do).
|
| Also, the VMCs are only good for high value brands because CNN
| is paying DigiCert $1600 / year for the certificate, but, since
| it's just PKI, it allows anyone to put up that logo with a
| verified badge on the @cnn.com identity. A more accurate badge
| would be the registered trademark symbol [4].
|
| Even though that only works for high value brands that own a
| logomark, it works extremely well and would be a great start to
| a system that's easier for the average person to understand
| because logos are a simpler concept than something abstract
| like domains and no one is spending the time and effort needed
| to get a fake VMC (if it's even possible).
|
| The Bluesky implementation for domain verification has a long
| way to go though. It's very naive at the moment and doesn't
| even do a proper job of dealing with changes in domain
| ownership. In fact, almost everyone doing domain validation is
| doing it wrong because very few implementation do re-validation
| from what I've seen.
|
| 1. https://www.domainconnect.org/
|
| 2. https://bimigroup.org/
|
| 3. https://amplify.valimail.com/bimi/time-warner/I0vDrJpkRnB-
| ca...
|
| 4. https://en.wikipedia.org/wiki/Registered_trademark_symbol
| comex wrote:
| > instead they want to see a name and a check mark
|
| How is that remotely surprising?
|
| Most famous people are not known by domain names. Most are
| known by their real names. Some are known by usernames on
| particular services, like MrBeast on YouTube or dril on
| Twitter.
|
| Maybe, if Bluesky stays popular, a new crop of Internet-famous
| people will be known by their domain names. But even then,
| you're probably not going to remember whether they're foo.com
| or foo.io or foo.bsky.social.
|
| Some people, mostly in tech, do have well-known personal
| websites hosted at their own domains - but I for one rarely
| remember the specific domains, because I'm used to finding
| websites through search. (Off the top of my head I can only
| think of cr.yp.to.)
|
| Companies are more likely to have websites and well-known
| domains, so there's that, but most social media users are
| individuals.
|
| Besides, domain names are not more owned than Twitter handles
| or any other kind of username. If anything, they're less owned.
| When Elon Musk stole some people's Twitter handles, it was
| (tech) news. The expectation with most services is that you can
| register a name and hold onto it forever for free; at worst it
| might be lost if you're totally inactive for a long time.
| Meanwhile, domains require yearly payment. Once they expire,
| they're often instantly snapped up by a bot with no way for the
| original owner to get them back.
|
| So in practice, people lose their personal domains all the
| time. Less common for companies, but companies _do_ tend to let
| their names expire when they go out of business. Just the other
| day there was a front-page post about using this to hijack
| people 's identities. [1]
|
| Domain names can also be taken away for trademark infringement
| (UDRP) or by a court for other legal reasons (e.g. pirate sites
| often have their domains seized). Domains can be lost for
| political reasons, as with .af domains suspended last year [2]
| following the change of government in Afghanistan (originally
| thought to be caused by the message expressed by the names, in
| reality caused by payment issues resulting from economic
| sanctions, but either way happening for political reasons). You
| even have situations like .io where millions of domains might
| disappear in one stroke (though it probably won't actually
| happen).
|
| [1] https://trufflesecurity.com/blog/millions-at-risk-due-to-
| goo...
|
| [2] https://www.reuters.com/technology/brokeaf-goes-offline-
| afgh...
| jazzyjackson wrote:
| someone should just buy bsky.nyc and sell subdomains for people
| that have Real IDs with a NYC address, then my handle could be
| @jazzyjackson.bsky.nyc and anyone who knows about the system
| then could trust I'm using my government name and that I'm not
| a russian bot.
|
| But yeah I was disappointed with the lack of adoption there.
| The CEO of the onion is a prolific poster and has to deal with
| scambots but can't be bothered to use onion.com in his handle
| immibis wrote:
| But I don't _want_ random bluesky users to know my government
| name.
| PaulHoule wrote:
| (Feeling a little agitated today)
|
| I suspect the average person believes "paying for services" =
| "slavery" and "free as in beer" = "freedom" and would, if
| pressed, would rather give their life than change that belief.
| Almondsetat wrote:
| If the fediverse's structure is like email, what's atproto's
| structure?
| input_sh wrote:
| By default: @user.bsky.social
|
| If you verify your domain: @yourdomain.tld
| davexunit wrote:
| Gmail.
| jchw wrote:
| To be honest, I hope that the Fediverse can be expanded to
| support W3C DID for identities. It's challenging to pick a set of
| tradeoffs that make the most sense for this sort of thing, but
| other than that I don't think it's impossible.
|
| For example, if you just wanted DIDs for verification, I reckon
| you could go the route of having DIDs be represented as
| [DID]@[ActivityPub service domain] and treat each ActivityPub
| service as a different type of PDS.
|
| I don't think AT Proto/Bluesky will wind up killing the
| Fediverse, at least not any time soon, so I think it would make
| sense to try to figure out ways to take some of the more
| interesting applicable ideas and try to figure out how they could
| work.
| lxgr wrote:
| > I don't think AT Proto/Bluesky will wind up killing the
| Fediverse
|
| I think it might just, if the Fediverse can't find a way to
| detach identities from instances/servers.
|
| It's baffling to me how people have been flocking away from
| Twitter, to at least some extent because they are unhappy about
| how the new owner runs things, to a system that gives _exactly
| the same power_ to the people running each individual instance.
| solarkraft wrote:
| I used to dismiss this argument entirely because you're free
| to choose who gets these power's through your choice of
| instance! But I do realize that it's important to be able to
| change your mind. Currently this means having to create a new
| identity, which does suck.
| jchw wrote:
| Although it sucks, I think the reason why it won't kill the
| Fediverse is because there is a large part of the Fediverse
| that is not really an alternative to what Twitter was or
| is, and is not really being competed on by Bluesky. These
| are smaller websites and smaller communities, at least in
| scope if not also members. They may be more or less strict,
| but either way they will have more thorough (and specific)
| moderation in general.
|
| That said, I also expect that some people will remain on
| Mastodon.social using it basically as a Twitter
| alternative, too, for the same reason that some people will
| basically never leave Twitter either, until it goes
| offline.
| immibis wrote:
| Well, you have the power to not use a bad instance, which you
| don't have on Twitter.
|
| Or on Bluesky.
|
| If your instance isn't bad but you want to move, there's a
| migration mechanism. And nobody is stopping you from having
| multiple accounts. The whole internet used to work that way,
| where you'd have a separate account for every niche-topic
| forum.
| dom96 wrote:
| I've dived head first into Bluesky and AT Proto in the last 2
| months. The platform is amazing and I was able to grow an app
| from 0 to 30k users in that time[1].
|
| I have also been long pondering what puts me off social media and
| how I could fix it. Often times it is the ease by which anyone
| can create new anonymous accounts, those accounts can be used to
| easily brew up a Firestorm of Falsehood[2]. Identity is a strong
| part of this and domain name verification isn't enough to solve
| this.
|
| One potentially radical idea I've had is to form a social network
| of verified humans. Where each human is only allowed a single
| account. This is possible, while remaining anonymous to other
| users. I think the only way in which this can be done is by
| relying on passport (and other government IDs) verification. I
| have actually built a prototype of this (still very much a
| WIP)[3]. Of course, the barrier to entry is tough, if anyone has
| thoughts/concerns and suggestions on how I can make this happen
| I'd love to hear them.
|
| Edit: To those downvoting I'd love to hear why, please :)
|
| 1 - https://listifications.app
|
| 2 - https://en.wikipedia.org/wiki/Firehose_of_falsehood
|
| 3 - https://onlyhumanhub.com
| lxgr wrote:
| How do you verify identity in that prototype? (Not providing my
| data to a signup form before I know at least the rough idea.)
|
| > I think the only way in which this can be done is by relying
| on passport (and other government IDs) verification.
|
| Given that most national IDs currently can't anonymously
| certify personhood to third parties, this seems like it puts
| unreasonable trust into the "identity broker" preserving both
| anonymity and not certifying sockpuppets. I don't see a
| scenario in which any even moderately successful solution would
| not eventually crumble under these two types of pressure.
| dom96 wrote:
| > How do you verify identity in that prototype?
|
| By using a third party service to read your passport's NFC
| chip, we then generate a strong crypto hash of the
| concatenation of your name, DoB, and last 4 digits of your
| passport and we also encrypt that hash for good measure.
|
| I agree that it sounds invasive, but there is no better way
| to verify uniqueness of a passport (and by proxy a human's
| uniqueness).
|
| And yes, I am aware that a single human can have more than
| one passport. It's certainly not perfect. But it reduces the
| possibility of sock puppet accounts significantly.
|
| If you register (just with your email and password), you'll
| get a little explanation of all the data collected (and don't
| have to move forward if you don't want to).
|
| > this seems like it puts unreasonable trust into the
| "identity broker" preserving both anonymity and not
| certifying sockpuppets
|
| True, but with enough resources onlyhumanhub itself can
| become the identity broker, no need for a third party.
| lxgr wrote:
| Newer passports intentionally don't support third-party
| verifiable signatures anymore (earlier ones did). Non-
| repudiation was always a bug, not a feature, and that
| functionality is going away in newer implementations due to
| privacy concerns [1].
|
| So unfortunately it's back to a centrally trusted verifier
| even with chip-enabled passwords for this use case.
|
| > True, but with enough resources onlyhumanhub itself can
| become the identity broker, no need for a third party.
|
| That doesn't address my concern at all: Why should I trust
| that service with something as sensitive as the mapping of
| my real identity to any number of pseudonyms? What's the
| economic incentive to not eventually offer a de-
| anonymization service to the highest bidder?
|
| [1] https://crypto.stackexchange.com/questions/75058/using-
| epass...
| immibis wrote:
| Government intelligence agencies, which can print passports
| at will, will be able to create millions of fake accounts,
| while the rest of us will be limited to just one. It's a
| similar problem to the money-given-to-charity idea: when
| you trust any actor to enforce identity, you're trusting
| them to enforce identity.
| mglikesbikes wrote:
| I handled the "real human" problem by charging access to the
| platform (and doing something socially responsible with the
| profits). Saw recently that X is starting to do this for
| signups, which feels icky (and likely explains why my idea
| didn't take off).
| dom96 wrote:
| X has been doing this and it didn't seem particularly
| effective. There are still many bots on the platform.
|
| Also, someone with a lot of money can still get around this
| requirement.
|
| Bribing a government to get fake passports is possible, but
| many orders of magnitude more difficult.
| jazzyjackson wrote:
| Bribing hotel clerks to make a new account every time a
| guest checks in and hands their passport over might be
| easier since in this case you just need to scan once to
| register. Maybe that sounds impractical and low volume but
| imagine you own a chain of hotels across thailand or
| whatever, you could probably make thousands of accounts a
| day and just sell that as a service.
| jazzyjackson wrote:
| It's really not a convincing pitch to me. It just raises the
| cost of bots to whatever I have to bribe a poor person to let
| me scan their documents, and it doesn't do anything to prevent
| me from putting an LLM in charge of my posts.
|
| Maybe you could require biometric login, something that
| requires a Google, Apple, or Yubikey issued secure enclave that
| authenticates on physical touch / face ID, and require that
| touch for every post.
|
| For me as a person participating in online communities, I'd
| rather just stay in my private group chats where I have met the
| people I'm interacting with.
| apitman wrote:
| > Ownership of identity
|
| This isn't currently a reality with ATProto, though they're
| making important progress over the status quo.
|
| Your identity in atproto is your DID. Your domain (if you use
| one) is just a handle. Currently all DID resolution goes through
| https://plc.directory, which is completely controlled by Bluesky.
| Their plan is to eventually have this run more like the DNS by
| something like a nonprofit, but AFAIK that process hasn't
| started.
|
| The question is if Bluesky turned completely evil today, what
| recourse would users and app developers have?
|
| All the other apps could form a coop for a new DID directory and
| switch their users over. That might work, but I would like to see
| something like this in place running alongside Bluesky's
| directory since the logistics of running such a thing are not
| obvious.
|
| Also, it's not entirely clear to me that running an alternative
| pseudo-DNS is really better than just using DNS like the
| fediverse does.
|
| One really nice thing about it is that DIDs are opaque values, so
| squatting should essentially go away. And there's not really any
| good reason for DIDs to expire like domains do. This is nice for
| account recovert, since in the worst case if you couldn't prove
| your identity to the DID registrar your account would just go
| stale, rather than potentially being taken over by a bad
| actor[0].
|
| [0]: https://news.ycombinator.com/item?id=42699099
| Retr0id wrote:
| > Currently all DID resolution goes through
| https://plc.directory
|
| _almost_ all. You can use did:web if you want to be more
| independent (but since 99.99% of people don 't it's almost
| completely irrelevant in the big picture).
|
| > The question is if Bluesky turned completely evil today, what
| recourse would users and app developers have?
|
| With sufficient developer consensus, we could all agree to
| switch to "plc2.directory". It'd be a shitshow, but hopefully
| not completely fatal.
|
| > One really nice thing about it is that DIDs are opaque
| values, so squatting should essentially go away
|
| Zooko's triangle strikes again!
| https://en.wikipedia.org/wiki/Zooko%27s_triangle (often
| expressed as a problem, but in this context it's mostly an
| advantage)
| xeonmc wrote:
| do you know how did:web works? Documentation only describes
| that .well-known/atproto-did should be the DID value, but no
| instruction at all on where the DID document should be.
| evbogue wrote:
| you put an identifier on a dns txt record and then
| Bluesky's directory checks to make sure the identifier is
| there.
|
| I'm not sure there is documentation on how to do this
| yourself though, if that was what you are asking.
| xeonmc wrote:
| no, that's just the identifier, I'm talking about the
| json document itself.
| evbogue wrote:
| Oh! I misunderstood the question.
|
| Navigating to my profile here:
| https://pdsls.dev/at/did:plc:i3gjwozl32eq3j3ejyw44hh4
|
| I clicked a link and my DID document is stored here:
| https://plc.directory/did:plc:i3gjwozl32eq3j3ejyw44hh4
|
| Not sure how you'd store it in other places, though
| that'd be pretty decentralized if you could.
| Retr0id wrote:
| It's documented here: https://w3c-ccg.github.io/did-method-
| web/
|
| For example, here's `did:web:retr0.id` :
| https://retr0.id/.well-known/did.json
|
| (.well-known/atproto-did is for handle resolution, not
| did:web)
| evbogue wrote:
| Exactly. The DIDs are held by Bluesky's directory, and they
| point to your latest signing key, which is also most often held
| by Bluesky. DID:Web is a one-time authentication process where
| Bluesky's directory checks to see if you have a DNS txt record
| and from then on you are known by your domain name and no
| longer have access to the bsky.app subdomain name that you
| initially start with.
|
| You can't see most of this information in the Bluesky app, so I
| find it helpful to use this other program to look up my
| information:
| https://pdsls.dev/at/did:plc:i3gjwozl32eq3j3ejyw44hh4
|
| For those of you who have time to listen to an hour podcast,
| pfrazee explains in depth how the Bluesky DID system works
| here: https://www.softwaresessions.com/episodes/atproto/
| bloopernova wrote:
| Cool, it's like a bit of KeyBase lives on. _(Note, I 'm not
| saying PLC derives directly from KeyBase! Just that the concept
| lives on!)_
|
| I really liked the idea of KeyBase. I found the idea of a
| cross-platform cross-system identity elegant.
| xrisk wrote:
| Caveat: You own your identity only as long as you use did:web,
| and did:web is not much different from webfinger, which is what
| activitypub uses.
|
| To clarify, the alternative (and default) is to use did:plc,
| which utilizes Bluesky (the company's) centralized identity
| server. It isn't possible to use other plc servers with any of
| the Bluesky clients either. Therefore, if you use did:plc it's
| simple to get kicked off of.
| icy wrote:
| Yeah, that's definitely a downside but there are plans to spin
| off did:plc into one that's managed by a neutral ICANN-like
| organization.
| rglullis wrote:
| I know I am comparing Bluesky's reality vs ActivityPub potential,
| but there are extensions that give identity and data portability
| to ActivityPub, all they need is to be adopted by the likes of
| Mastodon and PixelFed.
|
| Also, there is a whole spec for client-to-server ActivityPub
| which has been largely unexplored by developers and would allow
| end-users to be in full control of their whole experience (i.e,
| no "instance" between you and the rest of the social web.
| quantadev wrote:
| The problem with atproto is that it's rediculously complicated.
| Every detail in the spec done in the most difficult and stilted
| way possible.
|
| They could've made something much more like Nostr be at the core
| of it all, so that the barrier to entry is small for people
| wanting to write their own implementations, but the
| developers/designers of atproto put very little value in
| simplicity. They wanted everything to be as powerful as possible
| at every single layer, which means far too many levels of
| abstraction, super heavy-weight implementations, and stacks upon
| stacks of specs that are hard to unravel, etc.
|
| Anyone can learn Nostr in minutes. To learn atproto you need
| weeks.
| aintly wrote:
| It's not so bad. I managed to create a minimal implementation
| of a PDS for a Bluesky bot that can make simple text-based
| posts, and it only took a couple of days. Kind of lost interest
| in it after that but it was reasonably straightforward to
| iterate on. The trickiest bit was getting the subscribeRepos
| websocket to work, mostly because the documentation was
| unclear.
| quantadev wrote:
| Maybe so but I bet you 90% of the code you were running was
| already written because it was in a library right? So you
| didn't really have to understand it. You were just running
| someone elses code.
|
| With Nostr, for example (or even RSS), you can fully
| understand it from end to end, in minutes. As a former IPFS
| deloper myself I can assure you in just 2 days you didn't
| even understand the CAR format of a repo, unless you had
| prior experience.
| aintly wrote:
| ATProto is an interesting technology but the Bluesky app itself
| is seriously flawed as a Twitter/X competitor.
|
| Probably the worst feature is the "nuclear block" which allows a
| single user to completely disrupt a conversation: if one user
| blocks any other user in the thread, this removes the blocked
| user's replies for everyone else reading the thread, and severs
| the connection between posts so that even if you go directly to a
| post from the blocked user you can't see what post they were
| replying to or any of the rest of the thread above that.
|
| There are partial workarounds to this with third-party websites
| that attempt to piece together the thread from various other API
| calls, but these aren't perfect and it's annoying to have to do
| this to understand the context of a conversation full of blocked
| posts.
___________________________________________________________________
(page generated 2025-01-18 23:00 UTC)