Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

收消息API 重用返回值以实现快捷回复 #96

Closed
danni-cool opened this issue Dec 25, 2023 · 6 comments · Fixed by #95
Closed

收消息API 重用返回值以实现快捷回复 #96

danni-cool opened this issue Dec 25, 2023 · 6 comments · Fixed by #95
Labels
enhancement New feature or request

Comments

@danni-cool
Copy link
Owner 

          客户端不是本身就可以提供http访问推送消息吗？ 那我理解客户端应该具备给某个用户发消息的能力，直接把post的返回推送给发送方，就实现了回复拦截、处理、再回应的功能.

不然的话，就必须得两台服务

Originally posted by @lucasjinreal in #56 (comment)
@danni-cool danni-cool added the enhancement New feature or request label Dec 25, 2023
@rcy1314
Copy link

rcy1314 commented Dec 25, 2023 •
edited

个人见解：单通道发送接收是可以做到，比如webhook接收信息post到tg，再设置一个tg机器人post到固定群昵称，就形成了一个发送和接收的回路，加上tg的特性如果拉入该机器人到频道则可以在频道内实现双向接收和发送，在但接收需要name值的判断和对name值的单独包装定义，所以在这里，除了艾特别人时可以看到昵称，基本上对话中自己设置不到可以双向或单独回路的不同的昵称，需要在规则中添加一个存储发送人的昵称name值并轮询和判断下一个会话时舍弃存储的上个name值继续存储本次对话的name值，完成一个不同对话的机制，也可以单独把name定义函数值，在集成中可以设定该name值

@danni-cool
Copy link
Owner Author

个人见解：单通道发送接收是可以做到，比如webhook接收信息post到tg，再设置一个tg机器人post到固定群昵称，就形成了一个发送和接收的回路，加上tg的特性如果拉入该机器人到频道则可以在频道内实现双向接收和发送，在但接收需要name值的判断和对name值的单独包装定义，所以在这里，除了艾特别人时可以看到昵称，基本上对话中自己设置不到可以双向或单独回路的不同的昵称，需要在规则中添加一个存储发送人的昵称name值并轮询和判断下一个会话时舍弃存储的上个name值继续存储本次对话的name值，完成一个不同对话的机制，也可以单独把name定义函数值，在集成中可以设定该name值

回复同一个人呢的话，为什么要存储 name，而不是作为流的一部分，从源头(source里带有请求人信息）打标记，带到结束去post呢。

这个issue的提案，是为了改进这个功能，既然是请求的发起方，作为消息接受服务器，只要根据昵称去处理逻辑，最后并回应请求就好了，相当于一对一回复。

@rcy1314
Copy link

rcy1314 commented Dec 26, 2023 •
edited

回复同一个人呢的话，为什么要存储 name，而不是作为流的一部分，从源头(source里带有请求人信息）打标记，带到结束去post呢。

这个issue的提案，是为了改进这个功能，既然是请求的发起方，作为消息接受服务器，只要根据昵称去处理逻辑，最后并回应请求就好了，相当于一对一回复。

需求场景不同，也许我提出的不符合开发中的一环，或者和这个issue的提案不是一回事，我想要流中能提取name【有，但无法单独定义该函数】来记录是哪些人发送的信息，造成即便你能通过改进做到一对一回复，但在记录中无法记录有哪些人进行了对话。或许有人可以解答是否可以把name值作为json中的一个函数值，如果可以，则我的疑问就得到了解决，提过一次，不过我自己改的逻辑并不好，或者是否该放弃发送者名称的记录而选择其它场景

@danni-cool
Copy link
Owner Author

我想要流中能提取name【有，但无法单独定义该函数】来记录是哪些人发送的信息

  1. 以n8n举例确实无法单独定义一个 flow就能携带 name，但至少每个flow去处理的时候都需要向下传递 name字段。当然你为了方便全局暂存也是合理的做法，但我认为不应该是全局，而是每个环境运行时有自己的变量空间，所以flow向下传递是个合理的场景。我提的issue 包括后面要加的response即回复是优化这个场景。

即便你能通过改进做到一对一回复，但在记录中无法记录有哪些人进行了对话

  1. 为啥记录不了？source字段里的 from.payload.name 就是talker
  2. 如何回应是你服务器的策略，比如匹配到 @推送助手 就回复他，匹配特殊关键词，开始回复，那此时确实要存一下 这个人+关键词开关状态。但貌似不是我的项目需要去解决的问题

@rcy1314
Copy link

rcy1314 commented Dec 26, 2023

  1. 为啥记录不了？source字段里的 from.payload.name 就是talker
  2. 如何回应是你服务器的策略，比如匹配到 @推送助手 就回复他，匹配特殊关键词，开始回复，那此时确实要存一下 这个人+关键词开关状态。但貌似不是我的项目需要去解决的问题

👌

@danni-cool
Copy link
Owner Author

danni-cool commented Dec 26, 2023 •
edited

@rcy1314 https://www.npmjs.com/package/@telepilotco/n8n-nodes-kv-storage?activeTab=readme 这个 key-value storage 适合n8n存储场景，执行时存储、工作流存储、全局存储，蛮灵活，不用一层层传递了

Jietu20231226-165157@2x

@danni-cool danni-cool linked a pull request Dec 27, 2023 that will close this issue
Feat friendship #95
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Feat friendship danni-cool/wechatbot-webhook
2 participants
@danni-cool @rcy1314