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.
Are they really owned? I’ve always thought they’re [f]actually merely temporarily leased from a registry, and the ownership is just a legal fiction.
Unlike cryptographic keys, I don’t think domain names really pass the “can they be taken away without owner’s consent?” test. On paper maybe they should, but that’s certainly not how it is in reality.
Attaching digital identity to something that comes from a third party (a registry) rather than individual themselves is a fundamentally wrong idea.
It depends on the jurisdiction. In the EU, the European Court of Human Rights decided [0] that domains constitute a contractually acquired property or possession in the sense of article 17 of the EU Charter of Fundamental Rights [1]. So at least as long as you pay for the registration, your domain cannot easily be expropriated from you. However, it can for example be subject to garnishment. Of course, these property rights can likely only be fully ensured legally for domains under a CC TLD of the EU.
I see it more like a phone number or postal address, which implicitly also identifies you. Maintaining it generally incurs costs one way or the other. Heck, even the mandatory renewal of national ID cards isn't free.
I believe that identity and identity attestations must be well-separated concepts. I am myself (identity), a government had issued me a passport for $name (attestation), and my friends know me as $nickname (another attestation), etc etc.
Third party attestations/endorsements can be based on any conditions, such as payments, behaviors, or whatever - that's up to third parties to decide. But those mustn't be my identity (because that way my identity becomes something a third party controls, and that's not how things are), they must only refer to it.
It's basically Web-of-Trust again (and I realize any attempts to build a digital one had failed so far)
Well, think of it as a technical term and not a metaphysical one then. Self sovereign cryptographic identification is great, but at some point you have to choose a global namespace so people have a handle to address you by, your choices are some centralized dictatorship like a gmail address or a twitter id, or you can use the globally and politically distributed name resolution system with decades of legal precedent we call DNS.
EDIT: I will concede there is likely some kind of peering/pubsub architecture that would allow for connecting to people you know via QR codes of their DIDs and then using nicknames you distribute to those followers or whathaveyou, I for one am enamored by the design of KERI [0], but I guess you have to decide whether you want people to open a connection to you without any prior negotiation with any of your peers. But if you're OK with people having to be "in-network" or part of a gossiping p2p setup, maybe we can get by without paying third parties for identities.
My concern is that technical quirks tend to sometimes bleed out of their domains and start to change our perception of the society/world itself.
In the meatspace, I'm sure I don't have any single global handle. Here I have an online handle, my wife has a nickname for me, my friends use various names and nicknames too, one country's government had issued me a passport for one legal name, another country's government - for a different one, and so on. So I wonder if thinking of choosing a global namespace is actually a design mistake, as it doesn't match how the world works.
This said, KERI looks interesting - I like the idea that there's no single global ledger, as it matches my own thoughts on the matter. Thank you for the link, I'll save it to my reading list.
If you add date info to a domain it can work. See the fdc URN scheme for an example. Otherwise, you are right. I'm not sure why they didn't do something like this with ATproto IDs.
I actually managed to buy it back after I insulted them and let them understand that I wasn't interested (so they let it lapse as well). And I've set it on auto-renew ever since.
But it's not like it didn't happen to Google too, so don't patronize me. It's a legitimate vulnerability if you use a domain name as a source of identity.
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.
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.
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)
The seems like it would best be solved with an additional, optional attestation layer on top of domain-based uniqueness though.
Nobody cares if I'm ethbr1 or ethbr2. Uniqueness and stability suffices for me.
People do care if {famous person} is {famous person}. Therefore there should be some attestation process for mapping who the current official domain is for {famous person}.
Attestation is a great way to think about this, similar to cosign/sigstore. We can label an existing record or associate new records with it to support this feature. Multiple entities can attest and their track record, transparency, and reputation can feed into those which people decide they trust
What I like about ATProto is that it is decoupled like this, even if it still has weak points in terms of decentralization. We can build and extend outside of the choices and governance of Bluesky. It is a true platform in the sense that will make the participants more money than the originators in the long run
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.
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.
This is always true any time you have more than 1 human involved. People can always become corrupt and dishonest, and no technological solution will solve that.
> 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.
As with most things of moderate import or more, the vibes matter.
Setting up your own domain is pretty simple, but it is also daunting for people their first time.
Even with all the hand holding in the world, without 1:1 human interaction most people won't make that jump.
The daunting part is usually DNS. Also, a major flaw with domain names is the fact that they are subject to the whims of the provider. What if your last name is Nintendo? Are you going to spend your time disputing every single DMCA and domain seizure request that come your way?
As a user, I'm mostly fine with making an account with Google or Meta and using that as my identity root. I know there are a lot of problems with that, for example you can lose your account, but you have all the same problems with a different party that registers domains. Besides, the domain model is more complicated and I've had domains lapse, had problems with transferring, and so on.
What I'd want is:
1. register with some trustworthy third party (be it Google, Bluesky, or whoever), get an identity (can be a domain, but an entry in a database is fine)
2. have the option to craft an identity from thin air (by generating a key pair on my laptop)
3. have the option to move between 1. and 2. or between multiple instances of 1. (identity takeout)
4. (bonus) have the option to create sub-identities: I can register a completely new pseudonymous account, but have some (cryptographic) proof that this identity has certain properties: it is tied to a Google employee, to a woman, to someone with > 10.000 Stackexchange score ... without anybody being able to link that account to the person.
I think 1 and 2 are solved, 3 is quite tricky from a UX perspective, and 4 is going to be really hard (but would enable a lot of cool scenarios).
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.
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?
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
Since I'm not a celebrity, one is as authoritative as the other :)
But one of them I can receive email on and it also hosts my blog, and if I wanted to, I could reference it here in my bio, just like how people do it for "non-self-custodial" social media identities.
It's not perfect, but at least it works across services for regular people without any risk of "handle sniping" once a new service becomes popular. (I suspect that for regular social networks, different rules apply to celebrities than to regular people.)
And for companies, there's always trademark law, which is already heavily integrated into the domain registry framework: Also not perfect, but definitely better than replicating the same solution to n services/sites.
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
Tying legal name to social media exacerbate toxicity too. People are more likely to double down on mistakes when their reputation is (perceived to be) at stake, and published legal identities are prone to abuses.
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.
> 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).
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.
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].
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.
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
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.
So when I visit my did:plc at https://plc.directory/did:plc:i3gjwozl32eq3j3ejyw44hh4 It has a reference to alsoKnownAs: ["at://evbogue.com"]. And that is _not_ my did:web. That is a reference to the dns txt record that I used to verify my account and lose the subdomain evbogue.bsky.app that I had before.
at://evbogue.com is your handle, you don't have a did:web because you have a did:plc instead. Your DID string is the immutable root of your account's identity, it cannot be changed (the DID document it references can be updated, though) - but you can create a new account that uses a did:web instead. There aren't really any instructions on doing so (afaik) but you can do it pretty easily when you self-host a PDS.
(It's no longer possible to create new accounts with a did:web on Bluesky PBC's hosted PDSes, mine is old and "grandfathered" in)
> It's no longer possible to create new accounts with a did:web on Bluesky PBC's hosted PDSes
If that's the case, what is the (very well hidden) "choose your account provider" button on Bluesky's registration page ("You are creating an account on [[Bluesky Social]]") used for? Self-hosted PDS? If so, if it's possible to spin up a temporary PDS with TryCloudflare for the initial set up and keep the did.json hosted on static site instead?
What I’m thinking of is to use the _redirect file as a manual DDNS with cloudflare pages as a stable url that points to an ephemeral TryCloudflare address of a temp PDS running on my laptop. Does the validation scheme follow through HTTPS redirects?
This is an interesting idea that is worth exploring more.
I wonder if when your PDS was online if you had some kind of local sync for messages from the people you follow? You wouldn't follow many people, so you could quickly build a local Appview that organizes the posts into a chronological feed. Then you could browse your messages later without an Internet connection.
What happens if I set my handle on my selfhosted PDS as "alsoKnownAs: [evbogue.com]" and leave my handle at Bluesky PBC's PDS as "alsoKnownAs: [evbogue.com]".
Worked really nicely for backing up private git repos to multiple devices, they might have found a good market in shared file systems where every artifact is signed by the author, making file provenance possible. I consider the zoom acquisition one of the greater tragedies in software history.
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.
Ugh, reading that gave my flashbacks to clubhouse moderation, how one person blocking you would prevent you from seeing any room they were speaking in, how you get silently kicked from a room if someone who blocked you is upgraded from audience to speaker, and if someone who has you blocked joins a room you’re already in, cue Fred Armison, believe it or not, straight to jail!
Worst of all this was all opaque to the user on both ends, manifesting as merely glitchy behavior, but I was causal in blocking people who annoyed me because I didn’t think there were any consequences besides not being able to follow/DM me, and this guy I didn’t know ended up contacting a mutual friend begging me to unblock them because I had suddenly excluded them from all the rooms that we were both spending time in!
Maybe there needs to be more nuance in the block button, like, what kind of restraining order are you looking for here, don’t call me? Or don’t ever interact with me or my friends ever again? Platform needs to make consequences of hitting that button clear tho.
Basically, it allows OP to be a dang, or reddit-style mod of their own thread.
Negative: If OP is not interested in opposing views, they can shut that down.
Plus: the option to kill trolls, dead.
These types of design decisions all have plusses and minuses, but I am in favor of killing trolls given that if someone is militantly not into hearing opposing views, I can just not follow them.
For me it’s a great feature. If there’s a troll or an harasser, this remove their influence a lot because this kill all their work instantly. It makes the person posting in charge of their own replies.
You can always quote/embed the thread you're replying to "own" the reply that you're making.
I think you can understand the point I'm trying to make if you keep in mind that Bsky is essentially a microblog. (For the dinosaurs, a newspaper)
Each profile gets the right and the burden/responsibility of moderating/editorializing their page as they see fit.
It's _totally normal_ that you can't force a newspaper or a blog to publish content that they don't want to publish. And in the meatspace, if you want to get your voice/reply/commentary heard, you make your own blog/newspaper.
People have the right to make their voice/opinion/commentary heard, but you can't force other people to associate/publish/republish your message to their readers. You have the right to your own opinion, but only on your own personal forum, otherwise it's open to the court of public opinion and can be restricted if on someone else's forum.
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.
Can nostr be used for the same form of social network as bluesky (ie, a twitter clone)? It seems that it would only show messages from people the user explicitly follows, for example, and not replies by a third user.
Also it's distasteful to do any sort of content addressing on json data. One would think they'd learn and use CBOR after seeing secure scuttlebutt, but no? Now you have to worry about only sending text payloads, escaping some characters, avoiding whitespace when printing the json... Guaranteed to be a source of bugs...
1) It's up to the relay and the software how much of the firehose of posts to present to users. Your client is in control if whether you see posts from your follows (who you follow), or the entire world.
2) One of the things Nostr did get [slightly] wrong was the hashing of the JSON. It's pretty straight-forward to sort properties, and remove spaces, to create canonical JSON that can easily be hashed, but (and I forgot the specific reason) Nostr made it where you can't directly store Nostr in IPFS (for example) and have the post hash/ID be identical to the IPFS CID of the canonical JSON. They missed that opportunity because fiatjaf was not well enough versed in IPFS, so he got that a bit wrong.
All that being said I am still a fan of Nostr. It is far better than other Social Media protocols imo.
I think they should have not reinvented the wheel ;-) and use dCBOR42, which has an actual canonical form. But somehow people like to use json in places where it's shown again and again it's a terrible choice.
The problem with CBOR is that once people relate it to IPFS their will be massive push-back, because IPFS is seen as too complex. I know this is true because I saw it happen. To these kids even XML is deemed "too complex", thus their love affair with JSON instead.
The reason Social Media protocols need to be kept simple is precisely for this reason. Getting developers to all agree on things is next to impossible. So the way to combat that is by removing all those "things", and go with the simplest design that's workable. It's almost like politics in that it's "The Art of the Possible". And to be "possible" in this context means universal acceptance.
Maybe you're right, that's quite sad. I found dasl.ing to be quite nice and simple as a foundation for dCBOR42, without needing the full ipfs craziness. Oh well.
ok. And you're right too that CBOR is the "correct" thing to use (despite what I said about acceptance), if we wanted to do it right. CBOR could be the only "complex" piece. Everything else could be Nostr-like (i.e. simple, and using relays).
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.
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.
I don’t know, as an IPFS developer you might be discounting what prerequisite knowledge you possessed while hammering out a nostr implementation.
I looked at nostr but lost interest when I noticed there was no provision for key rollover. I guess that’s fine but ephemeral identities. Is there a concept of using a domain name as a handle like bluesky? It’s been a few years so maybe it’s worth a second look.
I always considered the permanent keys/identities of Nostr to be a desirable thing. I had basically invented Nostr before fiatjaf did. It's a trivially simple "concept".
Key rotation is an unnecessary complexity, imo. I never heard of anyone wanting to use a domain name as identity in Nostr, but there's probably a NIP for that where a domain can prove it owns the private key, and be used as an identity.
I mainly quit Nostr development because it was all essentially controlled by 'fiatjaf', and he was making bad decisions, and a childish intolerable arrogant person in general whenever people asked him to justify those decisions.
The one thing that completely turned me off nostr is the idea that my identity is tied to my private key and that it can not be recovered. I'd guess that the reason you don't hear from people like me is that we simply don't bother to work with such a boneheaded design.
I always felt like in the age of cryptocurrencies, people can be expected to protect their private key, and yeah pretty much if they lose it, they lose their data. I mean that's how encryption works also. No key, no data. I don't call that boneheaded. I think it's a feature not a bug.
Nostr is so far ahead it's not funny, in part because of this, in part because it's actually decentralised, in part because of already existing features built in to almost every client, like zaps.
I don't understand why anyone would invest their time in ATProto over Nostr, and don't know anyone who has studied both and has.
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.
> 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.
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.
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.
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.
Yes, but I don't have the power to predict the future and know which instance that's good today will turn bad at some point, so does it really matter?
> The whole internet used to work that way, where you'd have a separate account for every niche-topic forum.
True, and I'm personally happy it's not like that anymore. And you can still create a new identity per topic/interest if you want to, so arguably federated identities are the best of both worlds.
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.
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.
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.
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.
It's a "shared heap". There are relays that collect and pass the entire firehose of events through themselves to interested parties, there are PDSes that store each user's data, and there are AppViews that users interact with. It's not very decentralized and not at all self-hosting-friendly.
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
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
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.
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.
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
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
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.
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 :)
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.
"Proof of <x>hood" is explicitly a non-goal for FIDO authenticators, and implementors go to great lengths to make it impossible (primarily for privacy reasons); that's why they support anonymous attestation only, except in an enterprise context.
That's the thing about reusing existing services and protocols for "proof of x": Quite often, such proofs being possible are often adjacent to or explicitly an anti-goal.
Apple does indeed offer an API that allows uniquely identifying a given device in a privacy-preserving way, though: There's an API that allows apps to store two bits of information about a given device, such as "this device was involved in fraudulent activity on our platform" or "this device has already redeemed a free trial at one point". Not sure if Google has an equivalent.
No solution is perfect unfortunately. Even biometric login is easily duped, you can just hire a bunch of workers to pass the biometric check. Certainly much cheaper than bribing poor people to scan passports, eventually you'll run out of passports and we have a chance of identifying those types of accounts based on the passport country and how they behave.
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.
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.
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?
Hmm, I'm not using verifiable signatures though. Surely there will continue to be a way for a third party to verify that a passport's NFC is authentic and can be trusted. That and the ability to pull some data off it is all I need.
> 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?
Do you trust banks? Hotels? They all take a copy of your passport and likely store it insecurely.
The information that I store for the passports is irreversible. It's hashed. So even if I wanted to sell it I couldn't. I mean, sure, in the future if this becomes big and there is a company around it, it could become evil at any moment and then start selling this data but then you could easily sue the company for this.
> Hmm, I'm not using verifiable signatures though.
That's even worse then for older passports (and inevitable for newer ones): Everybody will have to trust the service to be honest about not issuing sockpuppet identities. How would you prove that you aren't?
> Do you trust banks? Hotels? They all take a copy of your passport and likely store it insecurely.
That's not a concern I have at all. Every company providing service upon "identity verification" through a scan/copy of somebody's passport deserves everything bad fraudsters can throw at them. It's a non-verification method. And by the same token, the hotel could try to leak the fact that I've stayed there, and everybody taking passport copies seriously as evidence might believe them. I'm fine with that risk too.
Conversely, a private proof-of-humanity service will, by its nature, attract users that want to prove their humanity, well, privately.
> The information that I store for the passports is irreversible. It's hashed.
But that hash is ultimately calculated over somebody's passport data, isn't it? This means that anybody stealing your database will be able to deanonymize any user they have passport data for (which is not exactly secret information, as you've illustrated yourself with the hotel example).
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.
I don't really think being resistant to evil governments is within scope here. Using passports isn't perfect, but practically speaking it's a hell of a lot better than what we have now which is a free for all.
How often does something like this happen? In that scenario there are a number of options though, one of which is just putting a banner on accounts that are impacted.
More often than you might think. The EU COVID-19 immunology status certificate scheme saw some fraudulent issuances, for example.
And "putting a banner on impacted accounts" both partially deanonymizes and effectively bans legitimate users for no fault of their own.
Travel documents are not a digital identity scheme, and using the ICAO biometric travel document scheme contrary to its explicit design goals is just asking for trouble.
Consider the theory that Russian-government-sponsored bots ran wild with COVID disinformation. It doesn't matter whether you actually believe that theory or not - just consider it. If you allow Russian passports as a valid identification source, then Russia would have no problem running that operation. The same applies to every country of course.
Yeah, and this is why we capture the country that issued the passport we verified. Worst case we can add a feature that allows users to share which passport country they used. And yes, this will mean that Russian users will be screwed unfortunately.
I strongly also think we're going to have a social network for humans-only (and one for AI-only, and one for humans + AI)
have you looked into world.org? They're scanning eyes and giving robust human identities. Before immediately dismissing, I'd check out the video -- https://www.youtube.com/watch?v=SXnwoMxKHV8
I think atproto + worldid can one day be very interesting
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).
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.
Yes, that's just another problem with using ICAO biometric travel documents for something they have decidedly never been designed for: They don't have any PIN code protection, unlike some national digital ID schemes based on similar technology.
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
> domain names are owned
Are they really owned? I’ve always thought they’re [f]actually merely temporarily leased from a registry, and the ownership is just a legal fiction.
Unlike cryptographic keys, I don’t think domain names really pass the “can they be taken away without owner’s consent?” test. On paper maybe they should, but that’s certainly not how it is in reality.
Attaching digital identity to something that comes from a third party (a registry) rather than individual themselves is a fundamentally wrong idea.
It depends on the jurisdiction. In the EU, the European Court of Human Rights decided [0] that domains constitute a contractually acquired property or possession in the sense of article 17 of the EU Charter of Fundamental Rights [1]. So at least as long as you pay for the registration, your domain cannot easily be expropriated from you. However, it can for example be subject to garnishment. Of course, these property rights can likely only be fully ensured legally for domains under a CC TLD of the EU.
[0] https://hudoc.echr.coe.int/eng#%7B%22itemid%22:%5B%22001-826...
[1] https://fra.europa.eu/en/eu-charter/article/17-right-propert...
Paying for an identity sounds extremely dystopian to me.
I see it more like a phone number or postal address, which implicitly also identifies you. Maintaining it generally incurs costs one way or the other. Heck, even the mandatory renewal of national ID cards isn't free.
I believe that identity and identity attestations must be well-separated concepts. I am myself (identity), a government had issued me a passport for $name (attestation), and my friends know me as $nickname (another attestation), etc etc.
Third party attestations/endorsements can be based on any conditions, such as payments, behaviors, or whatever - that's up to third parties to decide. But those mustn't be my identity (because that way my identity becomes something a third party controls, and that's not how things are), they must only refer to it.
It's basically Web-of-Trust again (and I realize any attempts to build a digital one had failed so far)
Well, think of it as a technical term and not a metaphysical one then. Self sovereign cryptographic identification is great, but at some point you have to choose a global namespace so people have a handle to address you by, your choices are some centralized dictatorship like a gmail address or a twitter id, or you can use the globally and politically distributed name resolution system with decades of legal precedent we call DNS.
EDIT: I will concede there is likely some kind of peering/pubsub architecture that would allow for connecting to people you know via QR codes of their DIDs and then using nicknames you distribute to those followers or whathaveyou, I for one am enamored by the design of KERI [0], but I guess you have to decide whether you want people to open a connection to you without any prior negotiation with any of your peers. But if you're OK with people having to be "in-network" or part of a gossiping p2p setup, maybe we can get by without paying third parties for identities.
[0] https://keri.one/
My concern is that technical quirks tend to sometimes bleed out of their domains and start to change our perception of the society/world itself.
In the meatspace, I'm sure I don't have any single global handle. Here I have an online handle, my wife has a nickname for me, my friends use various names and nicknames too, one country's government had issued me a passport for one legal name, another country's government - for a different one, and so on. So I wonder if thinking of choosing a global namespace is actually a design mistake, as it doesn't match how the world works.
This said, KERI looks interesting - I like the idea that there's no single global ledger, as it matches my own thoughts on the matter. Thank you for the link, I'll save it to my reading list.
If you add date info to a domain it can work. See the fdc URN scheme for an example. Otherwise, you are right. I'm not sure why they didn't do something like this with ATproto IDs.
https://www.rfc-editor.org/rfc/rfc4198.html
> Attaching digital identity to something that comes from a third party (a registry) rather than individual themselves is a fundamentally wrong idea.
That feels like a turtles-all-the-way-dowm problem.
Ultimately, you either have to tie to something suitable that can be obtained by everyone or a unique characteristic of everyone.
And given the blatant privacy issues [0] with uniquely fingerprinting users, I'd much prefer the former alternative.
[0] https://en.m.wikipedia.org/wiki/World_(blockchain)
[flagged]
That's your own fault for letting the registration lapse.
Excellent work by that entrepreneurial random Indian for capitalizing on your negligence.
I actually managed to buy it back after I insulted them and let them understand that I wasn't interested (so they let it lapse as well). And I've set it on auto-renew ever since.
But it's not like it didn't happen to Google too, so don't patronize me. It's a legitimate vulnerability if you use a domain name as a source of identity.
I get it, woke lost the culture war and stereotyping is cool now. But it really doesn't add anything to the comment.
I get it, you're American
I am not in fact American
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.
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.
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)
The seems like it would best be solved with an additional, optional attestation layer on top of domain-based uniqueness though.
Nobody cares if I'm ethbr1 or ethbr2. Uniqueness and stability suffices for me.
People do care if {famous person} is {famous person}. Therefore there should be some attestation process for mapping who the current official domain is for {famous person}.
Attestation is a great way to think about this, similar to cosign/sigstore. We can label an existing record or associate new records with it to support this feature. Multiple entities can attest and their track record, transparency, and reputation can feed into those which people decide they trust
What I like about ATProto is that it is decoupled like this, even if it still has weak points in terms of decentralization. We can build and extend outside of the choices and governance of Bluesky. It is a true platform in the sense that will make the participants more money than the originators in the long run
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.
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.
This is always true any time you have more than 1 human involved. People can always become corrupt and dishonest, and no technological solution will solve that.
> you can solve a lot of problems with the idea of 'just add money'
You also create a lot of problems and break trust, see the recent US election for an example
One-size-fits-all solutions are always inferior to a system that enables multiple solutions to co-exist and which are forced to compete
> 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.
As with most things of moderate import or more, the vibes matter.
Setting up your own domain is pretty simple, but it is also daunting for people their first time.
Even with all the hand holding in the world, without 1:1 human interaction most people won't make that jump.
The daunting part is usually DNS. Also, a major flaw with domain names is the fact that they are subject to the whims of the provider. What if your last name is Nintendo? Are you going to spend your time disputing every single DMCA and domain seizure request that come your way?
Or if your last name is Nissan: https://en.wikipedia.org/wiki/Nissan_Motors_v._Nissan_Comput...
As a user, I'm mostly fine with making an account with Google or Meta and using that as my identity root. I know there are a lot of problems with that, for example you can lose your account, but you have all the same problems with a different party that registers domains. Besides, the domain model is more complicated and I've had domains lapse, had problems with transferring, and so on.
What I'd want is:
1. register with some trustworthy third party (be it Google, Bluesky, or whoever), get an identity (can be a domain, but an entry in a database is fine)
2. have the option to craft an identity from thin air (by generating a key pair on my laptop)
3. have the option to move between 1. and 2. or between multiple instances of 1. (identity takeout)
4. (bonus) have the option to create sub-identities: I can register a completely new pseudonymous account, but have some (cryptographic) proof that this identity has certain properties: it is tied to a Google employee, to a woman, to someone with > 10.000 Stackexchange score ... without anybody being able to link that account to the person.
I think 1 and 2 are solved, 3 is quite tricky from a UX perspective, and 4 is going to be really hard (but would enable a lot of cool scenarios).
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.
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?
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...
except what makes lxgr.dev authoritative over lxgr.net?
How does… Movie Star get an authoritative domain that people can trust?
Since I'm not a celebrity, one is as authoritative as the other :)
But one of them I can receive email on and it also hosts my blog, and if I wanted to, I could reference it here in my bio, just like how people do it for "non-self-custodial" social media identities.
It's not perfect, but at least it works across services for regular people without any risk of "handle sniping" once a new service becomes popular. (I suspect that for regular social networks, different rules apply to celebrities than to regular people.)
And for companies, there's always trademark law, which is already heavily integrated into the domain registry framework: Also not perfect, but definitely better than replicating the same solution to n services/sites.
Someone should tell these people about Keybase.
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
But I don't want random bluesky users to know my government name.
Tying legal name to social media exacerbate toxicity too. People are more likely to double down on mistakes when their reputation is (perceived to be) at stake, and published legal identities are prone to abuses.
Not sure you're the target audience for this kind of verification. I see it being more for people with a public persona
A parallel might be not necessarily a Public persona, but still identity verified
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:
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
> 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...
(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.
> 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
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/
> 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)
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.
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)
So when I visit my did:plc at https://plc.directory/did:plc:i3gjwozl32eq3j3ejyw44hh4 It has a reference to alsoKnownAs: ["at://evbogue.com"]. And that is _not_ my did:web. That is a reference to the dns txt record that I used to verify my account and lose the subdomain evbogue.bsky.app that I had before.
If I was to upload a document like yours at https://retr0.id/.well-known/did.json
How do I configure Bluesky's social application to reference my did document at https://evbogue.com/.well-known/did.json (which doesn't exist yet) and have that be how people find my posts on Bluesky? Even if my selfhosted did document points to "https://shimeji.us-east.host.bsky.network" as my PDS?
Could I use this to host my stuff at many PDSes?
Sorry if I seemed confused. I listened the whole podcast and didn't realize alsoKnownAs is different than did:web.
at://evbogue.com is your handle, you don't have a did:web because you have a did:plc instead. Your DID string is the immutable root of your account's identity, it cannot be changed (the DID document it references can be updated, though) - but you can create a new account that uses a did:web instead. There aren't really any instructions on doing so (afaik) but you can do it pretty easily when you self-host a PDS.
(It's no longer possible to create new accounts with a did:web on Bluesky PBC's hosted PDSes, mine is old and "grandfathered" in)
> It's no longer possible to create new accounts with a did:web on Bluesky PBC's hosted PDSes
If that's the case, what is the (very well hidden) "choose your account provider" button on Bluesky's registration page ("You are creating an account on [[Bluesky Social]]") used for? Self-hosted PDS? If so, if it's possible to spin up a temporary PDS with TryCloudflare for the initial set up and keep the did.json hosted on static site instead?
> Self-hosted PDS?
Yes, or some other commercial PDS hosting service.
> If so, if it's possible to spin up a temporary PDS with TryCloudflare for the initial set up and keep the did.json hosted on static site instead?
Not sure why you'd want to do that, but it sounds possible.
What I’m thinking of is to use the _redirect file as a manual DDNS with cloudflare pages as a stable url that points to an ephemeral TryCloudflare address of a temp PDS running on my laptop. Does the validation scheme follow through HTTPS redirects?
This is an interesting idea that is worth exploring more.
I wonder if when your PDS was online if you had some kind of local sync for messages from the people you follow? You wouldn't follow many people, so you could quickly build a local Appview that organizes the posts into a chronological feed. Then you could browse your messages later without an Internet connection.
This helps, I am less confused now.
What happens if I set my handle on my selfhosted PDS as "alsoKnownAs: [evbogue.com]" and leave my handle at Bluesky PBC's PDS as "alsoKnownAs: [evbogue.com]".
Then the handle on the not-self-hosted-account will be invalidated (potentially after some cache expiry)
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.
no, that's just the identifier, I'm talking about the json document itself.
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.
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.
Worked really nicely for backing up private git repos to multiple devices, they might have found a good market in shared file systems where every artifact is signed by the author, making file provenance possible. I consider the zoom acquisition one of the greater tragedies in software history.
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.
Ugh, reading that gave my flashbacks to clubhouse moderation, how one person blocking you would prevent you from seeing any room they were speaking in, how you get silently kicked from a room if someone who blocked you is upgraded from audience to speaker, and if someone who has you blocked joins a room you’re already in, cue Fred Armison, believe it or not, straight to jail!
Worst of all this was all opaque to the user on both ends, manifesting as merely glitchy behavior, but I was causal in blocking people who annoyed me because I didn’t think there were any consequences besides not being able to follow/DM me, and this guy I didn’t know ended up contacting a mutual friend begging me to unblock them because I had suddenly excluded them from all the rooms that we were both spending time in!
Maybe there needs to be more nuance in the block button, like, what kind of restraining order are you looking for here, don’t call me? Or don’t ever interact with me or my friends ever again? Platform needs to make consequences of hitting that button clear tho.
This is an interesting feature.
Basically, it allows OP to be a dang, or reddit-style mod of their own thread.
Negative: If OP is not interested in opposing views, they can shut that down.
Plus: the option to kill trolls, dead.
These types of design decisions all have plusses and minuses, but I am in favor of killing trolls given that if someone is militantly not into hearing opposing views, I can just not follow them.
For me it’s a great feature. If there’s a troll or an harasser, this remove their influence a lot because this kill all their work instantly. It makes the person posting in charge of their own replies.
> It makes the person posting in charge of their own replies.
I think replies should be owned by the one posting them, not the one they’re replying to.
You can always quote/embed the thread you're replying to "own" the reply that you're making.
I think you can understand the point I'm trying to make if you keep in mind that Bsky is essentially a microblog. (For the dinosaurs, a newspaper)
Each profile gets the right and the burden/responsibility of moderating/editorializing their page as they see fit. It's _totally normal_ that you can't force a newspaper or a blog to publish content that they don't want to publish. And in the meatspace, if you want to get your voice/reply/commentary heard, you make your own blog/newspaper.
People have the right to make their voice/opinion/commentary heard, but you can't force other people to associate/publish/republish your message to their readers. You have the right to your own opinion, but only on your own personal forum, otherwise it's open to the court of public opinion and can be restricted if on someone else's forum.
Stay on Twitter I guess if comments sections of people yelling at each other is what you think the good content is?
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.
Can nostr be used for the same form of social network as bluesky (ie, a twitter clone)? It seems that it would only show messages from people the user explicitly follows, for example, and not replies by a third user.
Also it's distasteful to do any sort of content addressing on json data. One would think they'd learn and use CBOR after seeing secure scuttlebutt, but no? Now you have to worry about only sending text payloads, escaping some characters, avoiding whitespace when printing the json... Guaranteed to be a source of bugs...
1) It's up to the relay and the software how much of the firehose of posts to present to users. Your client is in control if whether you see posts from your follows (who you follow), or the entire world.
2) One of the things Nostr did get [slightly] wrong was the hashing of the JSON. It's pretty straight-forward to sort properties, and remove spaces, to create canonical JSON that can easily be hashed, but (and I forgot the specific reason) Nostr made it where you can't directly store Nostr in IPFS (for example) and have the post hash/ID be identical to the IPFS CID of the canonical JSON. They missed that opportunity because fiatjaf was not well enough versed in IPFS, so he got that a bit wrong.
All that being said I am still a fan of Nostr. It is far better than other Social Media protocols imo.
I think they should have not reinvented the wheel ;-) and use dCBOR42, which has an actual canonical form. But somehow people like to use json in places where it's shown again and again it's a terrible choice.
The problem with CBOR is that once people relate it to IPFS their will be massive push-back, because IPFS is seen as too complex. I know this is true because I saw it happen. To these kids even XML is deemed "too complex", thus their love affair with JSON instead.
The reason Social Media protocols need to be kept simple is precisely for this reason. Getting developers to all agree on things is next to impossible. So the way to combat that is by removing all those "things", and go with the simplest design that's workable. It's almost like politics in that it's "The Art of the Possible". And to be "possible" in this context means universal acceptance.
Maybe you're right, that's quite sad. I found dasl.ing to be quite nice and simple as a foundation for dCBOR42, without needing the full ipfs craziness. Oh well.
ok. And you're right too that CBOR is the "correct" thing to use (despite what I said about acceptance), if we wanted to do it right. CBOR could be the only "complex" piece. Everything else could be Nostr-like (i.e. simple, and using relays).
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.
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.
I don’t know, as an IPFS developer you might be discounting what prerequisite knowledge you possessed while hammering out a nostr implementation.
I looked at nostr but lost interest when I noticed there was no provision for key rollover. I guess that’s fine but ephemeral identities. Is there a concept of using a domain name as a handle like bluesky? It’s been a few years so maybe it’s worth a second look.
I always considered the permanent keys/identities of Nostr to be a desirable thing. I had basically invented Nostr before fiatjaf did. It's a trivially simple "concept".
Key rotation is an unnecessary complexity, imo. I never heard of anyone wanting to use a domain name as identity in Nostr, but there's probably a NIP for that where a domain can prove it owns the private key, and be used as an identity.
I mainly quit Nostr development because it was all essentially controlled by 'fiatjaf', and he was making bad decisions, and a childish intolerable arrogant person in general whenever people asked him to justify those decisions.
> I never heard of anyone wanting to use a domain name as identity in Nostr
https://en.wikipedia.org/wiki/File:Survivorship-bias.svg
The one thing that completely turned me off nostr is the idea that my identity is tied to my private key and that it can not be recovered. I'd guess that the reason you don't hear from people like me is that we simply don't bother to work with such a boneheaded design.
I always felt like in the age of cryptocurrencies, people can be expected to protect their private key, and yeah pretty much if they lose it, they lose their data. I mean that's how encryption works also. No key, no data. I don't call that boneheaded. I think it's a feature not a bug.
[dead]
Came here to say this.
Nostr is so far ahead it's not funny, in part because of this, in part because it's actually decentralised, in part because of already existing features built in to almost every client, like zaps.
I don't understand why anyone would invest their time in ATProto over Nostr, and don't know anyone who has studied both and has.
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.
> 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.
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.
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.
You still somewhat own your identity on the fediverse as you can decide to migrate to another server and all your followers will be migrated.
Sure you lose the content you posted. And it’s an important point. But your identity, is migrated.
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.
Yes, but I don't have the power to predict the future and know which instance that's good today will turn bad at some point, so does it really matter?
> The whole internet used to work that way, where you'd have a separate account for every niche-topic forum.
True, and I'm personally happy it's not like that anymore. And you can still create a new identity per topic/interest if you want to, so arguably federated identities are the best of both worlds.
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.
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.
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
Private posts/feeds/groups is one of the biggest things missing from ATProto at this point.
Once they solve that it will really take off beyond just a better Twitter.
Another effort that could help is the lexicon-community. The goal is to create a number of lexicon that can be reused across apps.
https://github.com/lexicon-community/lexicon
Calendar, locations, and events is one of the first they are considering
https://github.com/lexicon-community/lexicon/pull/23
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.
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.
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.
If the fediverse's structure is like email, what's atproto's structure?
It's a "shared heap". There are relays that collect and pass the entire firehose of events through themselves to interested parties, there are PDSes that store each user's data, and there are AppViews that users interact with. It's not very decentralized and not at all self-hosting-friendly.
In-depth article: https://dustycloud.org/blog/how-decentralized-is-bluesky/
By default: @user.bsky.social
If you verify your domain: @yourdomain.tld
Gmail.
Is ATProto fully implementable by third parties? I last read there were still closed source parts
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
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
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
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.
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
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.
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 .`
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
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.
"Proof of <x>hood" is explicitly a non-goal for FIDO authenticators, and implementors go to great lengths to make it impossible (primarily for privacy reasons); that's why they support anonymous attestation only, except in an enterprise context.
That's the thing about reusing existing services and protocols for "proof of x": Quite often, such proofs being possible are often adjacent to or explicitly an anti-goal.
Apple does indeed offer an API that allows uniquely identifying a given device in a privacy-preserving way, though: There's an API that allows apps to store two bits of information about a given device, such as "this device was involved in fraudulent activity on our platform" or "this device has already redeemed a free trial at one point". Not sure if Google has an equivalent.
No solution is perfect unfortunately. Even biometric login is easily duped, you can just hire a bunch of workers to pass the biometric check. Certainly much cheaper than bribing poor people to scan passports, eventually you'll run out of passports and we have a chance of identifying those types of accounts based on the passport country and how they behave.
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.
> 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.
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...
Hmm, I'm not using verifiable signatures though. Surely there will continue to be a way for a third party to verify that a passport's NFC is authentic and can be trusted. That and the ability to pull some data off it is all I need.
> 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?
Do you trust banks? Hotels? They all take a copy of your passport and likely store it insecurely.
The information that I store for the passports is irreversible. It's hashed. So even if I wanted to sell it I couldn't. I mean, sure, in the future if this becomes big and there is a company around it, it could become evil at any moment and then start selling this data but then you could easily sue the company for this.
> Hmm, I'm not using verifiable signatures though.
That's even worse then for older passports (and inevitable for newer ones): Everybody will have to trust the service to be honest about not issuing sockpuppet identities. How would you prove that you aren't?
> Do you trust banks? Hotels? They all take a copy of your passport and likely store it insecurely.
That's not a concern I have at all. Every company providing service upon "identity verification" through a scan/copy of somebody's passport deserves everything bad fraudsters can throw at them. It's a non-verification method. And by the same token, the hotel could try to leak the fact that I've stayed there, and everybody taking passport copies seriously as evidence might believe them. I'm fine with that risk too.
Conversely, a private proof-of-humanity service will, by its nature, attract users that want to prove their humanity, well, privately.
> The information that I store for the passports is irreversible. It's hashed.
But that hash is ultimately calculated over somebody's passport data, isn't it? This means that anybody stealing your database will be able to deanonymize any user they have passport data for (which is not exactly secret information, as you've illustrated yourself with the hotel example).
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.
I don't really think being resistant to evil governments is within scope here. Using passports isn't perfect, but practically speaking it's a hell of a lot better than what we have now which is a free for all.
It only takes a single government losing their signing keys (through whatever means) to break such a scheme.
And if that happens, what do you do? Deny service to that country's citizens?
How often does something like this happen? In that scenario there are a number of options though, one of which is just putting a banner on accounts that are impacted.
More often than you might think. The EU COVID-19 immunology status certificate scheme saw some fraudulent issuances, for example.
And "putting a banner on impacted accounts" both partially deanonymizes and effectively bans legitimate users for no fault of their own.
Travel documents are not a digital identity scheme, and using the ICAO biometric travel document scheme contrary to its explicit design goals is just asking for trouble.
Consider the theory that Russian-government-sponsored bots ran wild with COVID disinformation. It doesn't matter whether you actually believe that theory or not - just consider it. If you allow Russian passports as a valid identification source, then Russia would have no problem running that operation. The same applies to every country of course.
Yeah, and this is why we capture the country that issued the passport we verified. Worst case we can add a feature that allows users to share which passport country they used. And yes, this will mean that Russian users will be screwed unfortunately.
I strongly also think we're going to have a social network for humans-only (and one for AI-only, and one for humans + AI)
have you looked into world.org? They're scanning eyes and giving robust human identities. Before immediately dismissing, I'd check out the video -- https://www.youtube.com/watch?v=SXnwoMxKHV8
I think atproto + worldid can one day be very interesting
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).
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.
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.
Yes, that's just another problem with using ICAO biometric travel documents for something they have decidedly never been designed for: They don't have any PIN code protection, unlike some national digital ID schemes based on similar technology.
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.