Silberengel @Silberengel - 4mo
RUN THE MAILBOXES FROM THE RELAYS.
Here's why this is clever: * Relay devs and full-stack devs care more about spam prevention and data quality than only-client devs do (sorry, not sorry, painfully obvious), so have them do it. * Raises the usefulness of relays and opens a market for more relay development. Full-stack devs can tap into this by having relay selections/options that work well for their clients. * You can set up 1 or more relays to contain the specific configuration you want (or your community or company wants, etc.) and then use them from any client, with no further configuration * You no longer need follow or mute lists; global is great again. * Every relay admin (which will eventually be everyone) controls their own model, which makes switching clients easier * saves bandwidth (except for localhost relays) because the client only needs to communicate with one relay, at the same time as the events are spread to many different relays * you can develop custom criteria for accepting new npubs to the relay, to keep out spam * you stop loading crap into your client and then immediately filtering it back out or hiding
And then add negentropy syncing and you're done.
Niel Liesmons @nielliesmons - 4mo
🌍 🔫
🤣🤣🤣🤣💯
Use Kind 30078 to save relay subscriber's settings, would also be clever.
And the relays could collect new npubs in a waiting room and examine them, before allowing clients to pull that data. That keeps newbies from being locked out, while preventing spam.
They already do this with LN fees, but the could use the waiting room function for any trust-test, like checking the NIP-05, checking attestations, checking community membership, etc.
They can do whatever they want, without every client having to be compatible with what they're doing. They do need a way to communicate what they're doing / asking within the client. That's where I'm stuck now. Any ideas? (I'm recording a vid to show what I mean)
nostr:nevent1qvzqqqqqqypzplfq3m5v3u5r0q9f255fdeyz8nyac6lagssx8zy4wugxjs8ajf7pqydhwumn8ghj7argv4nx7un9wd6zumn0wd68yvfwvdhk6tcpr3mhxue69uhhg6r9vd5hgctyv4kzumn0wd68yvfwvdhk6tcqyzzz3ym56d9dqeukgqmvqpdl9xermy95y2ugskca2r6lrg707ejnz3lczqc
Use relay-generated events.
There's this Catholic principle of subsidiarity and I think it applies well to system design. Every decision should be made at the "lowest" possible level possible, to keep the system innovative and efficient.
And ephemeral events.
Absolutely! If you think of each level according to the person fiddling with it, it's easier to decide which level should focus on what.
