取消服务器存储的加密通讯方案，究竟是隐私福音还是开发噩梦
这种架构的逻辑链路极其精简，但对开发者的要求极高。在实际部署中，它首先需要建立一个点对点握手机制。客户端必须通过一个极其轻量级的信令服务器来交换公钥。这里的关键点在于，这个信令服务器在整个过程中不存储任何会话状态，它扮演的角色仅仅是一个“接线员”，在两个客户端完成公钥对敲后，服务器端不留任何痕迹。
最核心的颠覆在于消息的实时中转阶段。在传统架构中，消息进入服务器后会被写入数据库（如 MongoDB 或 PostgreSQL），等待接收端通过轮询或推送来拉取。而 Neptune 将服务器定义为纯粹的“临时缓冲区”。消息在内存中短暂暂存，一旦接收端发送确认收到（ACK）的信号，服务器必须立即执行物理删除操作。这意味着在服务器端，一条消息的生命周期可能只有几毫秒到几秒钟，完全不存在所谓的“云端备份”。
在这种设计下，所有的历史记录全部下沉到用户的本地设备中。这种“不可恢复性”虽然硬核，但对于追求极致隐私的用户来说，这才是真正的安全——如果设备丢失且没有手动备份，消息将彻底消失。它把数据的控制权从服务商手中完全夺回，消除了由于服务器端漏洞导致的大规模数据泄露风险。
不过，在实操部署 Neptune 方案时，有两个非常棘手的坑必须提前考虑。
首先是离线消息的处理。在没有中心化存储的情况下，如果发送方发出消息时接收方不在线，消息在缓冲区过期后会被直接丢弃。这意味着你不能像使用传统 IM 那样，在离线后重新登录时看到“未读消息”。除非开发者引入一套极其复杂的延迟队列机制，否则用户体验会非常糟糕，甚至会出现消息随机丢失的现象。
另一个痛点是多设备同步。由于没有中心存储，新设备登录后无法像同步社交软件记录那样直接拉取历史数据。如果你想在平板和手机上同时看到聊天记录，必须在本地设备之间建立一套独立的 P2P 同步协议，这极大地增加了客户端的开发复杂度，且对网络环境要求极高。
总的来说，Neptune 这种设计并不适合替代大众社交软件，因为它牺牲了太多便捷性。但对于安全性要求极高的专业场景，这种去中心化的存储思路非常有参考价值。它向我们证明了：真正的隐私不应该是通过复杂的加密算法来掩盖存储，而应该是直接从物理层面取消存储。
