Nostr Web Client

#[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.

Colby Serpa 2y ago

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.

Reply to this note

Please Login to reply.

Discussion

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?

2y ago

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.

2y ago

*works

2y ago

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.

2y ago

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.

moegrammer 2y ago

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

2y ago

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.

2y ago

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.

Colby Serpa 2y ago

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?

Colby Serpa 2y ago

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