Spam is always a problem in open protocols.
We must prepare ahead of the issue becoming critical, learning from previous protocols.
You could use different colours to shade out "npub" string, too.
Why "npub:1abc..." instead of "npub1abc...", if I may ask?
There's also:
It will also be very useful privacy-wise, as relays won't get your client IP as you change location (ie. on a mobile client).
It is indeed.
And everyone understand the meaning of it.
It's not an absolute definition, true, but it makes no sense to look for it in Nostream code, imo.
We'll see what are the nuances of #[3] 's spam definition as times goes.
That it's not coded in Nostream code.
It will depend on each relay admin and Code of Conduct, I suppose.
Regarding #[3] 's relay, the Terms are on the website: https://eden.nostr.land/invoices
We will see how it's applied as it goes.
#[3] 's relay spam-free feature is based on the assumption that spammers won't pay 5k sats per pubkey to write events on it.
As soon as a pubkey is sending spam, it gets out of the whitelist.
It doesn't scale to spam from lots of pubkey, as the costs increase.
As far as I understand it, of course.
Paying relay has come:
note1lvhse594x4tmejzmu2e5xr2vgs7eq7sxf952zjz64g7nnwcpqxtqfv8uwn
Gossip #nostr client.
Tricky question. 😊
We will see how spam is fought, but I guess it could be with a mix of pow, pay-to-post relays, and friends-of-friends web of trust.
So, valid signal would be a mix of likes with minimum pow, likes from certain relays (paying), and likes from your web of trust.
But nobody could be certain how this will evolve.
Likes are so easily gamed.
Not a valid signal, imo.
The only thing unique is the keypair (pubkey+privkey).
Here you have some instructions to install and run Rana:
Not that I know of, sorry.
Delegation could be useful, because you can sign with a key on behalf of another one.
But it's not the 'upgrade' you are looking for.
You can use Rana to generate a *new* pubkey (& related privkey, ofc).
This would be a different keypair of your current keypair.
You can later *delegate* signing rights between new and old keys, if you want. (NIP-26)