@91pornshanghai 算法都是公开的，不可能留有后门

这个功能很好实现吧，就把这个功能叫做 智能发送 吧，

O 在与 A 的聊天窗口点 智能发送，弹出一个框，输入发给 A 的消息内容及 JS 代码，点发送。这时调用到业务服务，业务服务记录下，然后调用 server api 发到 O 和 A 的会话。
当 A 收到消息后，点击消息打开内容，点确认或者输入消息回复，这时调用业务服务，业务服务启动 js 环境执行 js 代码，js 代码可以分析处理 A 的回复内容，然后发送消息到 O 和 B 的会话，或者做其他事情。

@franklinre 这个也可以的，请求的数据中加上 js 代码，等对方回复后，在业务服务执行 js 代码，理论上可以做任何事。

受楼上启发，发送的消息还可以加上菜单，比如完成，未完成或者其他菜单，然后回复再根据不同条件回复对应消息

这个功能很好实现吧，就把这个功能叫做 接力发送 吧，
O 在与 A 的聊天窗口点 接力发送，弹出一个框，输入发给 A 的消息内容及选择自动发送人 B 及发送给 B 的内容，点发送。这时调用到业务服务，业务服务记录下，然后调用 server api 发到 O 和 A 的会话。
当 A 收到消息后，点击消息打开内容，点确认或者输入消息回复，这时调用业务服务，业务服务调用 server api 把要发送给 B 的内容发到 O 和 B 的会话内。

可以继续扩张，输入多个用户，每一个都等上一个人确认后再发送。

实现功能并不难，但好像就是没有什么用。

便宜又健康的就是运动了，找找周边有没有运动场，没有运动场就去骑车跑步

以我的经验给你几点建议吧
1. 格式用 amr ，amr 的好处是对人声处理的特别好，压缩比特别高，基本上每秒小于 1KB 。
2. 发送语音有 2 个种办法，一种是上传到一个服务器，把链接发送给对方，对方播放再下载；另外一种是直接放到消息体内直接发送给对方。如果是对讲语音，用第二种方式。
3. 对接的话不需要考虑存储，对方不在就直接丢掉。如果只有对讲可以不用考虑离线消息和消息存储。当然如果有其它类型的消息则必须实现了。
4. 不要从 0 开始写，现在有开源的 MQTT 服务和客户端，一个频道就是一个 topic 就行，再加上抢麦的功能，这种网上有很多抢红包的例子，比较类似。
5. 要逐步实现，不要贪大求全，上来就高并发微服务。先功能再优化。

另外感觉你问得太笼统了，如果做好一个通用型的 IM 是非常困难的，你基本上在这里得不到答案。你可以详细说一下问题和需求。

让测试做一些区分，是以前系统本来就有的 Bug ，还是新功能加上后引入的 Bug 。新功能引入的 bug 解决完以后就可以上新功能了，原来就有的 bug 等新功能上线后再解决

不安全吧，中原的雨还在下，连火车都停了，汽车肯定不安全，试试✈️

我们做的是即时通讯和实时音视频能力，可以方便地包装成各种形式的社交产品或者对接现有系统，可能有机会能够合作一下，我们的项目在 https://github.com/wildfirechat/server，有空了解一下。

创业很难，贵在坚持，加油！

@firechat https://item.jd.com/10023364741983.html

飞腾的电脑能买到，https://item.jd.com/10023364741983.html，麒麟的操作系统，我们公司买了一台

我一般都是听郭德纲相声，听着听着就睡着了，跟老年人开着电视更容易入睡一个道理

@shengchen11 这个是我们当初解决了时发的通知，跟你描述的现象一摸一样 https://mp.weixin.qq.com/s/4cw0BMoUJUNoZu1Cucax0Q

@shengchen11 猜测是这样的：一般情况下，手机只有一个网卡（或者 wifi 和手机同时，但优先级比较明确），webrtc 建立连接时监听某个 udp 端口，并把 ip 地址（可能是本地的也可能是 srflx 或 relay 的）和端口发给对方，双方尝试打洞。双卡情况下有两个网卡，webrtc 监听了其中一个网卡的端口，然后把外一个网卡的地址发给了对方，这样无论如何打洞都不会成功了。描述可能不够严谨，大概是这个意思

以前我们公司也被这个问题困扰很久，后来终于等到了 webrtc 解决发了新版本我们才解决，估计 tg 用的也是 webrtc 并且还没有升级到最新版本

把哪个做爬虫全公司被一锅端的新闻发给老板看看

白嫖的见多了，从来都是白嫖程序员给写程序，白嫖设计师还是第一次见
@firechat 开个玩笑，如果有空一起练练手也不错，总比闲着上 v 站空摸鱼强