Trust-minimized Zaps that are verifiable by everyoneโฆ I think Iโve found a way to do it. An attacker can still fake Zaps to themselves, but they canโt fake Zap honest recipients โ and the proofs never expire.โก๏ธ
Compatible with BOLT12 or LNURL, all a user needs is a normal lightwallet to verify Zaps. #[0]โ ๐ฒ
Initially, I thought ION allowed unique URL registration like (did://bob.com), but Daniel clarified that it generates IDs in the format: "ChosenWord-RandomWord-RandomWord" (e.g., "Colby-Purple-Bee").
These trust-minimized IDs are more memorable than npubs or Bitcoin addresses and could function as usernames or domains atop Bitcoin.
Daniel and I discussed Web5 and Nostr 2.0 as co-protocols:
โข Nostr 2.0 provides hosting for websites across hundreds of untrusted relays without the risks of content tampering, thanks to a tamper-evident Merkle root that's on-chain.
โข Web5 enables self-hosting websites across local devices. This combination offers the best of both worlds: decentralized hosting with Nostr 2.0 and local self-hosting with Web5.
๐พ๐๐ฆ ๐๐๐๐๐ก๐ ๐๐๐๐ ๐๐ข๐ ๐๐๐ ๐๐ข๐ ๐ ๐๐๐ ๐๐ ๐๐๐ ๐ก๐ ๐.๐ ๐๐๐ ๐๐๐๐ ๐๐ ๐๐-๐๐๐๐ก๐๐๐๐๐ :
1. Web5 allows website owners to self-host websites locally with decentralized domains, while Nostr 2.0 enables distributed hosting across hundreds of untrusted relays. This offers flexibility depending on the owner's needs.
2. Web5 provides resilient backup solutions for users decentralizing their website with Nostr 2.0, ensuring local copies across their trusted devices.
3. Web5 facilitates direct, encrypted communication between website owners and users. Visitors can browse decentralized websites hosted on many Nostr 2.0 relays and establish a direct connection with the website owners through Web5, all thanks to using the same DID system for domains.
We encourage the Web5 TBD team to develop an ION middlelayer for Nostr 2.0, making ION a middlelayer similar to the decentralized GitHub we are building for the bounty started by #[7]
This modular structure means the Nostr 2.0 base layer for storage ossifies into a standard. This encourages people to build new middlelayers and a diversity of clients for each middlelayer atop the universal, hash-organized off-chain storage. ๐งฑ
Unlike IPFS, Nostr 2.0 lets people browse and verify websites without hosting them. Users donโt need to rely on public IPFS gateways to verify the data either โ thanks to the on-chain Merkle roots Nostr 2.0 utilizes for syncing any off-chain data, identical to the type of on-chain Merkle roots ION uses. We aimed for the same Merkle DAGs and content addressing standards that ION already uses in order to be interoperable.
Most importantly, making all Nostr 2.0 nodes become ION nodes offers a significant advantage: When users type in a DID URL into a browser, the conjoined node would resolve the URL and deliver the tamper-evident website files to the user. ๐
Replacing IPFS with Nostr 2.0 achieves this all-in-one package for a decentralized web powered by Bitcoin, where users can resolve URLs and browse decentralized websites through one type of modular node. If hundreds or thousands of operators run this conjoined node (Nostr 2.0+ION+Bitcoin full-node), the decentralized web becomes a reality. Anytime they want to host specific Twitter profiles or a GitHub repo, they simply add those middlelayers to their node stack and configure their hosting preferences.
๐
Good quote.
โThis paired with the high likelihood that ION DIDs will almost always be resolved by ION nodes instead of clients/light wallets manually doing what an ION node does for you sort of nullifies / diminishes the censorship resistance provided by the anchor to Bitcoin.โ
Thanks Moe.
We cannot rely on a prevalence of honest ION nodes as a form of security because it creates the risk of an ION Sybil attack. The proof a user receives must prove that the URL is not registered to anyone else, like it does in ENS.
Unlike ENS, an ION node could omit previous registrations of a custom URL and deliver valid proofs of a new on-chain registration. This means an attacker could perform URL spoofing on users with a mere ION node Sybil attack and a few bitcoin transactions, unlike the extremely costly 51% attack required for URL spoofing in ENS.
In ENS, full-nodes canโt perform this trick without launching a 51% attack because users receive a Patricia-Merkle proof from full-nodes that verifies the current state of the domain registry. ION trade-offs arenโt worth the risks.
๐ฅน eureka..
โ๏ธ๐๐ฎ๐คซ
Collapses lead to people begging for safety. That desperation might be used as leverage to consolidate government-controlled banking more than ever before.
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 #[1] #[2] and proving me wrong if I am. ION is indeed complicated, and now I understand why #[3] and #[4] complain about it as a standard.
Clever idea for sharing keys in person. #[2]
It can also improve the security of websites because anytime a hacker inserts a foreign file, heโll change the hashes of the websiteโฆ the user or node will automatically detect that it doesnโt match the Merkle Root in the website authorโs original bitcoin transaction.
Websites are stored as Merkle DAGs, so all websites become tamper-evident. It solves security, trust, and distributed hosting issues of the normal web.
Nostr 2.0 is far more than DID key delegationโฆ it will extend nostr to webapps where DIDs are the URLs.
Itโs a tamper-evident web where anyone can host your website without needing to trust them, effectively decentralizing all websites with Nostr. Native apps are great too, but we have a great opportunity to decentralize the web here.
#[0]