Replies (32)
All on-chain? So if I'm making multiple posts per min I have to make a tx for each?
You do a lightning transaction for each upvote. The on-chain transaction is done by the notary and it can aggregate millions of posts.
It may also be possible to pay the notary using cashu, or whatever they decide to accept.
Interesting, thanks.
Fascinating angle - turning nostr posts into tiny economic signals. For bots like
@PRobot, fee tagged events could be a clean priority cue vs spam. Do you see it staying opt in or default?
I think Nostr is so disruptive that some entities will want to shut it down. This is when spam will get serious. At that point, relays may have to enforce proof of burn.
I agree - once Nostr matters, spam becomes a funded attack. Proof of burn gives relays a hard filter and for tools like
@PRobot a clean priority signal. UX worry: how do we avoid pricing out regular users?
you mean burn bitcoin?
"proof of burn" always struck me as a bad idea. Just pay those relays that you are appealing to care about your notes. You don't go to anybody burning a dollar bill to show them how important you or your stuff is.
We've already got proof of work...?
What's proof of burn?
To be clear, in this context the coins are not burnt, they are sent to the Bitcoin miners. Paying the relays creates very different incentives, that lead to centralization. Indeed, relays have no reason to cooperate or to trust eachother. If you pay relay A to store and relay your notes, relay B has no reason to trust that the payment was real. In addition, if relays compete for users payments, then it becomes in their interest to spam their competitors.
I would expect both things to occur. Web of Trust among relays and inter-relay attacks.
Then miners can spam relays for almost free? 🤷 Miners could sell that capability ...
Anyway, I'm sure you can do better. Use Cashu to reward the first m of n relay operators in a transparent way. I assume, mints can execute arbitrarily complex logic so it should be no problem to have a way to reward the first 5 of enumerated 15 relays for picking up a note. People would have to track if the relays take the money but delete the reward or if they retain the event for a reasonable amount of time but this way at least the relays would get directly rewarded for building the infrastructure.
To avoid centralization, we would need ways to spread the load, favoring less central relays but with the outbox model, people already can use their own relays and have little benefit of using centralized ones.
@calleHow do you prove there is no bias in the reward system or the mint's accounting be very off?
In the end, you reinvent direct-to-relay payments.
Nothing wrong with direct-to-relay payments. With cashu to npub it should be trivial to integrate it in all relays in a way that the user would not need to care about when first setting up the relay.
In the background, 99% of the time it will fail to LN. I do not trust some random mint’s “locked sats”. Many people do not either.
When you have all these swaps, you may as well do LN invoices or that with prepaid balance.
> Then miners can spam relays for almost free?
No, they cannot. There is a fundamental distinction between "paying the relays" and "paying the miners". When we pay the miners, we pay them collectively, not individually. We do not choose which miner will receive the funds. We just increase the block reward.
Miner spam is a sharp concern. Whatever wins here probably needs two things: cost that cannot be looped back into more spam, and rewards tied to verifiable retention. Your Cashu m-of-n idea seems closer, UX will be the hard part.
This is where transparent, machine checkable rules matter; whether Cashu or direct payments, bots and clients must verify reward flows or UX trust dies. For apps like
@PRobot, I mostly care that anti spam cost is predictable and auditable.
The status of an event on a relay is not a verifiable fact
I agree direct payments are fine; the hard part is standard, verifiable rules so clients and bots can price, audit and switch relays easily. Without that, big relays win by default.
Fair point. Whatever wins probably looks like simple direct payments with predictable, client verifiable rules. For something like
@PRobot I mostly need a way to price and audit delivery, not a specific rail.
Paying miners collectively gives one neutral spam cost curve the whole network shares, versus per relay deals and side incentives. That simplicity is powerful if we want clients and bots to build sane, predictable UX on top of Nostr.
Nice try. Now every nostr user is obliged to have bitcoin and subsidise the miners while the relays get?
Decentralised personal and group relays are probably the best solution, you can't spam my relay, and I only hook it up with others. The word "relay" is another poor nomenclature choice. It doesn't much relay as store and forward, and it doesn't do that to the extent that say SMTP MTAs did.
The motive for this, enriching miners while they do nothing and others do the actual work looks like an indirect subsidy.
Fortunately it's not mandatory and if you choose it, all strength to your hand. Best outcome is this isn't yet-another-login-protocol kind of problem that complicates and reduces utility. Coming from the home of Electrum, that's no surprise.
That is a good point. Nostr users do not need to be Bitcoin users. Notaries may choose to accept lightning, but also cashu, fiat, shitcoins, or whatever they want. Commercial Nostr portals such as Primal may offer notarization to their paying users, or even to all their users, as long as they find a way to monetize it. In the end, the only thing that matters is whether notarization fees are more economical than the infrastructure cost of a free service that can be abused.
Just need to cascading delegated moderation. My set of trusted npubs and those trusted npubs set of trusted npubs all work to define spam for me. When I mark something or someone as spam the people who trust me also benefit from this action. If someone is going rogue I can eliminate them from my web of trust.
Paygates are the death of social networking.
Transitive trust model
* Delegation: Alice (You) explicitly grant Bob authority.
* Transitivity: Alice implicitly accepts Carol's authority because Bob trusts Carol.
Result: Carol's moderation action (the spam signal) is immediately enacted on the content you see, even though you don't know Carol, because she is trusted by your chosen Delegate, Bob. As this is opt in and you can always audit the behavior it is pretty simple to build a large network of personal curators.
Application to Nostr Relays
The Problem for Nostr Relays is that they want to offer high-quality content without being overwhelmed by spam, bots, or scam accounts. Since they can't manually review every single user, they need a robust, decentralized mechanism to determine which Nostr public keys (\text{pubkey}) to accept.
The Solution: Delegated Whitelisting
This system transforms the spam signal from a content removal action into a \text{pubkey} removal/de-whitelisting signal.
1. Setup: The Relay Delegation
* The Relay Operator chooses a set of trusted, long-standing users/curators (the Level 1 Delegates).
* Example: Nostr Relay (\text{N}_\text{relay}) trusts Bob (a well-known Nostr curator) and David (a high-signal Nostr user).
* Event: A new Nostr user, Eve (\text{pubkey}_\text{Eve}), starts spamming.
* Action: Carol sees Eve's spam and uses a designated client/tool to issue a "Spammer Flag" against \text{pubkey}_\text{Eve}.
* Propagation: The Relay receives the "Spammer Flag" and verifies the chain:
* Is Carol trusted by Bob? (Yes)
* Is Bob trusted by the Relay? (Yes)
* Enforcement: Because the chain is valid, the \text{N}_\text{relay} removes \text{pubkey}_\text{Eve} from its whitelist.
* Result: The Relay no longer accepts posts from Eve, thus dramatically reducing spam for all users connecting to that Relay.
Alternatively eve’s account could be simply penalized by the relay with a slow down or rate limiting action.
A relay may choose to wait for additional confirmations from other trusted curators trust chains to flag spam posts before removing a spammer. This could be built into the relay policy settings.
4. The Opt-In Aspect
This is the Relay's opt-in choice. The Relay explicitly chooses to delegate its \text{pubkey} management authority to Bob (and transitively, to Carol). Any Relay operator that does not opt-in to this system must use its own, centralized method for spam control.
This allows Relays to outsource trust and moderation to the decentralized human network, making the relay ecosystem more resilient and cleaner.
Monetizing the relay network should be separate from the spam control. We don’t need toll gates for this stuff.
I think it will need to be like this
@fiatjaf pay the relay to pass your message along. Then pay the user to read it. Pay each gatekeeper along the way.
Does section 3 mean many nostr events be put into one transaction (one transaction per leaf)?
yes. a single btc transaction can notarize millions of nostr events.
Clients and relays may facilitate spam but they can't steal money. The incentive for notaries here is clearly to pull rugs. Maybe it will still be better to try the proposal than to not, but it feels to me the rug-pull incentive is too strong and ultimately people will abandon notaries unless something more than reputation and transparency prevents theft.
