Colby on Nostr: DIDs as URLs will be needed for a decentralized web, but I have some concerning ...

DIDs as URLs will be needed for a decentralized web, but I have some concerning doubts about ION.

1. ION uses IPFS. Nostr 2.0 will replace IPFS for off-chain data storage. IPFS is clunky software that forces users to spin up a node to verify data, killing the user-server model that we're trying to decentralize with Nostr. Proof of this requirement in IPFS is in the quote below.
https://decrypt.co/resources/how-to-use-ipfs-the-backbone-of-web3

“Brave gives you the option to access IPFS content through a public gateway or 𝘵𝘩𝘳𝘰𝘶𝘨𝘩 𝘺𝘰𝘶𝘳 𝘰𝘸𝘯 𝘭𝘰𝘤𝘢𝘭 𝘯𝘰𝘥𝘦—𝘵𝘩𝘦 𝘭𝘢𝘵𝘵𝘦𝘳 𝘰𝘱𝘵𝘪𝘰𝘯 𝘪𝘴 𝘧𝘰𝘳 𝘵𝘩𝘰𝘴𝘦 𝘸𝘩𝘰 𝘸𝘢𝘯𝘵 𝘵𝘰 𝘷𝘦𝘳𝘪𝘧𝘺 𝘤𝘰𝘯𝘵𝘦𝘯𝘵 𝘭𝘰𝘤𝘢𝘭𝘭𝘺.”

In Nostr 2.0, user light wallets can verify data with on-chain Merkle proofs without needing to spin up an IPFS node or Nostr node. This advancement addresses some of the resource-intensiveness associated with IPFS and can help improve the user experience and scalability of decentralized web applications.

2. Light wallet users verifying a custom URL on ION doesn't seem as secure as light wallet users doing so via an ENS registry. To my knowledge, ION doesn't support custom domains yet; this might be why.👇🧵

The ENS registry lets user light wallets verify the state of the on-chain domain registry smart contract with a Patricia-Merkle proof that prevents duplicate registration of domains. This way, light wallet users can't be tricked into resolving a domain to the wrong IP.

ION, on the other hand, verifies domains through a normal Merkle proof, but light wallet users can be tricked because an ION node could modify their ION software and deliver a Merkle proof to users showing a new on-chain registration of an already registered domain.

𝘛𝘩𝘦 𝘐𝘖𝘕 𝘯𝘰𝘥𝘦 𝘤𝘰𝘶𝘭𝘥 𝘪𝘨𝘯𝘰𝘳𝘦 𝘢 𝘱𝘳𝘦𝘷𝘪𝘰𝘶𝘴 𝘳𝘦𝘨𝘪𝘴𝘵𝘳𝘢𝘵𝘪𝘰𝘯 𝘰𝘧 𝘵𝘩𝘦 𝘤𝘶𝘴𝘵𝘰𝘮 𝘥𝘰𝘮𝘢𝘪𝘯, 𝘯𝘰𝘵 𝘥𝘦𝘭𝘪𝘷𝘦𝘳 𝘢 𝘔𝘦𝘳𝘬𝘭𝘦 𝘱𝘳𝘰𝘰𝘧 𝘰𝘧 𝘪𝘵 𝘵𝘰 𝘵𝘩𝘦 𝘶𝘴𝘦𝘳, 𝘢𝘯𝘥 𝘵𝘩𝘦 𝘭𝘪𝘨𝘩𝘵 𝘸𝘢𝘭𝘭𝘦𝘵 𝘶𝘴𝘦𝘳 𝘸𝘰𝘶𝘭𝘥 𝘯𝘦𝘷𝘦𝘳 𝘬𝘯𝘰𝘸. 𝘚𝘪𝘯𝘤𝘦 𝘭𝘪𝘨𝘩𝘵 𝘸𝘢𝘭𝘭𝘦𝘵 𝘶𝘴𝘦𝘳𝘴 𝘥𝘰𝘯'𝘵 𝘩𝘢𝘷𝘦 𝘢 𝘗𝘢𝘵𝘳𝘪𝘤𝘪𝘢-𝘔𝘦𝘳𝘬𝘭𝘦 𝘱𝘳𝘰𝘰𝘧 𝘵𝘰 𝘷𝘦𝘳𝘪𝘧𝘺 𝘵𝘩𝘦 𝘴𝘵𝘢𝘵𝘦 𝘰𝘧 𝘵𝘩𝘦 𝘳𝘦𝘨𝘪𝘴𝘵𝘳𝘺, 𝘵𝘩𝘦𝘺'𝘳𝘦 𝘫𝘶𝘴𝘵 𝘳𝘦𝘭𝘺𝘪𝘯𝘨 𝘰𝘯 𝘵𝘩𝘦 𝘧𝘢𝘤𝘵 𝘵𝘩𝘢𝘵 𝘵𝘩𝘦 𝘔𝘦𝘳𝘬𝘭𝘦 𝘳𝘰𝘰𝘵 𝘰𝘧 𝘵𝘩𝘦 𝘱𝘳𝘰𝘰𝘧 𝘪𝘴 𝘰𝘯-𝘤𝘩𝘢𝘪𝘯 𝘧𝘰𝘳 𝘵𝘩𝘦𝘪𝘳 𝘥𝘰𝘮𝘢𝘪𝘯 𝘷𝘦𝘳𝘪𝘧𝘪𝘤𝘢𝘵𝘪𝘰𝘯 — 𝘵𝘩𝘢𝘵 𝘪𝘴𝘯'𝘵 𝘦𝘯𝘰𝘶𝘨𝘩.

An ION node could deliver a valid Merkle proof showing the data is on-chain while omitting the previous registration. Since the user doesn't have the ability to verify if the registry rejected the domain registration entry in ION, it is vulnerable to this omission attack — unlike the ENS registry, where light wallet users can verify if the ENS registry rejected the custom URL by checking the state of the ENS smart contract with Patricia-Merkle trees. Light wallet users don't have the luxury of a Patricia-Merkle tree in ION, so they don't get the same level of verification.

This is likely why ION does not support custom URLs.

The normal internet started with IP addresses, then custom domains came afterward. It seems like a wise route to follow for now, as current solutions for custom URLs on Bitcoin are inadequate. Bitcoin addresses will be our URLs for now, like IPs in the early '80s.

I'd appreciate anyone skilled in DID URLs responding moegrammer (npub1m0e…v88s) brockm (npub1hyq…k7cp) and proving me wrong if I am. ION is indeed complicated, and now I understand why fiatjaf (npub180c…h6w6) and jb55 (npub1xts…kk5s) complain about it as a standard.