Support Persistent Outbound Channels For Self-Hosted Deployments

[JohnCMcDonough]

I’ve been evaluating Eve for a self-hosted agent deployment and ran into a gap that seems worth discussing: support for persistent outbound channels, not just inbound HTTP / webhook-style channels.

In a self-hosted environment, you don't always want to expose a public endpoint to get events. The concrete use case for me is a connection from an agent running in a Docker container on a home server, to Discord.

With a persistent outbound connection, the agent can initiate and maintain the connection to the platform, receive messages/events over that connection, and reply back, without needing a public webhook endpoint or any inbound internet-facing route.

I was surprised this wasn't functionality supported by Eve out of the box, since it is supported using the chat-sdk (I thought required actually for Discord to receive messages?)

I know this is a fairly core change, but I believe that there's a number of platforms that support this model. Slack has a Socket Mode, Discord has their Gateway, Telegram has the getUpdates endpoint for polling.

I'm sure that you could use the Eve TypeScript client and Chat-SDK to bridge the gap, but that just seems like an extra step for people looking to get up and running quickly.

I think this would be a huge quality of life improvement for developers looking to test locally, as well as home-labbers looking to get something up and running without exposing a public endpoint.

Thank you for taking the time to read this post!

[AndrewBarba]

@JohnCMcDonough let me know what you think about this idea: #375

Feel free to comment on the PR directly

[JohnCMcDonough]

@AndrewBarba Thank you! I gave it a read, and I think that's a solid approach that addresses the problems described in this discussion!

I know that the Chat SDK already has a persistence layer, so it doesn't seem like that big of a deal if the gateway/subprocesses are left to manage that last-message-received cursor to appropriately handle restarts.

On that same subject though, are y'all leaving the model provider in charge of storing messages / thread state? I know that the /responses API handles storing / compacting thread state, but if we leave it up to model providers for the entire process, what happens if you have a model provider that only has an hour of retention on those? Is there a way of rehydrating that state from Eve?

I know that question is a little out of the scope of this discussion, but it does seem tangentially related.

[JohnCMcDonough]

My reading skills could use some work: https://vercel.com/docs/eve/concepts#durability

[abdinoor]

Big +1 to this feature. I would definitely use this.

My prior experience with this is OpenClaw which has Slack socket support (it might even be the default). With OpenClaw, it is reasonable to have every Slack channel message running through an LLM before acting. This is not a good idea for Eve. Instead I would want some kind of filtering tools and/or support for a fast+low-cost classifier to try and pick up and dispatch only relevant messages.

Filtering

• fuzzy match on agent name(s)
• thread mode: pick up all replies where agent is tagged on the root message
• other deterministic criteria for what messages should be acted-on (some false positives are OK here)

Classifier

• Classifier: simple true/false act-on-this-message
• Fast: primary consideration is keeping up with the conversation
• Low cost: classifier does not need a thinking model, etc.
• Good use case for an edge-hosted model