Feature: Automatic mesh map upload (integration/fanout module) #71

New Issue

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

adam commented

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

Repeaters and room servers displayed on the meshcore map (https://meshcore.co.uk/map.html) need to be submitted via its API. This can be done manually through the meshcore app or automatically with https://github.com/recrof/map.meshcore.dev-uploader. It would be useful to add this as an integration for Remote Terminal, using the same methods as map.meshcore.dev-uploader.

Acceptance criteria:

A new fanout module processes incoming advertisement packets and uploads eligible nodes to the map API
Only nodes with a valid advertised location (lat/lon) are uploaded
Chat nodes (device_role == 1) are excluded; repeaters and room nodes are included
Uploads are rate-limited per node so the same node is not re-uploaded within a 1-hour window
The upload is signed using the local radio's private key, with the public key included in the payload
Radio parameters (frequency, bandwidth, spreading factor, coding rate) are read from the connected radio and included in the upload
The API endpoint URL is configurable, with the default being https://map.meshcore.dev/api/v1/uploader/node
No additional dependencies are introduced

Additional enhancements:

Optionally, a geofence can be configured (centre lat/lon + radius in km) so that only nodes within that area are uploaded; when disabled, all valid nodes are uploaded
Distance is calculated using the Haversine formula internally

Repeaters and room servers displayed on the meshcore map (https://meshcore.co.uk/map.html) need to be submitted via its API. This can be done manually through the meshcore app or automatically with https://github.com/recrof/map.meshcore.dev-uploader. It would be useful to add this as an integration for Remote Terminal, using the same methods as map.meshcore.dev-uploader. Acceptance criteria: - A new fanout module processes incoming advertisement packets and uploads eligible nodes to the map API - Only nodes with a valid advertised location (lat/lon) are uploaded - Chat nodes (device_role == 1) are excluded; repeaters and room nodes are included - Uploads are rate-limited per node so the same node is not re-uploaded within a 1-hour window - The upload is signed using the local radio's private key, with the public key included in the payload - Radio parameters (frequency, bandwidth, spreading factor, coding rate) are read from the connected radio and included in the upload - The API endpoint URL is configurable, with the default being https://map.meshcore.dev/api/v1/uploader/node - No additional dependencies are introduced Additional enhancements: - Optionally, a geofence can be configured (centre lat/lon + radius in km) so that only nodes within that area are uploaded; when disabled, all valid nodes are uploaded - Distance is calculated using the Haversine formula internally

adam closed this issue

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

adam commented

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

Generally, I like the idea! I would be hesitant to filter/geofence — if a node is heard, it advertised, and we should report it without monkeying with the data we send. (If there's a bigger picture you're thinking of or a reason I may not be getting, super open to hear it)

I think we can probably reuse a lot of logic here around packet parsing and signing, which we already have utilities for. We don't have an easy way to track the last advert time (for "don't pass on an advert for any user who already advert'd in the last 60 mins") that isn't race-condition-y as we write the advert we just got, but we can probably just introduce a module-level var to track that in.

I pinged Cisien at https://discord.com/channels/1343693475589263471/1477723940951429330/1486124354491383959 — want to make sure that making it one-click for people to submit data is a welcome thing for that endpoint. I would want to make sure we set our user agent to identify us (probably the version string we use in our community mqtt submissions) so that it's easy to spot us in logs/figure out if there's an issue with what we're submitting.

So, pending the greenlight for the people who run the map to throw more data at them, and with emphasis on reusing the parts of the system we've already got that can help with this, I'd say good to prep a PR.

Generally, I like the idea! I would be hesitant to filter/geofence — if a node is heard, it advertised, and we should report it without monkeying with the data we send. (If there's a bigger picture you're thinking of or a reason I may not be getting, super open to hear it) I think we can probably reuse a lot of logic here around packet parsing and signing, which we already have utilities for. We don't have an easy way to track the last advert time (for "don't pass on an advert for any user who already advert'd in the last 60 mins") that isn't race-condition-y as we write the advert we just got, but we can probably just introduce a module-level var to track that in. I pinged Cisien at https://discord.com/channels/1343693475589263471/1477723940951429330/1486124354491383959 — want to make sure that making it one-click for people to submit data is a welcome thing for that endpoint. I would want to make sure we set our user agent to identify us (probably the version string we use in our community mqtt submissions) so that it's easy to spot us in logs/figure out if there's an issue with what we're submitting. So, pending the greenlight for the people who run the map to throw more data at them, and with emphasis on reusing the parts of the system we've already got that can help with this, I'd say good to prep a PR.

adam commented

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

The geofencing is to prevent submitting nodes with coordinates that are so far away from your current location that it's impossible to be correct. For example, I sometimes see nodes appear on my app map that are a thousand miles away, due to the owner misconfiguring the lat/lon. Having a geofence for a few hundred miles from your set location would remove these outliers (that likely have erroneous information) from being submitted.

The geofencing is to prevent submitting nodes with coordinates that are so far away from your current location that it's impossible to be correct. For example, I sometimes see nodes appear on my app map that are a thousand miles away, due to the owner misconfiguring the lat/lon. Having a geofence for a few hundred miles from your set location would remove these outliers (that likely have erroneous information) from being submitted.

adam commented

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

PR created. Can see from the map the two green repeaters that were recently updated using the new integration.

PR created. Can see from the map the two green repeaters that were recently updated using the new integration. <img width="3181" height="1955" alt="Image" src="https://github.com/user-attachments/assets/c38aa9a3-f472-42a2-a272-7bd57adcf160" />

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