Oddbean

did:plc is a shitcoin. Let me explain to you why. On #Nostr, your public key is your user ID. On #Bluesky, although you have a public key, your real user ID is a did:plc. To generate a did:plc, you must make a POST request to https://plc.directory/ Yes, https://plc.directory/ (the literal URL) is part of the protocol definition. They'll say it's not, but it is. They'll say it's not, because theoretically you could run multiple plc.directory servers, and people could point at different ones. But there are big challenges around security and UX of that, and let's be real, Bluesky never intends to "fix" it (it's not broken). Now, if we just put the whole thing on a blockchain that would totally solve that problem. But in fact, did:plc "does not make use of any blockchain". Because the accepted decentralized way to achieve this _would_ be to put it on a blockchain, so they had to make that qualifying statement against it. So, they needed to use a blockchain, but they don't want to use a blockchain. So they invented their own blockchain: a regular webserver! And they pretended their regular webserver was a blockchain. And this, is why did:plc is a shitcoin. nostr:nevent1qvzqqqqqqypzqprpljlvcnpnw3pejvkkhrc3y6wvmd7vjuad0fg2ud3dky66gaxaqydhwumn8ghj7emvv4shxmmwv96x7u3wv3jhvtmjv4kxz7gqyquwr3r6sghg57hzp7refr72p0ck484tt5tk6a2wjtslrl00z4gl54mdxtz

> Now, if we just put the whole thing on a blockchain that would totally solve that problem. I would be very surprised if this were true, as I have failed to find a sound use of a blockchain outside of a fungible currency. The problems are always deciding whether a change is valid, and enforcing the on-chain information. With Bitcoin a change is valid if it sends value less than what's in a wallet to somewhere and is signed by the corresponding private key. The change is also respected because now the wallet doesn't have control of the value, and (probably) someone else does. Both of these are automated and verifiable by anyone. When you put something else on the chain, say the deed to a house, miners can't validate the change unless it's an ordinal. Fair enough, we can assign an ordinal. But they also can't enforce the effect: only the government decides who owns a house. Once you identify this part which isn't automated, you might as well replace the blockchain with a database. So, on the one hand, it seems that they did the right thing and avoided using a blockchain in a way that doesn't make sense. But on the other, it's presumably because only one group can determine whether a change is valid, which means it was never distributed in the first place. Identity is a surprisingly difficult problem. Nostr gets most of it right, except for combining identity and authorization into a single key. No reasonable system still uses "$username:$password" as their session id.

You are confusing things. Blockchains indeed dont work irt 'physical' things. But 'identity' is just an abstract notion. Its just a registration of names and pointers, and signatures determine validity. So that should work fine. The problem is that blockchains dont scale well on the one hand and you have an incentive problem on the other. So Alex is correct in this statement: we know how to do decentralized global state, and we barely know and for the most part are still finding out over time if it works for money, let alone something else. Accepting that, leaves us with putting keys at the center of the system, and as such you have no option other than 'combining identity and authorization'. Your complaint against that is the same old trap that makes people want to look at blockchains or whatever, because you need a registry linking the two if you dont want to combine them. If your conclusion is that putting keys at the center of things (not an unreasonable possition btw) is unwise/wont work, then give up on Bitcoin and give up on Nostr.

I welcome being disproven, but I don't think you've done that. Blockchains have a head, and the head is advanced somehow. How does your identity chain advance? Who has the authority to advance it? Without proof of work, you have a Merkle tree. Without rewards, what is the incentive to compete proof of work? Regarding identity and authorization, you haven't even made an argument. Mine is https://github.com/nostr-protocol/nips/pull/1450

It is not just UX, if the plc directory censors your operations, you are screwed, and then people say oh but we can detect that and start using another registery, as if this is viable in practice, as if we couldn't in theory use a separate root servers than ICANN.

Cc nostr:nprofile1qqsvgepe3vk2h65cdwcyf6f53ec2x68j5npth8my07fhhjenhsumajspzemhxue69uhhyetvv9ujumn0wvh8xmmrd9skcqgcwaehxw309amk2mrrdakk2tnwdaehgu3wwa5kuegpp4mhxue69uhkummn9ekx7mq9d5mg2 in case you have any thoughts on this, as resident nostr/Bluesky exchange student:)

using a centralized registry web service is a cop-out, but there's not really an obvious solution either DHT and blockchain are basically the opposite extremes in this case, blockchain can provide a bad user experience because it can never forget (no way to delete private information), DHT can provide a bad user experience because it's potentially lossy (same frustrations as say, IPFS) nostr takes the "roll with the chaos" approach by not having any kind of guaranteed global identifiers, which is, another kind of compromise

Some remarks on that from their CTO and engineering lead: "there are multiple longterm options being discussed for plc, but the most well-regarded right now is an neutral ICANN-style org to operate it" "Technically, Bluesky PBC is still operating the PLC directory (we are actively exploring how to change this). However, there are already independent developers in the ecosystem who are mirroring and auditing the stream of operations from the directory, so any retroactive manipulation would be observed and called out." That debate aside, nostr is quite magical for the sheer lightness of it all, it's like travelling with only a carry-on and priority boarding all the time, I can't see any other architecture coming close there.