It's solvable over the course of, what, two years, with a big lobbying effort, intense pushback from those who disagree with the solution and prefer another one, and painfully slow coffee-drip client propagation. (Don't forget Primal, which you mentioned, is still on NIP-04). And that's assuming it gets adopted at all. Async server-side transcoding in a verifiable hash environment in a system that doesn't have any sort of holding pen (because there is no central authority to hold stuff) is just really complex. Remember when MLS was supposed to take just some months and have libraries that'd make it easy for any NIP01 client to integrate, and by now we'd all be enjoying MLS groups in our Damusus and our Primals? Look this stuff is years and years, I'll call anyone's bluff that says this is just a "few months" of friendly zoom calls and clacking around on the keyboard.

> i don't think your customer wants to hear that it just won't work What's the poor guy supposed to do? Nothing supports what's being asked of him. And he can't just throw something out there and be like "yo, nostr, support this!".

There was one guy here I forget who that performed these coding gymnastics to get secp256k1 quasi-working for passkeys/webauthn via the PRF extension and a bitwarden software vault and a bunch of other stuff, and the result I'm guessing was something impressive but that can't really function in the real world given that webauthn mandates that it's up to users to choose how they want to store passkeys, not websites, and users will just choose keychain or whatever they see first.

Nostr's main defence is that nobody who could potentially do anything about it has ever heard of it.

Because you still have to mine them, ton by ton, you can't just tow one of these to earth, put a parachute on it and done. Whereas if a lab right now today had a number of quantum machines running 2k logical qubits and 1b gates, Bitcoin would be game over in a week. As in game truly over. Yeah we're nowhere near, but we are at 100 logical qubits and advances in error-correction means there is a clear theoretical path to billions of gates. So it's not crazy pills. Different threat types.

I think this scam example is a good one to measure solutions against, as most people would (I hope) agree that the baddie should not be able to get away with this in a modern chat app. And perhaps a sister example with the same scam but two baddies vs. two normies. (The two baddies are working together, tagging each others fake events and fake-tagging the normies real events.) But one baddie to start. The simple methods like "just hit reply" don’t work. The slightly more complex method of tagging the last seen message at time of compose/send is easily thwarted by the praying hands emoji. So then the more complex options. Caveat, I suspect they all end up in the uncanny valley between NIP17 and MLS, where you’ve lost the simplicity of NIP17 and haven’t gained the functionality of MLS. But open to some solution if it's out there. The e-tag all/some past messages option (Batman The Dark Night master view option) I did game out before and remain ambivalent about it. Depends how far you take it. Security-wise is it a good idea to have an event ID history in every single new message? And for clients to detect a mismatch they'd have to basically traverse a DAG every time a new message arrives, and often on cheap mobiles. For both those reasons you’d seemingly be pushed towards a small sliding window to save on client-side computation and avoid too big of an ID map in each message. But go too small and the baddie can bury the scam. Maybe there’s a sweet spot. But the biggest issue for me about this one is false positives. If this produces a warning two or three times a day due to lag and just general nostr jitters the user will start ignoring those warnings pretty quick. False positives for the invisible receipts method would be pretty extreme too, I think. My gut is still that NIP17 one-to-one is a big win, best to go hard on that. NIP17 groups feels like getting greedy and paying the price, and harming the one-to-one use case in the process. But I’m open to there being some tweak of, or combo between, what’s on the table (Dark Knight mode, invisible receipts, bloom filters, multisig, ring signatures, a few ZK things I've looked at and not mentioned yet) that won't blow interop to smithereens and that doesn’t end up deep in the uncanny valley. For this use case what would you say is the most efficient solution that doesn't result in a detrimental amount of false positives?

And by way of example: I’m in a group with 2 normies. They trust each other. I’m the baddie here. There is something being discussed that involves them paying me. I send a payment address (or URL, or whatever) as a message. What I actually did was I used a malicious client to send one address to Normie 1 and a different address to Normie 2. Nobody is aware of this but me. The two normies both think I have sent one single address to the chat group. As pretty much any normie would assume. I then send a praying hands emoji. Normie 1 says: “Done, it worked, appreciate it!” (This is a new message) Lucky me! I just needed Normie 1 to do the payment first. This instils confidence in Normie 2, which was my goal all along. It was a 50/50 and I won! Of course there’s something not right with the address or URL for Normie 2 (use your imagination). Perhaps if Normie 2 was more on guard they’d clue in while paying and then unlocking whatever it is. But I’ve used Normie 1 to bring Normie 2’s guard down. Normie 2 pays to the address or URL or whatever it is, but sadly for them [insert whatever bad thing happens as a result]. This way of scamming (split view attack) would just not be possible on WhatsApp, Telegram, Signal, etc. And even after Normie 2 clues in that something that should have happened didn't happen, there'll still be much confusion. Normie 1 and Normie 2 would basically have to screenshot the chat and compare screenshots to figure it out. So even after the scam I can potentially continue to gaslight Normie 2 using the success of Normie 1.

Sure happy to define it. - Person A, Person B and Person C are all “up to date” (seeing the same most recent message). - The history of Person A can contain one or more messages that are not in the history of Person B *in any form*, not a deleted-message tombstone, nothing, no trace whatsoever. And the reverse. And the same for Person A-C, B-C. - Additionally the history of Person A can be missing messages that appear in the history of Person B, again with no tombstone, no trace, no indication whatsoever that something is missing. -These "He sees it, she doesn't" messages can be sent simultaneously, so at the same time (and with a malicious client) Person D can send a separate message to Person A, a separate message to Person B, and a separate message to Person C. (or send to all but A at the same time). Also I'd add that any detection method cannot result in a false positive and is therefore explicitly trusted. The above combination of factors enables a level of social engineering that you can't really compare with what an attacker could achieve on Signal, WhatsApp, Telegram, etc. Yes of course people will get scammed anyway. Scammers love Telegram, and Telegram's serer ensures the above can't happen. What I'm arguing is that after getting scammed on Telegram it's fair to say (if cruel) that they have themselves to blame. For this case, if you game theory it out, I don't think we can say that they do fully have themselves to blame. It's a very unique attack vector.

Trying to solve is this: Reduce the chance that normies, thinking this works like Signal, WhatsApp, everything else they've ever used, get scammed here. By way of a gaslighting attack that is unique to NIP17 groups, and, if undertaken with skill, could be very effective. Assuming there comes a time when normies start to use this, which I'm hoping there will. This kind of gaslighting risk in closed-group ultra-private messengers is not normal, you have to admit that. Name me any other messenger in the category of ultra-private messaging that carries this risk? I'm open to the fact that one might exist out there, and if so curious what the UX is for this, but I haven't found any. For solutions, what I'm saying is the only solutions you're touching on that actually have wheels are really complex. It's a solved problem and all existing solutions are really complex too, so that only stands to reason. There are no simple fixes that don't end up as security theatre in some way.

I've grumpily decided I don't like zaps. Nostr either without zaps, or with like-zaps (a fixed amount per like that nobody change) would be so nice.

Which solution specifically? The "remember to hit reply" solution doesn't work, clearly. The "hidden reply to last-seen message at time of compose" does not either. Your bloom filter one, if you’re saying every new message can include tags for every ID of every message the client/user has received, in the whole history of that group (or to some length back), and bloom filters on top, not sure where to start (also not sure that's what you're suggesting). What are the other simple solutions?

That part makes sense. But how would you make a nostr metrics client? If I remember right Artur was from a web-crawling background and made is own nostr crawler from scratch. Or you mean just for publishing, like writing daily stats events to the relays?

Those guys of course. Though you could make a technical argument that something like Ed25519 is a better choice for this kind of use case. Or ML-KEM for interop with Chrome's post quantum hooks. Or this or that. Anyway, we're not talking about reinventing the whole internet based on secp256k1. Right?

Biggest issue there imo is secp256k1. It's just not a curve you can easily do this kind of core infra stuff with. It's not supported by passkeys (webauthn), it's not supported by SubtleCrypto, it's not supported by the secure enclaves of iOS or Android devices, you can't use a secp256k1-based certificate to sign a tls 1.3 handshake, then there's JWTs, JOSE, list goes on. It's just absent from a ton of web standards. mainly because it isn't NIST-stamped, so it's sidelined most places by secp256r1. Basically if the goal from the start is to replace the certificate chain and all the rest, secp256k1 is definitely not what you'd choose.

This. Most cypherpunks have lived lives without any physical violence at all and as a result don't even think to factor it in. To them, all fights are in code.

There's some cool tech on Bluesky/Atproto these days. Nostr dev community is always doing things, but atproto dev community is no slouch.

I think so, but there will be a long period where mining in space is only marginally more economical than mining on earth. Basically there's no lights out moment, and that's price in. For Bitcoin, as quantum develops markets will start pricing in a potential lights out moment. That is unless Bitcoin starts to work a little harder on quantum resistance. Which I very much wonder about, since much of the Bitcoin community is basically Amish in this regard.