Consider preserving radio channels on connection #23

New Issue

2026-10-05T01:53:34+02:00

adam commented

2026-10-05 01:53:34 +02:00

Users might want to have their on-radio channels preserved. Downside: more event spam from decrypted room messages we don't care about, plus more processing time on the radio. Upside: we don't make users sad.

Users might want to have their on-radio channels preserved. Downside: more event spam from decrypted room messages we don't care about, plus more processing time on the radio. Upside: we don't make users sad.

adam closed this issue

2026-10-05 01:53:34 +02:00

adam commented

2026-10-05 01:53:35 +02:00

So this would be structurally difficult as we need predictable radio slots to send in channels in, which we currently load in and out for messages. We COULD do it where we assume that we know what's on the radio, but that could be unreliable for TCP radios that could swap/add channels, and generally means keeping track of remote state that could possible drift rather than guaranteeing we have good state each operation.

It could work, but it feels rickety. I will continue to think on this, and also run some message send perf tests to see if this would eliminate much overhead from message sending. If it did, this might be worth some rickety-ness for.

So this would be structurally difficult as we need predictable radio slots to send in channels in, which we currently load in and out for messages. We COULD do it where we assume that we know what's on the radio, but that could be unreliable for TCP radios that could swap/add channels, and generally means keeping track of remote state that could possible drift rather than guaranteeing we have good state each operation. It *could* work, but it feels rickety. I will continue to think on this, and also run some message send perf tests to see if this would eliminate much overhead from message sending. If it did, this might be worth some rickety-ness for.

adam commented

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

This is now done, in the best way we can, which may still overwrite channels if the radio is full.

This is now done, in the best way we can, which may still overwrite channels if the radio is full.

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#23