Increase contact limit of 300

[geekabit-nl]

There are quite a lot of MeshCore clients and repeaters around here, and I'm rapidly approaching the contact limit of 300. I know some of my friends have already gone over, and had to patch the firmware to accommodate this. Since the microcontrollers running MeshCore have plenty of RAM, would it be possible to increase the number of contacts? Or maybe make it configurable?

[mrlmuk]

I have experimented with this in the past.

The Seeed T1000E and Rak WisMesh Tag have the least available storage for an increase. It could maybe go to 400 but somewhere before 450 I started to see errors about the file system being full when it wasn't so it must be referring to the smaller one I cannot see.

The Xiao nRF have an extra 2MB of storage so in theory could handle much more but I'm sure I was told that the whole contact DB gets loaded into memory RAM. I have not run into any issues raising the limit on these but equally have not pushed it.

The Heltec v4 and v4 seem to have the most space. I have had nearly 1000 on these but that does not run well.

My point is, you can raise it a bit yourself but its not clear exactly what the limits are.

[hofmand]

Go to Settings > Contact Settings and uncheck Auto Add Contacts. Then remove all the contacts you don't need. You can still find them in your Discover Contacts list, the limitation is that you can't receive direct messages from them until you Add them.

[4np]

Right now the radio is the single source of truth, so whatever limits are imposed on the device firmware, those limits are replicated in the mobile client.

A mobile client could easily hold limitless contacts, and you may want to know about the devices you have discovered. In contrast, the radio is constrained and should impose a limit.

IMHO it would be better if the radio would never auto add contacts, and that it would rather be a manual action. The mobile app could just auto add new devices it has discovered. Marking the ones you are truly interested in could then add those to the radio so the radio can communicate with those contacts.

App and radio could (and probably should) be two separate things.

[mrlmuk]

The contact list is just a filter on inbound messages, you don't technically need it to receive or decrypt them but I assume the firmware discards them to avoid spam. You need it to know the name of the sender and for the public key to send back. Unless of course this works differently to most encryption which would be a bad thing.

The app and the firmware could absolutely handle contacts separately, I suggested this a long time ago along with a favourites / FIFO contact management on the firmware if you wanted that option.

If the app had a unified database of contacts you could import / export and share at will you could manage contacts a lot easier when switching between devices.

[4np]

You need it to know the name of the sender and for the public key to send back. Unless of course this works differently to most encryption which would be a bad thing.

That is only necessary for direct messages to a contact. If you only post in channels the channel key applies.

I suggested ... a favourites / FIFO contact management on the firmware

Rather than FIFO, I think a mechanism where long unseen contacts, get purged (unless favorited) would probably make sense on the firmware.

[timdj]

If contacts are only necessary for direct message why should we fill that list with repeaters then? Mine just reached maximum of 350 as well

[mrlmuk]

https://en.wikipedia.org/wiki/FIFO_and_LIFO_accounting

First In, meaning oldest, is First Out, removed from the list. FIFIOexcept favourites, means exactly what you have just described.

Think of it as a stack where every advert moves a contact back to the top of the stack making it Last In. The longer it has been since an advert for a contact was seen, the lower it gets on the stack. A previously unseen contact advert, added to the top, increases the size of the stack beyond its limit and makes the bottom one drop off. Favourites are exempt from this process, the stack is only the size of rest of the the available limit.

You are right, there is no need to fill your contact list with repeaters. This concept could be taken further by only adding the types of contact you want but not others.

[4np]

@mrlmuk , I think we all know what FIFO means :) The thing is that with contacts, First In would mean the first time you heard a contact, which can be months ago. But it is possible they sent their most recent packet a minute ago. A contact you heard once last week can actually be the one that should move out of the contact list if the other 299 contacts sent packets yesterday. So FIFO should apply to the contact activity rather than when you first heard them. We probably mean the same, just wanted to make it explicit.

@timdj knowing the repeaters can be useful to understand how packets are routed through the Mesh network or how far your messages reach, but absolutely not necessary to communicate. Probably less tech-savvy users couldn't care less about repeaters :) An option to specify what device types to auto-add could be useful:

Auto Add Contacts:

• companion
• repeater
• room server
• sensor

[mrlmuk]

We do mean the same, FIFO from the point of view of the adverts.
"The longer it has been since an advert for a contact was seen, the lower it gets on the stack."

[andyspoo]

T-Deck limit is only 180 for discovered devices. With an SD-Card installed the discovered devices should be moved to the card (if it's not already). It's nice to see the map populate more as new devices/people appear.

[liamcottle]

Most devices have a contact limit of 350, and the firmware now supports selecting which contacts types you want to add, along with being able to automatically overwrite the oldest non-favourite contact when the contacts list is full. I'll close this one out. Please see #1379 for more info.