Nostr Web Client

they should also try to sell something or have a customer relationship so they realize how stupid nostr DMs are.

i'm going to fix this without the cooperation of rockstar client devs by creating an extended "privileged event" processing scheme where the relay will recognise a tag on events to mean that only the author and tagged npubs can fetch the event.

with that, i will be able to make "only visible to you" messages that put the communication from the relay (or anyone) right in your kind 1 feed. the limitation will be of course that the relay has to support this kind and respect the privilege but it works around the customer communication problem.

i'll be implementing it as part of a system to automate relay subscription such that the user just zaps the relay npub and it then publishes a message internally that your kind 1 client will fetch (so, you have to follow, and then zap the relay) and voila. customer comms problem solved.

since i started working with you, i swore that i would build a relay that would be so compelling that you would adopt it for your infrastructure. it won't be much longer now.

i'll also be learning front end dev in the coming weeks as i'm going to get paid to do it for a while. so probably i will add a full UI that is returned when you request to the / with a normal browser request (and thus also visible in nostrudel's relay UI tab).

Reply to this note

Please Login to reply.

Discussion

cloud fodder 4mo ago 💬 1

this all sounds nice, I've prob spent too much time in my self-built UI prison lately and it made me curmudgenly today. need to step back and reset ..

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 4mo ago

yeah, the "easy" solution is UI but it doesn't integrate neatly with the clients, at all. that was how i came up with the idea. no extra wingdings or widgets required, it can all be done on the back end, with the things that client devs *have* implemented.

and you know very well the reason why they have not implemented DMs properly is because they all have superstitions that you can have a relay based architecture while making it zero trust. ridiculous. of course you have to trust the relay operator. further, you can BE the relay operator yourself, but this is a high bar to enable general use, so ultimately trustworthy, honorable relay operators are needed to bridge the gap.

we aren't going to get feted for this, but who cares. the satisfaction of doing what is required for your customers is a much better and more intimate reward.