有些安卓用户会使用一个第三方服务来转发iMessage，比如曾经的beeper mini
然后估计不久后就要求接受RCS了
今天突然发现iOS悄咪咪研发了这个功能：
设置-头像-滑到底
md退出了iCloud
Beeper Mini（反向 iMessage 实现的那个）已经凉了，不会有人会依赖一个隔两天宕机的服务聊天（被 Apple 封堵）
然后 iMessage 和 RCS 仍然是两个分开的存在，后者仍然是 green bubble 
那些为推 RCS 鼓吹 “get the message, stop green bubble hate” 的人都傻眼了。Cook 表示你们不是想要 RCS 吗，有 RCS 还不高兴？
此外 RCS 标准本身并没有端对端加密支持，Google Messages 的加密是谷歌自己加的
1 个赞
RCS标准里运营商和Google是啥关系？
运营商可以选择下发 RCS 配置（自建或者用谷歌的 Jibe），没有的话 Google Messages 会自动用自家的 Jibe。现在大部分运营商都钦定谷歌的，但是如果自建就很坑了，因为实现服务器之间的互通需要通过电话号码查到对应的运营商。
这里就到了号码控制权的问题：如果运营商自建 RCS 想给一个未知号码发消息，要么拒绝（之前 ATT 就是这样）要么回落到 Jibe，也就是完全信任谷歌会在用户注册时正确验证手机号
于是现在实际能用的 RCS 就是谷歌的服务，你作为苹果用户也没法不信任他们
1 个赞
不要再阴谋论了……
Contact Key Verification 这功能需要手动开的，iOS 也不会主动引导你开，包括 OP 在内的大多数人可能也并不清楚它到底是干啥的
这个东西是防止别人伪造你的身份的，可以通过线下交换公钥的方式确认跟你聊天的就是那个人。
而且同为端到端加密的 WhatsApp、Signal、Matrix Synapse 早就支持这个功能了。iMessage 号称端到端加密，其实在支持了 Contact Key Verification 前都不是很安全。Matrix Synapse 是开源的，底下有一大堆第三方客户端，支持 Verification 并没有影响这些第三方客户端的发展。
在我看来 Contact Key Verification 这个功能是所有打着安全旗号的软件都应该支持的功能，苹果后知后觉终于反应过来了。最近苹果还在 iOS 17.4 里加上了 PQ3 论文 / 官网，可以明显看出 Contact Key Verification 是为 PQ3 铺路的。最近苹果还做了 Stolen Device Protection；去年苹果还搞了 Advanced Data Protection for iCloud；感觉苹果终于在安全上发力了，这一波下来已经超越友商们了
不如说苹果是想把 iMessage 的功能做的更强，在安全性上超越 RCS、WhatsApp、Signal，以让用户更喜欢用 iMessage
想屏蔽转发服务苹果有至少一百种方式，犯不着通过这种方式
4 个赞
那感觉这个标准有问题啊，还不如SMS？
谷歌在RCS标准里是啥角色？
为啥会不知道对方服务器？不然电话不都打不出去
电话号码是由 Number Portability Administration Center 管理的，运营商完全控制整个过程。然而谷歌当时看到各大运营商不想支持 RCS 烦了，于是自己做了一套注册机制，你下载 Google Message app 会自动通过短信验证注册 Jibe，完全绕过了运营商。发消息的时候会查 Jibe 看对方有没有注册
几年后 ATT 自建 RCS，就出现了操蛋的用户体验：自己下载 Google Messages app 的用户（Jibe）无法与 S22 预装 Google Messages app 的 ATT 用户（ATT 自建）互通。不是都用的 ATT，而且是同一个 app 吗？
用户不爽，运营商不爽，那大家干脆都 Jibe 算了（ATT 之后转到了 Jibe）。谷歌大喜
好的，改掉啦
1 个赞
随便唠叨几句：其实苹果不想让第三方搞 iMessage 是因为第三方是通过逆向工程实现的 iMessage（当然还有通过 Mac mini 服务器登录你的 Apple ID 然后再转发）。逆向工程的话这种本身就是不可靠的方案，未来苹果随时升级一下 API 接口第三方就挂了，而且苹果本来就没有让第三方使用这些 API，所以苹果也没有义务去随时保证这些接口可以被第三方的程序正常调用。比如 iMessage 有个漏洞，需要同时升级服务器和客户端才能解决，这种第三方程序则会继续跑在有漏洞的软件上。
Mac mini 服务器这种方式虽然没有逆向API接口（但估计还是逆向本地数据库了），但相当于你的 Apple ID 在别人的电脑上登录，有很大安全隐患。
如果苹果决定开放API，苹果需要投入更多人力成本，而且又是一套私有的东西也很难成为标准。加入 RCS 这套标准才是最正确的方案，同时也可以劝退那些第三方 iMessage。就看苹果能把 RCS 做成什么样了，如果做的跟
一样那就是苹果故意的（类似欧盟开放侧载，结果又要收核心技术费）；如果苹果能用心做 RCS 那我觉得苹果垄断 iMessage 就彻底终结了
目前感觉苹果的战略是要把最好的功能和技术都加在 iMessage 上（包括Contact Key、PQ3），以在支持 RCS 后继续突出 iMessage 的优势（比如现在开了 Contact Key 的联系人有
）；不过这些都是一些边际优势，SMS 变 RCS 后 iMessage 的额外好处肯定会锐减，实际上没多少人在意端到端加密和 PQ3，只有少数 Hacker 喜欢这个。不过对于用户而言是赢的，希望看到RCS和iMessage一起卷起来
2 个赞
还在想是不是有个MD公司退出了跟iCloud的合作。。。
为啥不能互通呢？
查一下portability center再查一下jibe不就知道了吗
从 ATT 的角度，对面号码归属是自己的，为啥往一个第三方服务器发送。回落到 Jibe 就回到了信任谷歌的问题，然后仍然无法获得完整的谷歌体验
虽然现在谷歌也在推动运营商官方采用 RCS（和 Jibe 
），我还是对谷歌以来的作为不满：
- 强推 Jibe 导致号码归属有两个不同的 source of truth
- 推行自己的扩展（端对端加密）和应用（Google Messages）
- 当以上两点不存在，假装全部都是标准，GetTheMessage
那为啥同样的ATT会有不同的RCS实现？
所有的sim卡不都有写入短信中心号码吗，为啥自己下载的Google message不用att的实现？
这个就不知道是谁的锅了（Messages app 没有刷新配置，还是 ATT 下发问题），然后用了 ATT 也没有科学解决互通的问题，也不能用谷歌吹的加密。当时 Reddit 和 ATT 官方论坛都在喷 ATT 的 “proprietary RCS servers”，好像 Jibe 就不 proprietary 一样
结果就是 Jibe 大一统，for better or worse。之前 ATT 和 TMO 尝试“正确方法”（用了它们的服务器只能两个运营商之间互通）然后大家不买账
这感觉是实现失误啊，要么就是协议设计有问题，没有处理interoperability
Mdzz的md
知道的，骂人的