better propagation autoselect

[slg407]

a lot of propagation nodes are non-functional (not a columba issue, it happens on every reticulum messenger app), meaning that autoselecting the nearest node most times causes messages to either be stuck sending (because the propagation node cannot be reliably reached) or fail, and when retrieving messages you can wait indefinitely.

to fix this i propose that:

after one or two failed attempts (to either sync or propagate a message) columba moves on to the next prop node on the list of closest nodes, until the message goes through, this will make auto-select way more reliable, another idea is to use a propagation sync whenever a node is autoselected to check connectivity, if it fails autoselect automatically moves on to the next node on the list, thus impeding the issue from occurring in the first place

[torlando-tech]

I remember running into a similar issue early in Columba's development, in which it seemed like perhaps propagation nodes on some older version of reticulum or lxmf were incompatible with newer clients, perhaps something that was visible from announce data? It's been too long and I can't remember now, but I'll look into this. Thanks for raising it.

[slg407]

I remember running into a similar issue early in Columba's development, in which it seemed like perhaps propagatin nodes on some older version of reticulum or lxmf were incompatible with newer clients, perhaps something that was visible from announce data? It's been too long and I can't remember now, but I'll look into this. Thanks for raising it.

nowadays its better FOR SURE, but the issue still exists, and sometimes the nodes are in fact otherwise functional, (they route paths correctly, pinging them also works fine) they just don't work when you try using them as propagation nodes, while columba is way better at selecting prop nodes it doesn't always work and selecting them manually after auto-select decides it wants specifically the one node that is closest but that doesn't work instead of one that works but is a bit further kinda defeats the purpose of auto-select

[slg407]

@torlando-tech i fucked it up and accidentally closed the issue, fat thumbs 👎

[torlando-tech]

and sometimes the nodes are in fact otherwise functional, (they route paths correctly, pinging them also works fine) they just don't work when you try using them as propagation nodes

Do remember that LXMF propagation nodes are an entirely independent thing from Reticulum transport nodes. lxmd needs an instance of Reticulum (usually rnsd) to work, but not vice versa. Path routing is a function of Reticulum transport, not lxmd.

[slg407]

and sometimes the nodes are in fact otherwise functional, (they route paths correctly, pinging them also works fine) they just don't work when you try using them as propagation nodes

Do remember that LXMF propagation nodes are an entirely independent thing from Reticulum transport nodes. lxmd needs an instance of Reticulum (usually rnsd) to work, but not vice versa. Path routing is a function of Reticulum transport, not lxmd.

it is still a strange design choice to me, considering that reticulum is based on zero trust, so having such a fundamental feature like propagation nodes be limited in this way is very odd, as it basically turns them into bottlenecks/points of failure, you need to trust a propagation node to be reliable, to be accessible and to function properly, to me the way propagation node selection functions in LXMF is a very big oversight, and is in my opinion the most glaring issue with the protocol as a whole