https://docs.all-hands.dev/ logo
Join Slack
Powered by
<@U06QFDJ1QQ2>: this is what we discussed the othe...
# proj-agent-canvas
b
@wooden-umbrella-84098: this is what we discussed the other day: https://github.com/OpenHands/agent-canvas/issues/1351
w
Is this motivated by using OpenHands/OpenHands app server as a backend? When you do that, all the conversations in that backend show up in the same list right?
There's a tough UX issue here--we've oriented around this box being a backend selector. If we show conversations from multiple backends, it breaks that pattern That said there are many reasons to want to see all your conversations in one place across backends @breezy-kilobyte-39430 would love to get your thoughts
c
Related, we had another request on seeing all backends, and a PR for it here I think:
I would note: the PR for deployment-provided backends is good for an addon to add, rather than integrating all backends view in the core agent-canvas
At a quick look, all primitives we want to offer in addons seem to be there
(I'm not sure about the app-server PR though)
w
Yeah I do think moving backends out of localstorage would be great. Just not sure how to do this securely We could store backends statically at 
backends.json
, and have a tiny API to update them. But that doesn't work well for 
--public
mode since it exposes all your credentials
we could make it so default uses 
backends.json
, and 
--public
uses localstorage
or we could build basic auth into the system
b
So, I actually thought about this a week or so ago, it's a hard UX problem given that if a user can see content from multiple backends how do we handle where new conversations start (what backend) and what llm profile is used when and where, etc. I think we could have an "all" setting in the selector that allows the user to see all conversations but then we'd need to make it explicit per new conversation and in a conversation what backend it is connected to.
nod 1
w
maybe a separate page where you can see all your convos?
👍 1
I want to be very thoughtful about breaking the mental model of backend separation
b
> Is this motivated by using OpenHands/OpenHands app server as a backend? Yes. > When you do that, all the conversations in that backend show up in the same list right? Yes.
> There's a tough UX issue here--we've oriented around this box being a backend selector. If we show conversations from multiple backends, it breaks that pattern Yeah, originally I considered 1 more level: backend > container > workspace > conversation. Then I noticed the convos are filtered by the backend selector box at the bottom. At least for my personal use cases, it's not a problem to separate conversations by backend.
I would note: the PR for deployment-provided backends is good for an addon to add, rather than integrating all backends view in the core agent-canvas
In https://github.com/OpenHands/agent-canvas/issues/1351 I proposed "grouping options" to enable/disable each level. If they are disabled by default the UI would look exactly the same as now.
> how do we handle where new conversations start (what backend) You would need to use the options to sort by "Chronological list" to see your new conversation on top. I would also sort backend, container and workspace (if visible/enabled) in such a way that the first node of each level contains the new conversation. Alternatively, you could just disable all "Group by" options to display a flat chronological list like we do right now.
w
ohh I see why you want this. Even when using OpenHands as the backend you're starting multiple convos per container
b
yes
2 Views
Open in Slack
PreviousNext
Powered by