as i am constantly pointing out, and nobody listens to me
free relays are harvesting your access data anyway. the user's own npub is the
most frequently occurring npub in all of their requests, tied to an ip address
you can't solve spam and impersonation/scammer problems by burying your head in the sand.
nostr needs better auth, for a start, nip-42 should be merged with nip-98 and on option clients should be able to open sockets with a nip-98 token and skip the whole rest of the flow
normal socket based systems require auth before they start answering any queries at all. if you intend to write data to the database, you need permission from the relay operator, and the simplest way to do this is that your npub is registered as a whitelisted user and when you connect, you just auth
because ultimately anyway you are doxxing yourself
it's pure superstitious nonsense to say that sending out signals that contain identifying codes related to you are not, all nostr use is doxxing yourself
the real solution from the user side is being able to control who you connect to, but client devs also struggle with this while spamming the channel with inordinate amounts of data and responses that identify you, to do this "decentralized" thing when paying one or three trustworthy relay operators is so much simpler, so long as you auth to them, they can control spam
and further, there needs to be a way for a relay to act as an auth proxy for you so you can just use one relay at a time, and the relay handles fanning out and caching results from your requests.
this last point is still an unsolved protocol issue as well. and a big part of it goes back to the complexity of not authing a socket at the beginning.
mleku
npub1fj…mleku
2025-06-03 07:01:15
in reply to nevent1q…zyfe
Author Public Key
npub1fjqqy4a93z5zsjwsfxqhc2764kvykfdyttvldkkkdera8dr78vhsmmlekuPublished at
2025-06-03 07:01:15Event JSON
{
"id": "59508a45d9abbdf231c1db59c1e4cea70288b377f8793415c96f3f55ed896e9f",
"pubkey": "4c800257a588a82849d049817c2bdaad984b25a45ad9f6dad66e47d3b47e3b2f",
"created_at": 1748934075,
"kind": 1,
"tags": [
[
"e",
"f571c7a3459ab8a5a02b0da29317c4f3db3e147fec92c8c1bf550034c49cf4ff",
"wss://mleku.nostr1.com/",
"root",
"4c800257a588a82849d049817c2bdaad984b25a45ad9f6dad66e47d3b47e3b2f"
],
[
"e",
"001be7df7a54590beac92a1bd0b0c91c05887e874ed39af7ddc9270e8f21a3f9",
"wss://mleku.nostr1.com/",
"reply",
"4c800257a588a82849d049817c2bdaad984b25a45ad9f6dad66e47d3b47e3b2f"
]
],
"content": "as i am constantly pointing out, and nobody listens to me\n\nfree relays are harvesting your access data anyway. the user's own npub is the \nmost frequently occurring npub in all of their requests, tied to an ip address\n\nyou can't solve spam and impersonation/scammer problems by burying your head in the sand.\n\nnostr needs better auth, for a start, nip-42 should be merged with nip-98 and on option clients should be able to open sockets with a nip-98 token and skip the whole rest of the flow\n\nnormal socket based systems require auth before they start answering any queries at all. if you intend to write data to the database, you need permission from the relay operator, and the simplest way to do this is that your npub is registered as a whitelisted user and when you connect, you just auth\n\nbecause ultimately anyway you are doxxing yourself\n\nit's pure superstitious nonsense to say that sending out signals that contain identifying codes related to you are not, all nostr use is doxxing yourself\n\nthe real solution from the user side is being able to control who you connect to, but client devs also struggle with this while spamming the channel with inordinate amounts of data and responses that identify you, to do this \"decentralized\" thing when paying one or three trustworthy relay operators is so much simpler, so long as you auth to them, they can control spam\n\nand further, there needs to be a way for a relay to act as an auth proxy for you so you can just use one relay at a time, and the relay handles fanning out and caching results from your requests.\n\nthis last point is still an unsolved protocol issue as well. and a big part of it goes back to the complexity of not authing a socket at the beginning.",
"sig": "4b3b281fc356b6c169d52b57ed857dd087b38c5ec207e321851bbe79ecb49c1b0fba332f52fa329dc4ce59699a1d156d638a95df6a4f871f802417658a71602e"
}