[pfraze]

The DID method has to satisfy a lot of requirements. I did a ton of research on DHT and blockchain approaches and none of them give the right performance, reliability, and cost outcomes while also supporting key rotation. DNS isn't far off but it's a little obtuse to cram it into, so we're starting with did:web and did:plc. We'll add others if they have the right characteristics.

The only options that seem reasonable for PLC is for it either to be operated by some trusted multi-stakeholder institution like ICANN or to be a closed-group blockchain. I'm open to either approach but they require the creation of a consortium, which requires buyin from a set of stakeholders that don't exist yet. So until that happens, we run it, and that's why we called it Placeholder. We'll backronym it into something else once we get there (the C most likely being Consortium).

[bb010g]

What are your thoughts on KERI? Some of Phillip's slide decks are weird to go through, but I really like its security & usability goals (key rotation needs to be realistic!) and the fact that it's going through the IETF RFC process. (Also, it avoids cryptocurrency-related blockchain baggage. It's disappointing how much blockchains have infested decentralized identity efforts.)

<https://github.com/WebOfTrust/keri>

[seattleeng]

Since you're familiar with this, what was wrong with how Farcaster approached name registration? Signing up or rotating your key is (relatively) cheap on Ethereum mainnet, and client apps could front the cost of signing users up. The user registry doesn't need to be maintained by a closed group in the long run (could start out that way, with Bluesky maintaining the contracts but eventually removing upgradeability when out of beta).

[pfraze]

I’m concerned about the transaction cost variability that we’ve seen with ethereum.

[gregw2]

Consider Avax?