Oddbean new post about | logout
 Because nostr:nprofile1qqsvnx99ww0sfall7gpv2jtz4ftc9v6wevgdd7g4hh7awkpfvwlezugpg3mhxw309um8semndee8wdnrwvmk2atdw9arwct6xa6hj6mv0fhkzuncd34x6arxddckkctk094k7urkv33x2atpd36hzctc09jzummwd9hkutc2rde3l is the way  
 https://media.tenor.com/8mddYUccA9cAAAAM/wrong-drumpf.gif

🤣🤣🤣

In all seriousness why would you rather use nostr:nprofile1qqsvnx99ww0sfall7gpv2jtz4ftc9v6wevgdd7g4hh7awkpfvwlezugpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhs38wxc9 over nostr:nprofile1qqs9ajjs5p904ml92evlkayppdpx2n3zdrq6ejnw2wqphxrzmd62swspzemhxue69uhkummnw3ezumt0w46x7m3wv3jhvqgkwaehxw309aex2mrp0yhxummnw3ezucnpdejqzrthwden5te0dehhxtnvdakqhm2uug?  
 DYOR 
 Fair enough. The only argument I get for SimpleX over nostr based is the lack of metadata associated to your conversations on SimpleX. This is a real issue for some people but would not affect me normally. If there was a situation I needed that metadata split I'd just spin up a nostr identity just for that communication use case. Personally I think the WoT possibilities of nostr far outranks the anonymity of SimpleX for 99% of my interactions. 
 Nostr isn’t designed to be private 
 No need to compromise on discoverability or privacy. Nostr can be used as a discorrability layer for SimpleX (or any other messaging app) but this has been turned down twice. There were discussions about interesting SimpleX with Nostr last year but it never went anywhere, someone made a proposal for a contact info field to replace the DM button with but that was declined. 
 This. 
 https://github.com/simplex-chat/simplex-chat/issues/2859 
 This is for verifying identity to contacts, not discovery. Nothing needs to be done on SimpleX's end for discovery but Nostr devs declined. 
 What do you mean they declined? Was there a nip proposed for it? Clients could still do it if it was a good proposal. There is nip 48 proxy tags and nip 39 external identities that could hold simpleX information maybe 
 There was a NIP proposal for adding general contact info links which includes SimpleX. NIP-48 is for bridging content from other platforms, NIP-39 is for verifying identities of other platforms, which I suppose could be done for SimpleX addresses if there was a way to sign messages with the public keys. I think NIP-24 kind 0's are the most suitable for linking to SimpleX addresses as described here: https://github.com/retrnull/garnet/issues/8 
 We love Nostr as a publishing platform that offers unparalleled censorship resistance. But NIP44 does NOT provide most of the important qualities of e2e encryption:

- break-in recovery.
- repudiation (deniability).
- visibility of connection graph to observers.
- fixed message sizes (although it can be provided by the specific app)
- resistance to Shore algorithm (PQ encryption).

It's unclear whether it provides forward secrecy, but the spec implies that it does not - I might be wrong here.

We wrote this post about the qualities of e2e encryption and why they are important: https://simplex.chat/blog/20240314-simplex-chat-v5-6-quantum-resistance-signal-double-ratchet-algorithm.html 
 NIP-44 is just the encryption. The DM protocol is NIP-17 with NIP-59 and NIP-44. No one uses NIP-44 by itself for messages.

1. NIP-44 has padding for fixed message sizes. 2. NIP-17 DMs is giftwrapped by ephemeral keys in public, so repudiation/deniability is provided as well. Gift wraps can even use random alias keys as receivers. 
3. The connection graph is not visible unless the NIP requires it to. 
4. Break-in protections exist on the wrap. Breaking individual messages does not reveal the main nsec of the Nostr user. The only way the break-in can work is if the attacker gets the long term key or seed, which is also a problem for other E2E apps.  
 Also nostr:nevent1qqswtluezhnlywfk5m4z5wzywyemfc9dmcceejlavnsqnhf2ttgks3gpyamhxue69uhkymmnw3ezuenjv4jhxur9v43kstnrv9ekztelv93kxatjv96x20f3qgswmdrsyuff0tz6v8e80u7dzn09f3n7khxdyrhsm80jn0scdpdmqpqrqsqqqqqpfj9dl7 
 Excellent post! 
 No, but it's a very similar design with relays. Nostr has largely failed to provide a private and secure DM protocol so far so that should be a good thing. nostr:nevent1qqs04jkx6rxfnzs8a3dc3gxsqpvjhe9yat74y3hdmfw53efeu22g6qcqrau8x 
 nostr:nevent1qqs04jkx6rxfnzs8a3dc3gxsqpvjhe9yat74y3hdmfw53efeu22g6qcpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtczyrye3ftnnuz00lljqtz5jc4227ptxnktzrt0j9dalht4s2trh7ghzqcyqqqqqqgz2ugx4 
 Nip17 is a combination of nip 44 and nip 59 gift wraps, which takes care of the concerns in that message. 
 NIP-59 seems to do a good job at hiding metadata from public view but it doesn't provide

- break-in recovery.
- repudiation (deniability).
- (lack of) visibility of connection graph to observers.
- fixed message sizes (although it can be provided by the specific app)
- resistance to Shore algorithm (PQ encryption).

I can add that it definitely doesn't provide forward secrecy.

It's concerning that these developers simply don't seem qualified to properly implement secure messaging, and I believe users are being put at risk, although I do see a lot of people just putting nostr:nprofile1qqsvnx99ww0sfall7gpv2jtz4ftc9v6wevgdd7g4hh7awkpfvwlezugpz4mhxue69uhhyetvv9ujumn0wd68ytnzvuhsg5cway addresses in their profile anyway. 
 You are wrong on several of these if not all. I will pull it up in a bit. 
 By 'it' I mean mean NIP-44 encryption. 
 Nip17 is a combination of nip 44 and nip 59 gift wraps, which takes care of the concerns in that message. 
 NIP-59 seems to do a good job at hiding metadata from public view but it doesn't provide

- break-in recovery.
- repudiation (deniability).
- (lack of) visibility of connection graph to observers.
- fixed message sizes (although it can be provided by the specific app)
- resistance to Shore algorithm (PQ encryption).

I can add that it definitely doesn't provide forward secrecy.

It's concerning that these developers simply don't seem qualified to properly implement secure messaging, and I believe users are being put at risk, although I do see a lot of people just putting nostr:nprofile1qqsvnx99ww0sfall7gpv2jtz4ftc9v6wevgdd7g4hh7awkpfvwlezugpz4mhxue69uhhyetvv9ujumn0wd68ytnzvuhsg5cway addresses in their profile anyway. 
 You are wrong on several of these if not all. I will pull it up in a bit. 
 By 'it' I mean mean NIP-44 encryption. 
 NIP-59 seems to do a good job at hiding metadata from public view but it doesn't provide

- break-in recovery.
- repudiation (deniability).
- (lack of) visibility of connection graph to observers.
- fixed message sizes (although it can be provided by the specific app)
- resistance to Shore algorithm (PQ encryption).

I can add that it definitely doesn't provide forward secrecy.

It's concerning that these developers simply don't seem qualified to properly implement secure messaging, and I believe users are being put at risk, although I do see a lot of people just putting nostr:nprofile1qqsvnx99ww0sfall7gpv2jtz4ftc9v6wevgdd7g4hh7awkpfvwlezugpz4mhxue69uhhyetvv9ujumn0wd68ytnzvuhsg5cway addresses in their profile anyway. 
 You are wrong on several of these if not all. I will pull it up in a bit. 
 By 'it' I mean mean NIP-44 encryption. 
 nostr:nevent1qqs04jkx6rxfnzs8a3dc3gxsqpvjhe9yat74y3hdmfw53efeu22g6qcpz9mhxue69uhkummnw3ezuamfdejj7q3qexv22uulqnmlluszc4yk92jhs2e5ajcs6mu3t00a6avzjcalj9csxpqqqqqqzehrms0