修桥前和拆桥后有多位涉水过河的村民溺亡。
No ID只是听起来挺酷，但牺牲了太多的用户体验。
如果你愿意，可以为每个聊天对象生成一个单独的Nostr ID。
至于隐私性保护，NIP42 + NIP 59已经超越simpleX。
偶然看到这句话，借来描述我对Nostr的看法非常合适。
nostr:note1qfnup7yprqt0pw0xs03e00dgdtunqfckvmlju5wgmcnu6ezt90kqwl89k0
Ecash发行方有点商业银行的感觉，存在跑路可能性。比特币主链类似央行。
选择可靠的发行方放零钱。
是那东西，Bitcoin恰好解决了其最大问题。这里有个简单介绍：https://thebitcoinmanual.com/articles/chaumian-ecash-bitcoin/
前些天fiatjaf也意识到这个事情，不过讨论没怎么展开。
其实大型relay用fedimint也可以，只是比cashu稍微复杂些，但也有相应的安全回报。
nostr:note1m7hguukwncsh7wdrc7adn6fwudl3agx7dphdlpgxxcrj08uexlkq3fl807
我只知道币是托管给发行方的，但是转ecash 时，发行方并不知道转账内容，主打隐私性。
nostr:note12ylcdswfame8rhf3dfnmyya0wqcpzw72rpthhtttcuahc32jrzks42xtmw
以上就是当前一对一聊天的安全翘楚。
接着写下加密群聊。
我们想要的加密群聊是只有群成员才能加解密消息的端对端加密群。微信群这种通过中心化服务器控制群权限、无端对端加密、始终有一个“官方”可以监控所有群的方案不在我们讨论范围之内。
从两个人的一对一聊天到三个人的群聊是非常不一样的。现在还没有完美的加密群聊方案，目前主要有以下四种实现方式（我只了解到这四种，欢迎补充）。
1、群发模拟出群聊。
一个成员在此模式的群发言，实际上他是在给其他群员发送了一对一私信，在用户界面显示成群聊。假设一个群有10个人，一个群成员发送一条群消息，实际上他是给另外9个成员发送了9条不同的加密消息。
这种方案适合小群。它的优点是直接继承一对一聊天的安全性，简单粗暴。缺点是可扩展性差，不适合人数很多的大群。
2、共享群密钥模式。
在这种模式下，所有的群成员共享一个密钥，所有成员都用它加密和解密群消息。
这种方案适合人数更多一些的群。当群成员发生变动时，例如踢掉某个捣乱的成员，需要更新共享密钥。这种情况下，更新共享密钥效率不够高，可以理解为复杂度为O(N)，复杂度和群人数成正比。
3、sender key solution。
在这种模式下，假如一个成员刚加入一个有99人的群，他首先把自己在这个群要用到密钥发给另外99人。后面他在这种群的发言用这个密钥加密，其他成员用这个密钥解密即可。还可以更进一步，他可以对这个密钥做哈希计算，用得到的新密钥加密下一条消息，其他成员也同样操作，然后用新的到的密钥来解密他的消息。
这个方案的难点也是出在群成员变更的情况下，如果有个成员被发现是叛徒，把他踢掉后，所有成员都要互换新的密钥（通过一对一私聊方式）。可以理解为复杂度为O(N^2）。
WhatsAPP的群聊用的是此方案。
（我没有理解为什么会有这个方案，不知道它和共享群密钥模式相比，有什么优势。有懂行的，欢迎评论。）
4、MLS （ Messaging layer security ）
这是一个还在制定中的加密群聊方案。制定MLS的组织制定过TLS（transport layer security)，几乎只要上网就会不知不觉用到它。MLS方案小组的成员包括一些大的互联网公司，例如facebook和推特，还有一些高校。
MLS目标是为5万人的大群做加密方案。群成员到达万人，前面几个方案就力所不及了。方案2和3在群成员出现变更时，复杂度太高了。
MLS也是共享一个群密钥，所有成员用它加解密消息。特殊之处是，MLS的做法是通过一棵特殊的群成员二叉树方式，把交换更新群共享密钥的复杂度降到O(logN)，从而能支持更多的人数。
