Feature request: tag nodes/messages with a location name from the ingestor for map display #219

New Issue

2026-10-04T23:04:32+02:00

adam commented

2026-10-04 23:04:32 +02:00

Idea

The motivation for this comes from wanting to add a city that is far from our current installation (meshtastic), but that city doesn't have enough nodes to justify deploying its own separate PotatoMesh instance. So instead of running a full instance per city, it would be simpler to feed that city's nodes into our existing instance via their own ingestor, listening on the local LongFast/MediumFast channel.

Right now there's no way to tell, on the map or in the chat, which city/location a node or message actually came from — everything is shown the same way regardless of which ingestor/channel reported it.

It would be useful if each ingestor could tag its own data with a location label (e.g. a LOCATION_NAME env var, similar to INSTANCE_DOMAIN/ API_TOKEN), and the web app would then show that label on the map and next to chat messages, so nodes/messages from a different city are easy to recognize at a glance — without needing a full separate instance for a small number of nodes.

Would be curious to hear if this fits the project's direction, or if there's already a preferred way to achieve this that I'm missing.

### Idea The motivation for this comes from wanting to add a city that is far from our current installation (meshtastic), but that city doesn't have enough nodes to justify deploying its own separate PotatoMesh instance. So instead of running a full instance per city, it would be simpler to feed that city's nodes into our existing instance via their own ingestor, listening on the local LongFast/MediumFast channel. Right now there's no way to tell, on the map or in the chat, which city/location a node or message actually came from — everything is shown the same way regardless of which ingestor/channel reported it. It would be useful if each ingestor could tag its own data with a location label (e.g. a `LOCATION_NAME` env var, similar to `INSTANCE_DOMAIN`/ `API_TOKEN`), and the web app would then show that label on the map and next to chat messages, so nodes/messages from a different city are easy to recognize at a glance — without needing a full separate instance for a small number of nodes. Would be curious to hear if this fits the project's direction, or if there's already a preferred way to achieve this that I'm missing.

adam closed this issue

2026-10-04 23:04:32 +02:00

adam commented

2026-10-04 23:04:33 +02:00

In general, the idea is the federation. If two mesh hubs are too far apart, they should have their own potatomesh instance. We cannot prevent multiple ingestors from different hubs and that is fine but it is pretty much out of scope for this app which focuses local mesh activity and works pretty much isolated.

That said, it wouldn't be too hard to tag nodes with an ingestor and other metadata. The crux is, I honestly have no idea how to add this to the User Interface. We already serve a lot of information on very little space. Any suggestions?

In general, the idea is the federation. If two mesh hubs are too far apart, they should have their own potatomesh instance. We cannot prevent multiple ingestors from different hubs and that is fine but it is pretty much out of scope for this app which focuses local mesh activity and works pretty much isolated. That said, it wouldn't be too hard to tag nodes with an ingestor and other metadata. The crux is, I honestly have no idea how to add this to the User Interface. We already serve a lot of information on very little space. Any suggestions?

adam commented

2026-10-04 23:04:33 +02:00

You might be right that this isn’t something PotatoMesh should support, and maybe separate instances are the better long-term solution.

The main idea behind my suggestion was to make it easier for smaller or remote communities that don’t yet have enough activity to justify running their own instance.

For the UI, I wasn’t thinking about adding more information to each message or node directly. Instead, maybe the existing chat tabs could simply be generated per ingestor/tag. For example, if an ingestor had a tag (or LOCATION_NAME) configured, the UI could show:

MediumFast (City1)
LongFast (City1)
MediumFast (City2)
LongFast (City2)

That way the interface would stay almost identical to what it is today, while making it immediately obvious which local mesh a conversation belongs to. It would also avoid cluttering the map or every chat message with additional labels.

Just a thought, though—I understand if this is outside the intended scope of the project.

You might be right that this isn’t something PotatoMesh should support, and maybe separate instances are the better long-term solution. The main idea behind my suggestion was to make it easier for smaller or remote communities that don’t yet have enough activity to justify running their own instance. For the UI, I wasn’t thinking about adding more information to each message or node directly. Instead, maybe the existing chat tabs could simply be generated per ingestor/tag. For example, if an ingestor had a tag (or LOCATION_NAME) configured, the UI could show: * MediumFast (City1) * LongFast (City1) * MediumFast (City2) * LongFast (City2) That way the interface would stay almost identical to what it is today, while making it immediately obvious which local mesh a conversation belongs to. It would also avoid cluttering the map or every chat message with additional labels. Just a thought, though—I understand if this is outside the intended scope of the project.

adam commented

2026-10-04 23:04:34 +02:00

This is something, unfortunately, that would go against the purpose of the software and would cause too much friction in the design to implement. I'm sorry.

This is something, unfortunately, that would go against the purpose of the software and would cause too much friction in the design to implement. I'm sorry.

adam commented

2026-10-04 23:04:35 +02:00

All good, thx!

All good, thx!

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/potato-mesh#219