Signal CLI REST API 中使用 UUID 进行消息收发的技术解析

背景介绍

Signal CLI REST API 是一个基于 Signal 协议的通信工具接口，允许开发者通过 RESTful API 与 Signal 服务进行交互。在实际使用中，开发者可能会遇到消息收发时涉及的用户标识问题，特别是 UUID 的使用场景。

UUID 作为用户标识的机制

在 Signal 协议的最新版本中，系统逐渐从传统的电话号码标识转向更注重隐私的 UUID 标识机制。当通过 Signal CLI REST API 接收消息时，返回的 JSON 数据结构中会包含以下关键字段：

• sourceUuid: 发送方的唯一标识符（UUID 格式）
• sourceNumber: 发送方电话号码（可能为 null）
• sourceName: 发送方显示名称

这种设计提高了用户隐私保护，但也带来了 API 使用上的新挑战。

技术问题分析

开发者在使用 v2 版本 API 时遇到的主要问题是：当尝试使用 UUID 作为收件人标识发送消息时，系统错误地将 UUID 解释为用户名格式，导致发送失败。错误信息表明系统期望用户名包含点号(".")，而 UUID 显然不符合这一格式要求。

解决方案

项目维护者已经确认这是一个需要修复的问题，并在开发版本中提供了解决方案。开发者可以采取以下两种方式：

1. 等待正式发布：官方表示将在近期发布包含此修复的正式版本
2. 使用开发版本：通过使用 bbernhard/signal-cli-rest-api:0.162-dev 镜像提前体验修复后的功能

临时替代方案

在等待修复版本发布期间，开发者可以考虑：

1. 继续使用 v1 版本 API，该版本对 UUID 的处理方式不同且能正常工作
2. 在应用层实现 UUID 到其他可用标识的映射逻辑

最佳实践建议

1. 版本兼容性：在应用中同时保持对 v1 和 v2 API 的支持，确保平稳过渡
2. 错误处理：实现健壮的错误处理机制，特别是对用户标识相关的异常
3. 测试策略：在开发环境中充分测试不同版本的 API 行为差异

总结

Signal 协议向 UUID 标识的转变是隐私保护的重要进步，但也要求开发者适应新的 API 使用模式。通过理解底层机制、及时跟进官方更新并采用适当的应对策略，开发者可以构建出既保护用户隐私又稳定可靠的通信应用。