Oddbean

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?

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.

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.

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

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

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.