Nostr Web Client

https://decrypt.co/resources/how-to-use-ipfs-the-backbone-of-web3

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.

“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.

teatwo 2y ago

I'm very interested in Nostr 2.0.

But did:nostr is different

from ION, isn't it?

it is yep. did:nostr only uses nostr. dids are resolved by relays

#[6] imo, the primary benefit of ION is the censorship resistance provided by the anchor to Bitcoin.

Operationally, the lift to run an ION node is probably too high for most to consider actually running one primarily because of how tough it can be to run a reliable IPFS node. Given the high barrier, i feel that the likelihood of there being many ION nodes to choose from is low. 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.

Generally speaking, i think reducing the # of intermediary servers/nodes that have to be relied upon to resolve a DID is the best path forward because it decreases the likelihood of getting tricked (e.g. your example an ION node tricking a user) or being censored.

If there have to be intermediary servers/nodes in between, the hope would be that running that server/node is dead simple / ezpz as a means to increase the likelihood of many people/businesses actually running them. people already don't want to run servers so the barrier is already high.

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.

Mike Brock 2y ago

Wait. Wouldn't you have to possess the private keys used to create the ION ID, since the ID is a hash of the in initial state, signed with the privkey. How do you carry about the Sybil attack with that being the case?

That's not how creation and ownership of ION IDs worlds. You cannot attempt to create/own the same ID as another person, because the ID itself is entirely generated by the initial state of the IDs PKI (including the keys). This cryptographically secure, unique, immutable means of creating identifiers is know as a 'self-certifying inception event'.

Because all data related to DIDs in ION is DID-relative, and you cannot Sybil/own another person's IDs, your routing and data URLs are not susceptible to the type of issue you are describing.

*works

Part of your confusion seems to stem from the idea that IDs are something you can register like an ENS/DNS name, wherein different people could end up with a string attributed to them. ION specifically removes this whole class of issues due to its self-certifying inception event for creation of IDs, and it's non-transferability properties.

To own or take someone's ID string, you'd literally need to take control of their current recovery private keys, you can't Sybil your way to that.

I think the point #[2] is making though is: “an ion node isn't giving me any proofs that i can use to verify the legitimacy of a response" (definitely correct me if I’m wrong Colby)

if i send a request to an ION node to resolve a DID for me, what proofs are provided alongside the resolution result that would allow me to do any integrity checks?

Without these proofs, an ION node could just lie to me about the contents of a DID Doc and I’d be none the wiser.

an example that isn't ENS would be a DWeb Message or a Nostr event. they're independently verifiable. i can immediately do a sigcheck clientside and know whether the message/event is bunk.

it seems like ION node does have these proofs because they’re required in order to anchor a DID (e.g. self certifying inception event). it just doesn’t return them currently.

If they were returned as part of a resolution result (or could be requested separately) a client would have everything needed to verify legitimacy I think.

Or is the expectation to run your own ion node if you want to verify? Which is a significantly heavy lift

You could certainly get proofs from ION, as it contains all the data for them, but just hasn't been implemented yet. The issue with literally any construction, even L1 blockchain ones, is that you really must run some sort of light node to avoid Tip - N state issues.

TLDR: anyone who says "I can provide a non-interactive proof of current state for a mutable record in an oracle without consulting said oracle", is trying to sell you magic beans, because that is quite literally impossible.

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.

Hafeez 2y ago

Where is Nostr 2.0 being discussed? Any links/podcasts etc?

Crickets when there’s a chance for unity, tons of dialogue when there’s a chance for battle. 🦗 Does anyone have any comments? 💭

Tamper-evident websites that are decentralized atop bitcoin could change the world. 🌎

Running an ION light node (a configuration that's provided for in the system, but has yet to be coded to provide) reduces the resource requirement by ~95%, making it feasible for users to run on most devices.

jb55 2y ago

👀

SMS 2y ago

At the enterprise, after a few synthahol cocktails River goes to Picard, hey, did Data have to do an interview to get into the federation?!

Max 2y ago

Interesting, why double hash the recovery pubkey?

I though that there's no good reason why Satoshi put double hashes everywhere...

Heyo, great question. My rationale behind double hashing the recovery key commitment was to prevent against length extension attacks.

I’m not a cryptography expert though so there’s a possibility that double hashing might just be unnecessary complexity. Would be awesome to know for certain

Max 2y ago

I'm out of my depth here, but doesn't even a single hash hide the length of the input?

Summoning a wild #[5] to clear things up 🖤

In the meanwhile, here’s ChadGPT’s take:

waxwing 2y ago

Yes but as I said, this is fixed length data - a secp256k1 pubkey. LEA applies to the scenario where you're trying to check the authenticity of an arbitrary length string that is authenticated with a secret. I don't think it applies here, nor in sighashing, nor in standard hash commitments.

waxwing 2y ago

AFAIR LEA aren't a concern here. The classic example of a LEA attack vector is a badly designed HMAC in which the data to be authorised is appended *after* the secret key. Then you can add more data that is erroneously authorised. For a commitment to fixed length data this doesn't apply.

Haven't looked it up, but I *think * that's right.