u/CognitionMass

As far as I can tell, this reference to "gravity" in the reticulum manual is new in version 1.4.2, it says:

"In Reticulum, encryption is gravity."

and introduces this new option:

"The gravity option specifies the pathing affinity of an interface. If not set specifically, and unless otherwise configured by default_gravity or autoconnect_interface_gravity, it defaults to 0. Positive values increase pathing affinity, and negative values decrease it."

I can't make heads or tails of what any of this means in practice or how it relates to reticulums existing systems.

It seems to indicate that it gives some control over to a node to decide the path to use for transmitting data. But as far as I was aware, transport nodes have complete control over routing via announces?

For anyone who doesn't know, in the reticulum manual, it suggests that any transport node using both a LoRa interface, and a public TCPIP interface should set the TCPIP interface as "Boundary" mode, and LoRa as "Access Point" to avoid the flood of announces overwhelming the LoRa interface. In effect, this means any announces recieved on the TCPIP interface would not be transported to the LoRa interface. Messaging is still supported because access point still allows devices residing on it to request path lookups for any destination hashes they have.

I've just been testing this today, and to my suprise, with both interfaces set to gateway, the LoRa interfaces does not get overwhelmed with announces.

I realised this is because, as per the manual, interfaces automatically limit announce traffic to, by default, 2 percent of available throughput or bandwidth.

I was able to test this in real time. I change the lora interface from a 250 khz at sf 11 to 500 khz at sp7 (a significant increase in available throughput), and found that all of a sudden the announces being transmitted on the LoRa side increased. Presumably, because RNS recognised the avalable throughput had increased; though still limited to 2 percent.

But all this got me thinking, why would you ever want to use stuff like Boundary mode in the first place? It seems it's not even necessary nor even really wanted in this scenario.

Title

Basically, I'm a bit confused on these different values. Specifically in the context of copying contacts between different lxmf client. There seems to be little to no standard in terms of which values to use to add a contact in an lxmf client.

for example, one client might want a destination hash, another night only export an lxma value, which is a completely different length to a destination hash.

For an open standard, the simple act of copying contacts between different devices with different clients seems to become difficult to impossible.