Support multiple companion configurations (TCP-based profiles) #135

New Issue

2026-10-05T01:59:36+02:00

adam commented

2026-10-05 01:59:36 +02:00

Context

RemoteTerm connects to one radio via env vars (MESHCORE_SERIAL_PORT, MESHCORE_TCP_HOST, MESHCORE_BLE_ADDRESS, etc). Fine for a single fixed setup, but it doesn't really scale to more than one companion per host.

Wanted to float this as an idea and see if it's something you'd even want before anything happens.

Use case

I run two companions, both important, and they have very different roles.

The stationary one sits near a well-positioned repeater, always plugged in, and feeds MQTT plus an Apprise to Matrix bridge for the local community's public channels. Repeaters don't forward to MQTT, so a companion has to do it. This one is basically infrastructure: it catches all the public traffic from the area and pushes it into Matrix so people can follow along without being on the mesh themselves. It has to stay up 24/7.

The mobile one I carry with me for DMs and everyday use. Different identity, different location, different purpose.

Today the only way to do both is to run two separate RemoteTerm instances: two databases, two sets of fanout configs, two web UIs, two ports. It works, but it means duplicated config, no shared view of the mesh, and switching between them is a browser tab dance. Having them under one UI with a quick switcher would be a big quality-of-life win, and it would also make the Matrix-bridge setup a lot easier to recommend to other community members who currently have to juggle two instances themselves.

Rough idea

Something like: move companion config out of env vars and into the database, at least for TCP, so multiple companions can be registered and picked from the UI. A companions table, settings API for CRUD, first-run setup screen writing to the DB instead of reading env vars (env vars could stay as a fallback), a dropdown in the status bar to switch between configured companions.

It's probably a decent chunk of work though, and there are a few things that would need to be worked out:

Data scoping. Contacts, channels, messages, raw packets have no radio_id today. When switching companions, should the history stay shared (same mesh, probably fine) or get scoped per companion?
Identity. Every companion has its own private key, so switching changes your "self" on the mesh. The keystore is single-radio today.
Profiles vs parallel. Two rough directions:
- Profiles: one active companion at a time, switching means disconnect then connect. Simpler. Fanout (MQTT/Apprise/Matrix) follows the active companion and goes offline when you switch away.
- Parallel: multiple radio instances running at once (e.g. stationary always on for fanout, mobile switchable for viewing and sending). Matches the use case better, but a much bigger refactor. Radio manager, fanout, background tasks, and probably data scoping would all need to go per-radio.

Is this something you'd be interested in at all, or is running two instances the intended way to handle this?

## Context RemoteTerm connects to one radio via env vars (`MESHCORE_SERIAL_PORT`, `MESHCORE_TCP_HOST`, `MESHCORE_BLE_ADDRESS`, etc). Fine for a single fixed setup, but it doesn't really scale to more than one companion per host. Wanted to float this as an idea and see if it's something you'd even want before anything happens. ## Use case I run two companions, both important, and they have very different roles. The stationary one sits near a well-positioned repeater, always plugged in, and feeds MQTT plus an Apprise to Matrix bridge for the local community's public channels. Repeaters don't forward to MQTT, so a companion has to do it. This one is basically infrastructure: it catches all the public traffic from the area and pushes it into Matrix so people can follow along without being on the mesh themselves. It has to stay up 24/7. The mobile one I carry with me for DMs and everyday use. Different identity, different location, different purpose. Today the only way to do both is to run two separate RemoteTerm instances: two databases, two sets of fanout configs, two web UIs, two ports. It works, but it means duplicated config, no shared view of the mesh, and switching between them is a browser tab dance. Having them under one UI with a quick switcher would be a big quality-of-life win, and it would also make the Matrix-bridge setup a lot easier to recommend to other community members who currently have to juggle two instances themselves. ## Rough idea Something like: move companion config out of env vars and into the database, at least for TCP, so multiple companions can be registered and picked from the UI. A `companions` table, settings API for CRUD, first-run setup screen writing to the DB instead of reading env vars (env vars could stay as a fallback), a dropdown in the status bar to switch between configured companions. It's probably a decent chunk of work though, and there are a few things that would need to be worked out: 1. **Data scoping.** Contacts, channels, messages, raw packets have no `radio_id` today. When switching companions, should the history stay shared (same mesh, probably fine) or get scoped per companion? 2. **Identity.** Every companion has its own private key, so switching changes your "self" on the mesh. The keystore is single-radio today. 3. **Profiles vs parallel.** Two rough directions: - *Profiles:* one active companion at a time, switching means disconnect then connect. Simpler. Fanout (MQTT/Apprise/Matrix) follows the active companion and goes offline when you switch away. - *Parallel:* multiple radio instances running at once (e.g. stationary always on for fanout, mobile switchable for viewing and sending). Matches the use case better, but a much bigger refactor. Radio manager, fanout, background tasks, and probably data scoping would all need to go per-radio. Is this something you'd be interested in at all, or is running two instances the intended way to handle this?

adam closed this issue

2026-10-05 01:59:36 +02:00

adam commented

2026-10-05 01:59:37 +02:00

That is something I've considered. As you called out, though, the menagerie of issues that crop up around message history, continuity of identity, decrypting with two possible keys, etc. all start to get pretty darn crowded until the amount of work just doesn't make sense when it's trivial to spin up a second instance. I empathize with the loss of dual-radio-view-of-the-mesh but I just don't think the massive overhaul needed for this is proportional to the usage I think the feature would get, I'm sorry 🙁 I'm going to close this as not something I'm going to implement right now, but if there ends up being a critical mass of folks who do want this, I would be amenable to revisiting in the future!

That is something I've considered. As you called out, though, the menagerie of issues that crop up around message history, continuity of identity, decrypting with two possible keys, etc. all start to get pretty darn crowded until the amount of work just doesn't make sense when it's trivial to spin up a second instance. I empathize with the loss of dual-radio-view-of-the-mesh but I just don't think the massive overhaul needed for this is proportional to the usage I think the feature would get, I'm sorry 🙁 I'm going to close this as not something I'm going to implement right now, but if there ends up being a critical mass of folks who do want this, I would be amenable to revisiting in the future!

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/Remote-Terminal-for-MeshCore#135