产品创意：一种信息可回调的聊天 APP

[franklinre]

现在我们的消息都是单向的，例如邮件，信息发送给对方，必须等待对方发送回来，我们才能收到信息。
这样在某些情况就会比较麻烦，例如：给 A 发送信息，等待 A 的回复后，再给 B 发送信息。
如果我可以给 A 发送信息时，把回调方法插入信息中，要求 A 完成这个回调，这个回调会给 B 发信息。这样我是不是就不用等待了呢？

[IvanLi127]

我觉得可以考虑委托 A 给 B 发送消息。
如果 B 不相信 A 说的话，可以把 B 的一个秘密告诉 A ，让 A 向 B 发消息前和 B 交换并验证这个秘密。
这样一来，你就完全解脱了。

[dcty]

拉个群啊，手动狗头。

[Jooooooooo]

你想要的是不是邮件的抄送功能?

回复邮件抄送都会收到的.

[debuggerx]

消息发给了 A 然后设置好了所谓的回调自动发送给 B 结果 A 回的消息是“B 是大傻 X”……

[hanbing135]

这不就是抄送吗

[darkengine]

If this then that

其实是收到 A 的回复信息后，触发给 B 发信息这个动作 （发给 A 、B 的信息不一定相同）。

[lucybenz]

有点意思 还可以让群主灵活设置群规则 比如把群设置成圆桌游戏 必须上家发言、操作结束或超时 下家才可以发言 妥妥的 元宇宙社交

[binux]

你需要一个 workflow 管理系统，消息只是载体。

[dunn]

楼上的回复笑到了

[kop1989smurf]

楼主的程序设计功夫不到家。

1 、发给 A 与发给 B ，其实是完全没有耦合关系的。
2 、把执行逻辑带给 A ，IO 开销浪费。
3 、原本是可信任信息（本地 sendB 逻辑），变成了不可信任（由 A 执行的 sendB ，A 是否会篡改 sendB 不可预知）
4 、犯了和显卡界“光追”一样的错误：将开销转移给了本不应负责的人。（ sendB 原本是楼主的责任）

所以，这个需求我的设计，是 sendA 的同时附上消息 ID ，同时监听本消息 ID 的回复。
针对回复再次触发 sendB 命令。

[Veneris]

你需要 ai 替你处理邮件

[lululau]

我给 a 发消息，a 还可以回给我，拜托，这个叫双向，考虑到中间可能还有服务器，这个还可以叫四向😂

[franklinre]

@kop1989smurf 别太认真看待我举的例子。
我是说现在的聊天 app 的消息都是单向的文本，就像我们代码里的 string ，既然可以发 string ，为什么我们不能把函数，逻辑，代码，也当作一种新的消息形式发送给对方呢？
只有 string 也太单调了。
A 可以回调方法，我可以把这个回调当作数据发送给 B ，B 也可以发送给其他人。可以应对某些需求。

[kop1989smurf]

@franklinre #13
谁说现在的 IM 只能发字符串的？你给他发个.bat ，发个.dll ，发个.exe ，甚至发个.java 不就达成了？

[kop1989smurf]

@franklinre #13
反之，如果你说的是必须自动执行，那不叫聊天，叫挂马。

[wangerka]

我给某人发一条消息可以是：function (done){return done == 1 ? "好啦":"还没做完"}。对方在消息里输入 1 ，我就能收到“好啦”。是这个意思吗？

[firechat]

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

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

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

[firechat]

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

[franklinre]

@firechat 功能肯定有很多种方式实现，我想表达的是，现在的 IM 的消息形式太单调了，可以在上面做点文章。如果把两个用户比作两个函数方法的话，方法之间不能只是发送文本，文件，语音等的拷贝吧？应该还能发送变量引用，回调吧？

[HeyWeGo]

Telegram bot ？