room servers #46

New Issue

2026-10-05T01:54:56+02:00

adam commented

2026-10-05 01:54:56 +02:00

They exist. We don't support them. That's bad.

They exist. We don't support them. That's bad.

adam closed this issue

2026-10-05 01:54:56 +02:00

adam commented

2026-10-05 01:54:57 +02:00

now you do - great work 👍

retrieval of missed messages is quite laggy, but that's very most likely related to the latency of the mesh itself. (I've been experiencing this with official App as well).

But one thing you could do better than official app is message ordering!

If you enter a room and send a message while on roomserver-side there are unsynced messages, it can get quite confusing as these messages get synced over time but are not in line with the messages you sent. There should be some ordering applied based on timestamp so that retrieved messages older than the one(s) just sent to the server will be inserted before those in the timeline.

now you do - great work 👍 retrieval of missed messages is quite laggy, but that's very most likely related to the latency of the mesh itself. (I've been experiencing this with official App as well). But one thing you could do better than official app is message ordering! If you enter a room and send a message while on roomserver-side there are unsynced messages, it can get quite confusing as these messages get synced over time but are not in line with the messages you sent. There should be some ordering applied based on timestamp so that retrieved messages older than the one(s) just sent to the server will be inserted before those in the timeline.

adam commented

2026-10-05 01:54:58 +02:00

Duly noted -- I'll see if I can figure that out.

Duly noted -- I'll see if I can figure that out.

adam commented

2026-10-05 01:54:58 +02:00

Potential issue spotted in a pre-pass -- if the room server's time is wrong, the packets will be wrong, which could mean that we end up with packets that are far in the future or the past relative to our own. Sorting packets by receipt time rather than the room server-chosen time means that we keep our messages in a relatively sane order. Maybe that's not super important; maybe we offer it as a toggle option.

Potential issue spotted in a pre-pass -- if the room server's time is wrong, the packets will be wrong, which could mean that we end up with packets that are far in the future or the past relative to our own. Sorting packets by receipt time rather than the room server-chosen time means that we keep our messages in a relatively sane order. Maybe that's not super important; maybe we offer it as a toggle option.

adam commented

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

We can keep the message order, all we need to figure out is whether there are pending messages when we just entered the room and keep messages that we send right after we enter the room server while it hasnt finished sending unsynced messages at the end of the timeline, inserting these incoming pending messages before them. It only gets troublesome if someone in the room already replied to our new messages while the sync hasnt finished yet 🤔

Is there a way to determine the server time? Or the number of unsynced messages?

We can keep the message order, all we need to figure out is whether there are pending messages when we just entered the room and keep messages that we send right after we enter the room server while it hasnt finished sending unsynced messages at the end of the timeline, inserting these incoming pending messages before them. It only gets troublesome if someone in the room already replied to our new messages while the sync hasnt finished yet 🤔 Is there a way to determine the server time? Or the number of unsynced messages?

adam commented

2026-10-05 01:55:00 +02:00

We do have access to the original sender time, yes (assuming their clock is correct). We have no idea how many unsync'd messages there are; they are pushed out by the room server itself. We don't know when it's done.

We do have access to the original sender time, yes (assuming their clock is correct). We have no idea how many unsync'd messages there are; they are pushed out by the room server itself. We don't know when it's done.

adam commented

2026-10-05 01:55:00 +02:00

Ok, then I'd just assume the sender's clock is correct and insert all incoming messages before/after outgoing messages according to these timestamps.

This would at least mitigate confusion for the majority of people with correct clocks.

I guess this all can be implemented solely in the frontend and it may be worthwhile to add a simple toggle switch to order by received sequence vs. order by timestamp.

Ok, then I'd just assume the sender's clock is correct and insert all _incoming_ messages before/after _outgoing_ messages according to these timestamps. This would at least mitigate confusion for the majority of people with correct clocks. I guess this all can be implemented solely in the frontend and it may be worthwhile to add a simple toggle switch to order by received sequence vs. order by timestamp.

adam commented

2026-10-05 01:55:01 +02:00

I've made a branch to do this at fix-room-server-ordering. If you're up for it, feel free to check it out and rebuild your frontend and it should do what you're expecting. I'm away from my radios right now so am not going to commit it to main until you test OR sometime next week once I'm back and can set up a room server (so no pressure; I'll get to it eventually).

I've made a branch to do this at `fix-room-server-ordering`. If you're up for it, feel free to check it out and rebuild your frontend and it should do what you're expecting. I'm away from my radios right now so am not going to commit it to main until you test OR sometime next week once I'm back and can set up a room server (so no pressure; I'll get to it eventually).

adam commented

2026-10-05 01:55:02 +02:00

Investigating..... and waiting for pending room server messages to occur somewhere....

What I don't like so far is the UI change: no more permanent indication of successful login and "Refresh ACL login" needs 3 clicks now (open tools, refresh acl, close tools) instead of only 1.

Investigating..... and waiting for pending room server messages to occur somewhere.... What I don't like so far is the UI change: no more permanent indication of successful login and "Refresh ACL login" needs 3 clicks now (open tools, refresh acl, close tools) instead of only 1.

adam commented

2026-10-05 01:55:03 +02:00

Hmm maybe I need to dig in more into the room server auth lifecycle. I assumed it was like repeaters where you only ever need to login with password once, and then from there on you just use the ACL login and you're good to go. Will take a look.

Hmm maybe I need to dig in more into the room server auth lifecycle. I assumed it was like repeaters where you only ever need to login with password once, and then from there on you just use the ACL login and you're good to go. Will take a look.

adam commented

2026-10-05 01:55:03 +02:00

Hm.... to me it appears like ACL login is not always successful - either because it's not received by the server or because client didn't receive ACK from server.

Hm.... to me it appears like ACL login is not always successful - either because it's not received by the server or because client didn't receive ACK from server.

adam commented

2026-10-05 01:55:04 +02:00

Yeah there's a tradeoff there. Would you rather be gated/blocked from being able to send messages until we guarantee we've heard a successful login confirm?

Yeah there's a tradeoff there. Would you rather be gated/blocked from being able to send messages until we guarantee we've heard a successful login confirm?

adam commented

2026-10-05 01:55:05 +02:00

Maybe it's enough to look at message ACK from server in case of missing login ACK.

Message ACK => login successful
No message ACK => login likely failed

But still there should be a note and a button to refresh ACL if login was not confirmed.

Maybe it's enough to look at message ACK from server in case of missing login ACK. Message ACK => login successful No message ACK => login likely failed But still there should be a note and a button to refresh ACL if login was not confirmed.

adam commented

2026-10-05 01:55:05 +02:00

Okay I've overhauled room server ops, and it should be much, much clearer now. Lemme know what you think.

Okay I've overhauled room server ops, and it should be much, much clearer now. Lemme know what you think.

adam commented

2026-10-05 01:55:06 +02:00

Okay I've overhauled room server ops, and it should be much, much clearer now. Lemme know what you think.

looks good to me - great job!

> Okay I've overhauled room server ops, and it should be much, much clearer now. Lemme know what you think. looks good to me - great job!

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