Nostr Web Client

Dms are good, so are images, stop being a misery guts.

main obstacle to a practical implementation of DMs on a network of intermediaries like nostr relays is not really any different from any other thing. you can do MLS using ephemeral events, as one way, though it has scale limitations, the way that doesn't is where relays enforce privilege to restrict reading private events to authed users.

i have been hammering at this last point for the last 2 years but nobody seems to listen to me. fortunately, my relay implements it and there is a growing number of users who have in mind private network deployments that can also be easily bridged to open public access as well as respecting the confidentiality of the operators of this network.

the liveness problem of private communication for methods like MLS make it a lot more challenging than it would be with a dedicated protocol, and i just think that the lack of DM support is the number one thing retarding nostr adoption.

Reply to this note

Please Login to reply.

Discussion

JOE2o 1mo ago 💬 2

Nostr was never conceptualised for DMs. If you trust the concept for something then use it for what it was conceptualised for.

DMs add a need for assured delivery that wasn't there before

DMs add a need for encryption that wasn't there before

Encryption adds a need for derived identities that wasn't there before

Encryption adds a need for nsec hygiene that wasn't there before

Nsec hygiene adds a need for remote signing that wasn't there before

DMs add a need for relay specialisation that wasn't there before

Relay specialisation adds a client UIs that wasn't there before

The list goes on and on.

DMs are a trojan horse, let them in and soon the city gates are open for an horde of barbaric complexity to march through.

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

the majority of non-competent distributed systems and game theory talkers who get all the airtime on this protocol don't actually understand either game theory or distributed systems.

here's some hard fax:

fully anonymized, private direct messages can only be coordinated over an anonymising proxy, with ephemeral messages, and thus have a huge problem with asynchrony and there is basically ZERO consistency to the data on the network.

every security and privacy (a form of security policy) system has tradeoffs. the great holy grail of these uneducated, uncreative folk who say nostr can't do secure private messaging, is a type of privacy protection that is essentially a form of deliberate amnesia with a zero time window.

the biggest disagreement i have with this idiotic view of what must be in place for nostr to implement this, is this:

nostr's middleman, rendezvous architecture is designed for asynchronous messaging. but it can also do synchronous messaging through rendezvous, and solves the NAT routing problem that persists for anyone wishing to do p2p protocols from their home connection.

nostr solves that problem.

now go back to all these supposedly "private" protocols.

NAME ONE THAT DOESN"T INVOLVE THEM CACHING YOUR MESSAGES ON THEIR SERVERS!

not one of them. simplex, signal, matrix, telegram, whatsapp. all of them basically have relays in them.

so, what was that you were saying?

are you saying i can trust Signal Inc. more than i can trust my friend in germany?

JOE2o 1mo ago 💬 1

I've no doubt that cryptographically-signed JSON events on websocket relays can form the basis for many neat things.

As for Nostr, we have a long list of nostr protocol DM implementations (and nostr-inspired other protocol DM implementations). We can add to that long list, but for what?

Nostr doesn't have a mechanism to sort this all out. There's no Supreme Court. There's no Jedi Council. It's XKCD 927 all the way down.

1. All solutions to the DM problem require widespread cooperation

2. Widespread cooperation at this stage is effectively impossible

You see the meaninglessness here? If there is nobody to clean the wall then the moment you allow people to start throwing spaghetti at it it's over.

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

i don't think so.

i can store privileged messages on my relay already right now and nobody authed to a pubkey that doesn't appear in my privileged message p tags can read it.

i also have automatically configured relay whitelists that grant write access to anyone i might want to have an ongoing DM with.

the only thing holding this up from working is a client that lets you configure it correctly to push events there correctly according to what i have configured. the rules for defining that, are not complex, and currently, almost no nostr clients implement this part of the protocol correctly. everyone loves their chosen single kind 1 client, with half arsed DM support, or irritating high friction like coracle, which works, but nags you without option to disable the nag that you are using nip-04, which btw, is not actually in practical terms any less secure, but is also a lot faster because everyone has AES acceleration even mobile users, a cipher stream algorithm that is standing up perfectly well to attacks everywhere on the internet over TLS.

because of this downer negative pessimistic attitude, promoting the ignoring of this critical feature of a social network is the norm, and nobody has actually spent enough time to fix it. that is all.

so it's a self fulfilling prophecy when you parrot these dictums about nostr "not being made" for something.

perhaps we should talk about the fact that humans are "not made" for any specific thing either, yet can do many many more things than your little short circuit evaluation gives you.

JOE2o 1mo ago 💬 1

I don't think it's a downer attitude or a self-fulfilling prophecy. It's just the physics of human nature and governance (or lack thereof).

If you're designing a building you're not being a downer if you take into account gravity, you're not being pessimistic if you inform someone that their proposed balcony design just can't be built.

You won't get this new standard widely adopted. It sounds really well thought out and could be the basis for a personal or other fork. But you won't get a critical mass of clients and relay operators on board. Nobody will at this stage, for any such proposed standard, no matter how well thought out. We've simply reached a stage where (a) all we have is lobbying and (b) no lobbying effort will ever be enough.

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

"it can't be done" is a red flag for an inventor, which you are not.

all i'm hearing from you is "this other bunch of people said this and i'm too stupid to think any more about it because they save me from the pain". pathetic.

JOE2o 1mo ago

Here's what I'm assuming is the end-game you're picturing.

-All clients converge on this one DM standard over time

-Other standards effectively get weeded out, not to be seen again

-When someone on nostr says "send me a DM" it's always gets sent this one way, and this one way always works.

Or are you picturing there always being competing and non-interoperable DM standards? A sort of ice cream buffet, choose what you like?

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

in government statute books, there is always a preamble which states the aspirational result of implementing the law.

a bit like the aspirational preamble that you all have accepted as the premise of nostr.

meanwhile, the lawyers pore through those things, and with enough time, will find a way for you to break the law without breaking the law.

the same applies to nostr. what you think it is, is one thing. what it actually is, is something a bit more complicated than this uneducated faith in the preamble of a body of rules.

that's why we don't have DMs still. because y'alls don't understand what the protocol allows. same goes for name/npub mappings and namespace registration. nostr protocol is not a complete distributed system. it's lego bricks for foundational components.

you have to use your imagination and logic to see whether or not it can protect privacy adequately. most of it falls to the lowest rung of dev skill in architecture, the client devs, and idiot projects like primal promote these guys in front of us relay devs, who actually have at least one level higher knowledge of how this works.

you should be listening to us, and working with us, instead of pretending that relays aren't important.

or you can just go back to mastodon or bluesky or x and get off my lawn.

Ben Arc 1mo ago 💬 2

What are you talking about?

Nostr had dms very early on, and is incredibly useful for things like a marketplace where customers need to dm merchants.

Your being a technocrat

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

I am so pleased to read this from one of the original designers of the protocol.

JOE2o 1mo ago

I'm coming at this from the angle that nostr doesn't have to be an everything app, and indeed the more it tries to be one the more it loses itself.

Ben Arc 1mo ago 💬 1

Just make a simple client, if that's what you want, but I cant see how limiting protocol makes sense.

JOE2o 1mo ago

It depends what you see a social protocol as. Before nostr we had signed json events on websocket relays. Then we had nostr. And now we are more or less back to signed json events on websocket relays.

For me a social protocol is a set of guarantees. Not perfect guarantees, mind you, but still, strong ones. A guarantee that if you add a relay it'll work, just as any other relay. That if you write a note it'll get shown just the way you wrote it.

The vision for nostr, as I understand it, was a very limited number of quite strong guarantees. But now we're back to a space with so few guarantees that we can more or less say we have no guarantees. When people talk about nostr now, they're often actually talking about signed json events on websocket relays, the thing we had before nostr.

Relays are not guaranteed to work, for whatever thing you're trying to do. DMs are not guarantees to be sent to who you send them to. Media are not guaranteed to load. Sing-in methods are not guaranteed to be supported. The list of guarantee-less and guarantee eroded things goes on.

Does this mean signed json events on websocket relays are bad? No, they work great as an alternative to APIs, and much of the tooling for this that's come out here is great.

But it's gone from being a social protocol that your average social human being can wrap their head around to being a sort of devkit for json events on websocket relays, and my take is that this is a bummer.

Making a client for more constrained things doesn't work. Any client would suffer from the current lack of guarantees. We're at the point where if a dev wants those guarantees back then at the very least a soft fork is needed.