Hi — I'm a v1.14.1 user who recently hit the 350 contact cap, and in digging into it I found several small UX issues that I think are connected. I did a search first so I'm not duplicating — related issues linked at the bottom.
1. Everything is called a "contact" — it's one big mixed list
Contacts, repeaters, room servers, and sensors all live in the same list in the app. On a busy mesh, most of my list ends up being repeaters I've never routed through, with the actual people I message buried in the middle.
The CLI already classifies contacts by type internally (1=client, 2=repeater, 3=room, 4=sensor), so the data is already there — it just isn't surfaced in the app UI.
Suggestion: Split the contact screen into sections or tabs by type — People, Repeaters, Rooms, Sensors. No schema change, just surfacing what the system already knows. It would also make cleanup decisions much easier because users can see at a glance what's actually in their list.
2. Hitting the 350 cap silently drops incoming DMs
When the contact list fills up, new contacts get rejected and new incoming DMs can be silently dropped (see #1311). For a comms tool, "you stopped receiving messages and we didn't tell you" is a really bad failure mode.
I know FIFO eviction was supposedly added in #1379 (closing #931), but on v1.14.1 I'm still hitting a hard wall where new contacts are refused. Either it isn't enabled by default or it isn't working as intended in this code path.
Suggestion: Auto-purge of the oldest non-favorite contact should be the default on behavior when the list is full, with a toggle to disable it for users who want strict manual control. A full list should never silently break messaging.
3. Favoriting is entirely manual, which doesn't scale
Right now a contact only becomes "sticky" if the user manually stars it. Most users don't favorite anything until they've already hit the cap — and by then the list is a mess and they don't know where to start.
Suggestion: Auto-favorite a contact after it's been heard or interacted with some number of times (configurable, maybe default 5–10). That turns the list into a self-organizing cache — nodes you encounter regularly stick around, one-off travelers age out, and manual favoriting still works as an override when you want it.
4. The word "advert" is confusing for non-technical users
Smaller point, but worth flagging. The term "advert" in the app is hard to understand if you aren't already familiar with networking terminology. When a new user sees something like "advert received" it isn't obvious what that means, and for some readers it even sounds like commercial advertising. It makes the app feel less approachable for people coming in without a tech background.
I'm not suggesting a specific replacement — just flagging that the current term isn't friendly to new users and might be worth rethinking in the app UI.
Why these together
Individually each one is a papercut. Together they'd turn contact management from "a thing you have to manually curate before it silently breaks" into "a thing that mostly takes care of itself." The heaviest lifts are already done — the data model knows the types, FIFO logic has already been written — this is mostly about surfacing and defaulting things correctly.
Related
Running v1.14.1-467959c. Happy to test anything on real hardware if it helps.
Hi — I'm a v1.14.1 user who recently hit the 350 contact cap, and in digging into it I found several small UX issues that I think are connected. I did a search first so I'm not duplicating — related issues linked at the bottom.
1. Everything is called a "contact" — it's one big mixed list
Contacts, repeaters, room servers, and sensors all live in the same list in the app. On a busy mesh, most of my list ends up being repeaters I've never routed through, with the actual people I message buried in the middle.
The CLI already classifies contacts by type internally (1=client, 2=repeater, 3=room, 4=sensor), so the data is already there — it just isn't surfaced in the app UI.
Suggestion: Split the contact screen into sections or tabs by type — People, Repeaters, Rooms, Sensors. No schema change, just surfacing what the system already knows. It would also make cleanup decisions much easier because users can see at a glance what's actually in their list.
2. Hitting the 350 cap silently drops incoming DMs
When the contact list fills up, new contacts get rejected and new incoming DMs can be silently dropped (see #1311). For a comms tool, "you stopped receiving messages and we didn't tell you" is a really bad failure mode.
I know FIFO eviction was supposedly added in #1379 (closing #931), but on v1.14.1 I'm still hitting a hard wall where new contacts are refused. Either it isn't enabled by default or it isn't working as intended in this code path.
Suggestion: Auto-purge of the oldest non-favorite contact should be the default on behavior when the list is full, with a toggle to disable it for users who want strict manual control. A full list should never silently break messaging.
3. Favoriting is entirely manual, which doesn't scale
Right now a contact only becomes "sticky" if the user manually stars it. Most users don't favorite anything until they've already hit the cap — and by then the list is a mess and they don't know where to start.
Suggestion: Auto-favorite a contact after it's been heard or interacted with some number of times (configurable, maybe default 5–10). That turns the list into a self-organizing cache — nodes you encounter regularly stick around, one-off travelers age out, and manual favoriting still works as an override when you want it.
4. The word "advert" is confusing for non-technical users
Smaller point, but worth flagging. The term "advert" in the app is hard to understand if you aren't already familiar with networking terminology. When a new user sees something like "advert received" it isn't obvious what that means, and for some readers it even sounds like commercial advertising. It makes the app feel less approachable for people coming in without a tech background.
I'm not suggesting a specific replacement — just flagging that the current term isn't friendly to new users and might be worth rethinking in the app UI.
Why these together
Individually each one is a papercut. Together they'd turn contact management from "a thing you have to manually curate before it silently breaks" into "a thing that mostly takes care of itself." The heaviest lifts are already done — the data model knows the types, FIFO logic has already been written — this is mostly about surfacing and defaulting things correctly.
Related
Running v1.14.1-467959c. Happy to test anything on real hardware if it helps.