feat: Multi-account switching & self-hosted/on-premise instances

[Pecacheu]

Dependencies

• feat: Multi-user account switching #1217
• feat: Instance context to enable routes and reactivity w/ consistent interface #1315

Related Discussions

• feature request: Allow connecting to self-hosted instances through the client applications self-hosted#141
• [Feature] Allow users to select a different "master server" from stout.chat for-desktop#43
• feat: Basic framework for allowing selfhosted servers upon startup via Config for-desktop#55
• [Feature Request] Sign into multiple accounts/instances simultaneously #851
• Provide client assets through API and/or a dedicated configuration service stoatchat#471
• https://github.com/orgs/stoatchat/discussions/1073#discussioncomment-15783714
• https://github.com/orgs/stoatchat/discussions/1310

Current UI concept

Test this live at https://forestfire.net:420

Feel free to give it a test if you've got a self-hosted instance and let me know how it goes!

[Gtoasted]

I'm currently working on a similar feature, but instead of making an account switcher, I'm trying to make adding servers from other instances to the sidebar possible. I've done some preliminary work here, but I'm still far from finished.

I've actually been struggling to come up with a good way of managing things like user settings that are instance-specific but not server-specific, so maybe we can coordinate to make both features work together.

[Pecacheu]

I'm currently working on a similar feature, but instead of making an account switcher, I'm trying to make adding servers from other instances to the sidebar possible. I've done some preliminary work here, but I'm still far from finished.

I've actually been struggling to come up with a good way of managing things like user settings that are instance-specific but not server-specific, so maybe we can coordinate to make both features work together.

Interesting- I could see both of those features working together, yes. I think the way I'm handling swapping between user tokens could be extended to apply to other stored user settings too.

[Pecacheu]

Aight so @Gtoasted is now using an API call to fetch all the other endpoint URLs, so I can make a big improvement here UI-wise.

Old vs new:

Still experimenting with how to redirect all navigation though.

[Pecacheu]

Eureka, it actually works now! (Mostly)

[insertish]

This looks promising, I would update the wording to match:

This should also be accessible as a dialog/modal from a button, I'd say in the footer, rather than chucking it into the form (this also makes it look weird).

[Pecacheu]

This should also be accessible as a dialog/modal from a button, I'd say in the footer, rather than chucking it into the form (this also makes it look weird).

True. I was inspired by the collapsable UI found in some other login screens, but the text would probably fit much better inside a modal in this case. I'll give that a go.

This looks promising, I would update the wording to match

I like the proxy wording and used that, but personally I think the "on-prem" wording feels a bit too corporate. Not that we can't acknowledge corporate use, it is definitely a common use-case for on-premise hosting, I just feel it shouldn't be worded as if that's the only people who use it, confusing some poor guy just trying to sign into some self-hosted Minecraft server chat instance.

How about something like:

Use this option to connect to a self-hosted on-premise instance. This is useful for private communities or access-controlled corporate environments.

It's also still a good idea to have some sort of content hosting warning like above. It disavows any liability to certain types of content (you know which kind I mean) being discovered on some mega-creep's instance. #notalawyer but my pleb understanding is that in many jurisdictions, a clear warning needs to be shown to the user for this type of thing, i.e. a notice buried in some license policy doesn't count, it has to be something you click "OK" or "Accept" to. (Then again, clearly the "Here's a link to this 500 page ToS you obviously won't read, do you accept?" approach counts.) But please do reword it, again not an expert.

[Pecacheu]

This is pretty much ready and mostly tested now (though more testing is def appreciated!) so I'll go ahead and take it out of draft.

Also here is what the advanced options look like now as a modal:

[Pecacheu]

Known issue: There seems to be some overriding behavior happening with the settings stores- They write to the correct instance's store, but read still seems to pull from the base store. I suspect that the keys are being overwritten during the hydration phase.

[Taureon]

hey @Pecacheu are there any issues here that need resolving?
i wanna check if i can help here

[Pecacheu]

hey @Pecacheu are there any issues here that need resolving? i wanna check if i can help here

There is the one known issue above, tho it might be hard to solve without being familiar with the code already. I was planning to address it next time I have some time to work on Stoat stuff. Overall though this is looking pretty solid/stable, it has come a long way.

You can always help by simply testing it out and seeing if you run into any other issues, though!