Manage ECA remotely

[ericdallo]

To upvote this issue, give it a thumbs up. See this list for the most upvoted issues.

Context

We could have a way to stop, send a prompt, approve tools, and others of running ECA session if connected somehow (IP / password?), having a webpage (maybe web.eca.dev) which in the future could have other features there like a ECA chat section.

More context discussed in clojurians here

Frontend web

• Probably a stateless frontend only page under github pages like eca.dev, but in a new domain (web.eca.dev?)
• This would be the first use case for a ECA web client, in the future we may have more features there like a own ECA chat.

Connection / configuration

• User configures on eca server side a remote enabled and optionally remote port, remote pasword configs
• When eca starts, it starts a webserver on that port and listen for requests in some endpoint
• On the web app, user specify the IP + password and then connects to a ECA process
• From there, the webapp keeps communicating via http, but we should have probably a way to receive messages from server and show in webui so maybe consider a websocket

Note: for this to work the server machine needs to be publicly available via internet (port forwarding etc).

Communication protocol

We can discuss if we should have different endpoints or a single one receiving different types of requests (stop session, start, tool approval etc).

[ericdallo]

FYI @zikajk

[rschmukler]

Excited to see this issue! Just chiming in with some thoughts here, some of which are just echoing what you said above:

Server Considerations

• In addition to considering a web socket consider using a SSE text/event-stream from the server. Basically all updates could come via that, while various commands are offered on either a single or many POST endpoints.
• I propose the stream endpoint take a ?replayFromIndex=0 that could be used on connect / reconnect to enable a UI to get caught up to the latest state. UIs that disconnect (eg mobile) can just provide their last known index to come back.

Client considerations

Ultimately I think if the API is rich enough we can let multiple different clients emerge and just link them for users to discover what works best for their needs. My thoughts on a wishlist for a client is below:

• For the WebUI it would be nice if it supported multiple sessions / eca servers. Frequently you want to work in multiple projects and just respond to whatever needs doing.
• Similarly, I could see the UI grouping by project where you have multiple eca servers running on different work trees all corresponding to the same project.
• A responsive UI (or dedicated mobile client) would be awesome.

Discovery / Multiplexing?

One thing that comes to mind, especially with the above, is that managing the configuration of multiple remote eca servers could become tedious, especially in the situation where you have a dynamic number (eg. each one corresponding to a git worktree) - It could be worth thinking through whether eca might be able to support some sort of registry (eg. a standalone endpoint that it fires a web hook to on server startup / shutdown). I could imagine a standalone eca-registry that handles multiplexing the event streams and facilities the work around maintaining the state of multiple eca chats, enabling richer multi-server clients to emerge.

[ericdallo]

Thank you @rschmukler, yeah I had most of that in mind, but haven't thought in the protocol details yet (endpoints etc), this would need more research indeed.
I see some important parts for the the remote page of the web UI that I would like to include:

• mobile friendly
• pluggable by eca session, but allowing to group different sessions and chats
• It should have updated the current state of the chat, if

About the registry, I don't see clearly how it would look like or work, but it's something we can leave for the future when things are more clear.

[rschmukler]

A few more thoughts:

1. It may be worth exploring adding ACP to eca. It looks like they are currently exploring what the "server" protocol looks like (it's currently stdio only) and depending on where they land it may make sense to implement what they land on for integration with the ecosystem at large.

2. If we do go the way of a custom protocol, the live event stream could keep track of whether an event is complete. I imagine that when you "replay" the events you only get the terminal events:

Eg imagine a response series:

{entity_id: 1, entity_type: message, sequence: 0, data: "Hel", terminal: false}
{entity_id: 1, entity_type: message, sequence: 1, data: "Hello wor", terminal: false}
{entity_id: 1, entity_type: message, sequence: 2, data: "Hello world", terminal: true}

In the event of replay the stream could be reduced to just the events that are terminal, allowing a client to avoid having to render all events and instead just be able to get to the "final" state:

/events?replayAt=0

{entity_id: 1, entity_type: message, sequence: 2, data: "Hello world", terminal: true}

[ericdallo]

1. It may be worth exploring adding ACP to eca.

I did some research a while ago and it looks would be hard to find a common adapter layer for it, there is too much overlap and I feel like ECA protocol extens better for editors having a central place in control (eca server), than being too generic affecting UX.
Also, I don't see helping that much this issue with ACP supporting non stdio protocol, it would need to have a server running in the same way locally

About replay

Yeah, ECA server does that already when you /resume, so we could probably re-use this logic when remotely connecting to a server
Or you have in mind using this replay in other stages/places?