这不是邮件的问题，是邮件客户端的问题
好几年前国外就流行把邮件格式化，像聊天软件一样直观，忘了做的最大的是谁了，Slack, YoMail Group 都是其中一个

云服务每个服务开通都要用户确认才开通的，所以
这日志服务我都不记得什么时候开通的 - 这明显你自己忘了

相信腾讯财务统计也大概率不会出 bug ，所以
可能你没被坑？

计算器问题很严重 1/10+2/10=0.21 认真的么 😗

@gesse 应该不是这个原因，供不应求只影响短期价格，这应该还是硬件价格上涨导致的

@ouqihang 确实 我们玩都是下 armbian 第三方的系统

你们提交 commit 连 author 不指定么？另外任何时候都应该避免直接修改 git 仓库

如果其他人都是 merge 进去的话可以考虑把 log 拉出来，merge 的点和 merge 关联的 commit 都排除，剩下的就是你的

用多个 dom 标签结合起来显示邮件地址，对用户无感又可防止被扒

不用 ai ，盲猜是色彩通道或者说颜色模式的问题？看看保存时是否可以设置

其实挺好的，以前写代码总感觉束手束脚，现在加了泛型灵活多了

pixi 配合相应的平滑迁移库可以试试，基于 webgl 渲染的

@yhvictor 确实，你说的对，如果提前拷贝了 ssh 公钥，这种情况无法进行中间攻击。但是这又回到了最早的情形-既然都可以通过某种方式将公钥可信的传递到服务器，那么有没有密钥交换都无所谓，端端通信跟 dh 没关系了。这个我是针对 nomagick 的回复说的。

我也是做区块开发的，至于区块链我跟你看法也一样，区块链本身协议无法提供可信保障，现有的区块链其实都存在这个漏洞的，只不过区块链中间人攻击几乎没有什么收益，而且节点多攻击成本也高-有那能力还不如 51 攻击。
公钥加密-解决不可信网络的可信通信(如 https)
私钥加密-解决不可信网络的身份认证(如区块链)

@rekulas 补充一句，其实普通的 ssh 证书登录也是用了 ca 的，只不过 ca 是自己并不被系统信任，所以开始的时候会询问你是否信任。

完全不依赖 ca 呢？也是可以通信的，但是如上仍然是不可信通信

@nomagick ca 并不是信任服务器名单，它只是一个授信机构，也就是初始化的时候可能没有任何证书，唯一的共识就是-所有人都信任 ca ，然后进入通信环节，ca 通过各种认证向客户端办法证书，大家都信任，通信才能继续。

ca+密钥交换，可以实现在不可信网络中的可信通信，这正好是 op 的需求，也是 https 的基础原理
回到你的疑问-ssh 就没 CA ，照这么说没法用了
可以用，但是你的通信时在不可信网络中的不可信通信，通信中的任何一个中间设备都可以对你发起攻击

要说主要的漏洞，可能就是 ca 认证环节了，如果认证不够严格可能会被伪造证书，但鉴于其超低概率和高难度基本可以认为是足够安全的，毕竟我们的互联网就运行在这套理论上而且稳定几十年了

@nomagick 那你仔细想一想，要求你确认的目的是什么？就是为了让你自己负责对方是否可信啊，那么问题来了

如果你没有第三方认证机构，你确认的时候怎么知道对方是否可信呢？如果是假冒的你也无法分别
如果你说你本地存储了一份信任服务器名单，那又有个新问题，信任名单是从哪里来的呢？如果你通过网络传输，那又陷入了中间人攻击的怪圈。如果你是直接提前协商写死的，那么既然都可以提前协商了还用 dh 干什么，直接写死每个服务器通信对应的加密 key 不就完了？所以说光是 dh 是无法解决端端通信的

@nomagick 密钥交换只是其中一个逻辑啊，光有交换算法也没法通信，都说远了最简单的 https 通信就是一个非常安全的端端通信，在不自黑的情况下目前没办法破解

“亦或借助 server 进行转发，server 俨然就是一个中间人的角色，在协商阶段把 A 、B 的密钥全都替换成 server 的。”

这个中间人的定义就不太准确，参考中间人攻击方式，server 要换密钥，那 client 就要信赖 server 才行，既然你都信任 server 了，那就相当于自己 hack 自己了。只要你只认可合法 client 的证书，server 没法攻击

淘宝的体验真的是一言难尽，前段时间购物经常收不到卖家消息，后来才知道因为之前我开过卖家店铺，别人看到我有 2 个头像一个是卖家千牛的一个是买家的，所以能不能收到消息完全是随机，搞得我淘宝购物还必须安个手机千牛，还找不到关闭入口，如果能不用淘宝，那自然尽量远离 🤣

我也有同感，更新倒是一直很频繁，可能还不够稳定

@dzdh wrk 没用过 你可以用 ab 压测下对比下结果里的 Keep-Alive 数量