@hoppe2
hi
Relays (3)
- wss://nostr.hoppe-relay.it.com/ – read & write
- wss://nos.lol/ – read & write
- wss://relay.wisp.talk/ – read & write
Recent Notes
most usful nostr app
Would it be better if Bitcoin was "completely confidential"?
Let's skip the "shitcoins" debate. Would it be better if Bitcoin was "completely confidential" ™️?
Assuming it was like that from the...
I also left a comment there — beyond privacy and the risk of state attacks, there's one more thing worth weighing, and it's why I voted no: scalability, or maybe more precisely how easy it is to build a layer 2. It isn't mathematically proven, but looking at the tech we have so far, getting scalability, ownership and privacy all at once looks impossible. And if we have to give up one of the three, it should be the last one. Because privacy can be recovered at a higher layer
Spammers have pennies of sats too
Thinking about it, the core of reply spam is the asymmetry: posting a reply just once gives it unlimited exposure, so charging a very small fee wouldn’t help much. Why didn’t you tell me this before I built it? I wasted my tokens for nothing 😂
❤️1
Today I completely solved nostr's spam problem. The link below is a demo web client and relay you can try out — a pay-per-reply concept where posting a comment costs you 1 sat.
https://npub1pt4qwkcpp76et45pfatrxqywsuxh0gky84xa592yapesuqye29zql4eera.nsite.lol/
This page is a plain nostr client (it follows the outbox model properly) that shows the 5 most recent notes from one hardcoded account. That account has exactly one inbox relay, and that relay charges.
Connect NWC and you can actually leave a comment, paying 1 sat for it. No login — comments are signed with a throwaway key. It uses ecash, so you need to top up 100 sats to start, but once you're done testing you can sweep the whole balance back to your own lightning address (2 sat fee).
If NWC supported keysend, no top-up would be needed and this could be genuinely pay-per-reply. But it doesn't, so there's no one-way push payment — doing it over lightning would take two round trips, which is why it's ecash instead.
I’m not a professional relay operator, and the relay isn’t optimized, so the connection may be somewhat unstable. Thank you for your understanding.
2
Better in theory but in practice not everyone will follow or agree what the standard is
That’s true—it was an unrealistic hope.
1
Gm,
Thinking of removing the hard coding of primal relay in wisp.
Currently it's hard coded in many places because primal doesn't outbox.
I don't think this would influence primal, but it would gi...
If everyone followed the standard, things would work with a reasonable amount of effort. But once we start relying on nonstandard behavior, it may be convenient in the short term, yet it eventually becomes the de facto standard. Wouldn’t it be better to avoid using hardcoded relays?
1
I’d like to ask something I’ve been curious about for a while.
For a Nostr client that respects the outbox model, when fetching the replies to a note, it wouldn’t retrieve them from some arbitrarily hardcoded relay. Instead, it would find the note author’s inbox relays and fetch the replies from there. The note itself, of course, would be fetched from the author’s outbox relays.
That much seems obvious, but what happens with replies to replies?
Does the client fetch them **only** from the original author’s inbox relays, or does it also look up the inbox relays of the authors of the replies and fetch them from there as well? And as more replies are added, does it keep looking up the inbox relays of each new author and continue fetching from those relays?
If all Nostr clients followed the standard exactly, the former approach should be enough to find everything. When posting a reply, a client is required to tag every `p` tag from the parent note, so the author of the root event would also be included. That means the root event author’s inbox relays would be among the broadcast targets as well.
How is this usually implemented?
For a Nostr client that respects the outbox model, when fetching the replies to a note, it wouldn’t retrieve them from some arbitrarily hardcoded relay. Instead, it would find the note author’s inbox relays and fetch the replies from there. The note itself, of course, would be fetched from the author’s outbox relays.
That much seems obvious, but what happens with replies to replies?
Does the client fetch them **only** from the original author’s inbox relays, or does it also look up the inbox relays of the authors of the replies and fetch them from there as well? And as more replies are added, does it keep looking up the inbox relays of each new author and continue fetching from those relays?
If all Nostr clients followed the standard exactly, the former approach should be enough to find everything. When posting a reply, a client is required to tag every `p` tag from the parent note, so the author of the root event would also be included. That means the root event author’s inbox relays would be among the broadcast targets as well.
How is this usually implemented?
Good morning,
Glm 5.3 flash is no joke an approaching endgame level intelligence that you can realistically run at home, especially with these new Mac studios
Re: cost, think of this
If a landsca...
Bitcoin is so cheap right now that I can't afford to buy anything else, but once it breaks its all-time high, I'm planning to buy a new computer. It would be perfect if computer prices crashed at that exact moment.
❤️2
Let me say it clearly:
The only way to fix reply spam is for people to use inbox relays that filter spam.
Clients then should read replies by default only from people's advertised relays.
Finally, ...
Considering both that spam needs to be blocked and that relays need revenue to keep operating sustainably, charging a small fee (around 1 satoshi) when publishing a note to a relay seems like it would satisfy both perfectly. But precisely because it satisfies both so perfectly, isn't there a really high chance it becomes a relay where nobody can post anything at all?
Should the relay operate a mint, with notes attaching ecash when they're published? Since there will be cases where people specify too many inbox relays, maybe only include it in a couple of the inbox relays?
Would there be absolutely no one willing to pay to post a shitpost? Would client complexity go up too much?
Should the relay operate a mint, with notes attaching ecash when they're published? Since there will be cases where people specify too many inbox relays, maybe only include it in a couple of the inbox relays?
Would there be absolutely no one willing to pay to post a shitpost? Would client complexity go up too much?
1