[Bug]: Location tracking feature in sideband crashes Meshchat X

[johnysilvermon]

MeshChatX version

4.8.6

Release channel

Stable

Platform

Desktop (Electron)

Operating system

macOS

OS details (if Other)

tahoe 26.6

How did you install MeshChatX?

macOS app

What happened?

I'm sorry for all the reports today, but someone has to do it :)

Today a friend send me a 'share location' from sideband. I know nothing about sideband or tracking location requests (that wording isn't used in MCX options), so I went into the options for the chat and clicked 'share telemetry'. Which I felt must have the same thing? In anycase, when doing so, I noticed I could click these icons in the chat, and the UI froze. There's nothing in the logs i'm afraid, so i just restarted MCX.

When I restarted MCX and clicked the chat window with these messages, the window appeared blank. Totally blank, nothing. I hit Crtl+R out of habit and MCX crashed. Again.

I reloaded MCX and went back to that window, and now this notification icon (the red dot) is always on even if I mark 'all as read'. I can't quite share screenshots without doxxing myself or my friend, so bare with me. It has this icon in every messages from him now:

and clicking it starts the crash loop again. UI freeze -> restart -> blank window -> restart -> Notification dot forever on.

In addition, the terminology here is super confusing. Telemetry I thought was for sideband plugins to share sensor temperature of my own with my server on a private RNS network, not share my location like i would with whatsapp or imessage. There are options for 'location' in settings, but the telemetry option (which i turn on) is very unclear as to what it actually does (does it always share my location with everyone? only to those i share? if so why bother having a global switch?)

There are also 'map' options, but these talk about what i think is the map tab, which i'l mention another report.

What did you expect?

no crash :)

Steps to reproduce

as above

Logs or error output

i'm tailing the logfile and nothing appeared at all.

Checklist

• I searched existing issues to avoid duplicates
• I included my MeshChatX version, channel, operating system, and install method
• I can reproduce the issue with the steps above

[johnysilvermon]

Just wanted to add, it's actually a problem for other reasons. The current implementation uses store/forward, so even on a mac m3, due to darwin limitation a stamp will take 6.4 s average to generate, and 23.4 seconds at worst. So , if the other party goes offline and opportunistic delivery fails, you find yourself with a UI that generates a stamp a minute. If you had 2+ of these running concurrently, I'm not sure what would happen, but probably nothing good :)

I think a different implementation would be advisable, or disable the sending of telemetry altogether when opportunistic delivery is not possible.

[Sudo-Ivan]

Thank you for reporting all these issues and testing on MacOS as I dont have one to test MeshChatX on right now. I will look into all them and fix and test as much as I can with GitHub CI.

[Sudo-Ivan]

Fixed on dev branch and will be in next release v4.9.1:

• UI freeze and crash loop: Failed telemetry requests were triggering expensive propagation proof-of-work retries every minute. Location shares and TELEMETRY_REQUEST commands now use opportunistic delivery only and never fall back to propagation. Added a test confirming try_propagation_on_fail is false for telemetry sends.
• Blank chats and stuck unread messages: Missing or malformed telemetry coordinates could crash the renderer when .toFixed() was called. Coordinates are now validated before rendering using a shared lxmfTelemetryLocation helper for conversation entries and telemetry history items.