Nostr Web Client

Initially the 1, 2, 3 letter names could be reserved for internal use and for the 4 letters and up a donation of a certain amount of sats could be asked inversely proportional to the length of the name.

For example for 1,000 sats someone could get a 10 letters name.

And up with the same logic to get to 1 full BTC or more for 5 letters names, this could be also a smart idea to fund the project : )

Claude.ai suggested me earlier today also other possible attack scenarios:

Username Squatting:

Attacker registers thousands of popular names

Defense: Rate limiting, cost per registration, reputation system

Federation Collusion:

5+ federation nodes collude to register conflicting usernames

Defense: Bitcoin timestamp provides proof of fraud, community can fork

51% Attack on Bitcoin:

Attacker reorganizes Bitcoin blockchain

Defense: Wait for deep confirmations (6+), extremely expensive ($billions)

NOSTR Relay Censorship:

Relays refuse to propagate certain registrations

Defense: Users can query Bitcoin directly, run own relays

DNS Hijacking (if using domain):

Attacker compromises domain used for federation

Defense: Use IP addresses, Tor hidden services, or multiple domains

david 1mo ago

This is a hurdle that appears over and over again in decentralized systems: a solution that appears simple at first rapidly explodes in complexity. Which means the space of all possible protocols to implement the basic idea becomes very large. But the system only works if a large community can come to agreement on all of the details of the protocol. In the absence of a Schelling point, what’s the mechanism to get everyone to use your preferred version of the protocol over some other version?

The only solution I’ve ever come up with is WoT. First, make a decentralized list of protocols, using the simplest possible system, which is what I’ve designed Decentralized Lists to be. Next, curate the list using methods as proposed in the NIP. Lastly, hope that my WoT and your WoT and most people’s WoT will spit out the same (or almost the same) curated list. This last part I call “loose consensus” and I think it will work surprisingly well. But no one has demonstrated “loose consensus” — the act of demonstrating loose consensus would be an important milestone in the development of WoT on nostr. It might be an essential ingredient in preventing solutions like the one we’re discussing in this thread from falling apart.

I ought to write up an article on this; demonstration of loose consensus would make an excellent project for the #wotathon . (It would be an extra feature of a generic Decentralized Lists app — I do already have an article on that.)

Reply to this note

Please Login to reply.

Discussion

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1mo ago

yeah, the consensus doesn't tend to be the hard part, especially when you use WoT. but rate limiting is challenging because of the low cost of generating new keys. i'm doing a bit of a survey of mechanisms for rate limits in distributed systems that don't involve security deposits or proof of work. there must be something.

the complexity is something i also want to avoid, especially because the protocol design i have (it's based on a distributed database consensus called PnyxDB), is so simple.

oh, first thing springs to mind - to register a name, you must use it, a minimal number of times in the provisional period after registration. if the network never sees activity that reflects utilization, it can expire the provisional registration and it becomes open again, but the IP address and pubkey are both unable to attempt registration.

something like this.

i'm gonna start working on implementing this, this weekend, two things on my agenda for my downtime.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1mo ago

i also call it a "loose" consensus but actually the proper word is "weak consistency". bitcoin has weak consistency also, it is probabalistic. a WoT based consensus, like PnyxDB, where peers make trust attestations (or distrust) and distribute them so that you can use that graph to decide if that peer is near enough to your circle that it can be trusted.

oh yeah, if you never saw it:

https://github.com/technicolor-research/pnyxdb/blob/master/README.md

i've been following the guy who created this, handle is lesterpig, he is a distributed systems researcher, pnyx is the current revision of his protocol, previously he called it SporeDB.

distributed consensus designs that use Web of Trust are not common. i'd love to hear about others than this one that you know of.

david 1mo ago

Are people using pnyx?

I think my Decentralized Lists custom NIP would qualify as a distributed consensus design using WoT, if I understand correctly what you’re referring to. There are so many ways that this NIP could have been made more complex, but complexity is fatal if you want a large community to form around it. This is the simplest NIP I’ve been able to come up with and in my mind it is a primitive that can be used to build lots of more complex decentralized data structures (more complex that just simple lists).

https://nostrhub.io/naddr1qvzqqqrcvypzpef89h53f0fsza2ugwdc3e54nfpun5nxfqclpy79r6w8nxsk5yp0qyt8wumn8ghj7un9d3shjtnswf5k6ctv9ehx2aqqzdjx2cm9de68yctvd9ax2epdd35hxarnwrn9hx

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1mo ago

i think the repo refers to this or even contains it but this is the paper on arxiv: https://arxiv.org/pdf/1911.03291

it is considered experimental, and both of our proposals are also. but i'm pretty sure there is something. i'm searching now for some exampes of production systems that are based on it, or use it in any way...

Production Systems

1. Stellar Consensus Protocol (SCP) - Federated Byzantine Agreement

Most significant web-of-trust-based consensus in production

Each node chooses its own quorum set (trusted validators)

Powers the Stellar network with billions in transaction volume

First provably safe consensus with: decentralized control, low latency, flexible trust, and asymptotic security

Anyone can join; no central authority dictates membership

Introduced by David Mazières as a novel trust model

2. Ripple's Unique Node List (UNL)

Each XRP Ledger server maintains a UNL - list of validators it trusts not to collude

Default configuration uses lists published by XRP Ledger Foundation and Ripple

Requires ~90% overlap between UNLs to prevent forks

Powers the XRP Ledger with significant daily volume

If nodes don't agree with their UNL validators, the network halts (safety-first design)

3. Proof of Authority (PoA)

Validators stake reputation and identity rather than computational power or tokens

VeChain is the primary deployment (101 Authority Masternodes)

Used by Walmart China, BMW for supply chain transparency

New blocks every ~10 seconds

Transitioning to DPoS in December 2025

Also used by: Bitgert, Palm Network, Ethereum testnets (historically Rinkeby/Kovan)

Popular in enterprise/consortium blockchains via Hyperledger Besu (IBFT 2.0, QBFT)

Research Prototypes

Multiple trust-enhanced Byzantine Fault Tolerance variants exist in research:

ModET-FC & TC-PBFT: For decentralized social networks

GABFT: Uses HonestPeer++ reputation model

TV-BRAFT: Trust values integrated into Raft

PoTC (Proof-of-Trust Collaboration): For M2M/IoT applications

Key Insight

While traditional consensus algorithms (Paxos, Raft, classic PBFT) dominate general distributed systems, web-of-trust mechanisms have found significant adoption in blockchain/DLT contexts where decentralized trust is essential. SCP and Ripple's UNL are the most mature implementations with real economic value at stake.

-----

i know one of the people who were working on VeChain back in the day, but i'm very hostile to monetary token based solutions. however, the info is clear, there is systems already running in production for a long time that have a strong WoT based component in them.

so even though it's "experimental" if the protocol seems like it might work, we should try to run it and see if we can at least get a network with a few dozen nodes or more and see how it works. nobody can use a system without a system to use.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1mo ago

the fact stellar uses a similar thing with assigning trust values to validators seems very pertinent. this network has managed to keep running for a very long time. it hasn't succeeded in acquiring a large userbase, however. but it clearly is secure enough that the protocol is still operational.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1mo ago

oh yeah, Steem (and hive) are specifically social network related but they are proof of stake, trash from that Dan Larimer Bytemaster guy. but their consensus is stake based, the stake is delegated by users voting for them.

i think it's worth taking a shot at building one and since you and I both want to do such a thing, it would probably be productive to continue a dialog, if you are interested, as it really depends on enough users to actually prove the concept.

david 1mo ago

I def want to build a system of distributed consensus using WoT — and a neo4j nostr relay will be a very useful step in that direction!

If you like, I can propose a schema for this. (Brainstorm doesn’t need a fully functional neo4j relay — it can make do with a much more restricted schema as described in my docs, at least for now — but a fully functional relay would be awesome and is def worth doing. Nothing like going above and beyond!)

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1mo ago

david 1mo ago

Cool. Will work on it probably tonight and let you know when it’s done.

david 1mo ago

I can see two ways to go about it.

The first way would be to store the entirety of the data, including content fields, inside neo4j. I guess this would be the “purist” way, but events with lots in the content would eat up memory.

So the second way would be to omit content (and sig) properties from neo4j (with perhaps some exceptions, like kind 0 events), the goal being to reduce the amount of memory required for neo4j. In this method, we would view neo4j as an adjunct to a non-graph database, which could be relational, KV, etc, which would store each event in its entirety.

Perhaps I’ll design a schema for the purist method first and we can switch to the second method if/when bloat becomes too much of a problem.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1mo ago

https://git.nostrdev.com/mleku/next.orly.dev/src/branch/main/docs/FIND_RATE_LIMITING_MECHANISMS.md

this lists a number of options that have been used somewhere or discussed previously. a few of them might work. as i see it the main thing i haven't covered in the design is that initial bonanza problem.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1mo ago

yes, also, name->npub registration has been added to my design, in addition to all the standard DNS records. the idea would be that aside from the connectivity to the data source, it would be functionally equivalent to BIND

david 1mo ago

I share your hostility towards monetary token based solutions. We need a WoT system that people will use and that does not rely upon shitcoinery.

btw I sent you some DMs (from Damus) — not sure if they’re going through; if not should I use coracle maybe?

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1mo ago

coracle properly supports nip-44, and it already worked before with the nip04 messages we have exchanged. so, yeah.

Fabulous Mindset 1mo ago

The "Decentralized ID" Merkle Root would become the anchor or the immutable peg for a certain WoT network, because networks are dynamic and I keep going back to thinking about the need of a timechain to anchor their legitimacy...

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1mo ago

it needs a consensus. doesn't have to be a blockchain database.

i'd like to refer you to the Stellar XLM shitcoin, and the Ripple XRP shitcoin. both of those are built with a consensus that in part uses web of trust. they might be shitcoins, but they are more secure than proof of stake.

with nostr, we have a network of databases that can be used to store consensus state, and help connect nodes in the consensus protocol. we have a social graph which is extremely rich in information, that can be used as part of the decision process to eliminate bullshit from poisoning the database.

i seem to be one of the few people on this protocol with even second year CS distributed systems theory. i guess it falls on me to demonstrate it because none of y'alls understand enough about it to get it, and hey, someone's gotta do it.

david 1mo ago

I just read up on the stellar consensus protocol (SCP).

Allow me to rephrase the basic idea with as little terminology as possible; tell me if this makes sense to you.

The basic idea is that if I want to answer an arbitrary question (which could be anything: is this a valid transaction? What’s the best coffee shop in Prague?) then I pose this question to my WoT, collect everyone’s answers, and select the winning answer based on the consensus of my WoT.

SCP is obviously a very specific application of the above basic idea. What if I want to apply this same idea to a completely different specific use case — like selecting the best coffee shop in Prague? How do I take the preceding paragraph and state it as precisely as possible but also in the most *general* terms as possible? This is the problem that I’ve been turning over in my head for over a decade.

We would need a well defined method to represent the space of “all possible questions” (or at least a very very large class of questions) as well as a well-defined method to answer any given question. What would be the primitives for this method? In my mind, decentralized lists and personalized, portable, contextual trust metrics are two of the most important primitives. Decentralized Lists is how we define a question (to ask: what’s the best coffee shop in Prague, you start by defining a decentralized list of coffee shops in Prague) and trust metrics is how we answer the question (as discussed in the NIP). If my WoT and your WoT and lots of people’s WoT converge on the same answer, we have a method that is not only widely generalizable, but more importantly one that is useful.

https://nostrhub.io/naddr1qvzqqqrcvypzpef89h53f0fsza2ugwdc3e54nfpun5nxfqclpy79r6w8nxsk5yp0qyt8wumn8ghj7un9d3shjtnswf5k6ctv9ehx2aqqzdjx2cm9de68yctvd9ax2epdd35hxarnwrn9hx