clarify LXMF message format vs LXMF routing?

[khimaros]

am i understanding correctly that LXMF is a general purpose message format?

in documentation, it seems that the message format is a bit conflated with the routing functions provided by lxmd.

this makes it a bit tricky to build a mental block diagram for the reticulum network since it seems to create a dependency cycle.

disambiguating the two uses seems to produce something like:

• LXMF (message format) can be used standalone and is independent of Reticulum/RNS.
• LXMF (router) depends on RNS / Reticulum for mesh networking and LXMF (message format)
• NomadNet / Sideband depend on LXMF (router), and (transitively and directly) Reticulum and LXMF

am i interpreting the moving bits correctly?

[markqvist]

Hm, yes, this is not really very obvious from the available info. As I seem to keep on saying, the actual LXMF documentation is coming in the relatively near future ;) So please have a little more patience with me :)

Your interpretation is not far off, but there's some nuances that I feel are worth pointing out.

• The format can definitely be used independently, but it is very easy to use in the context of the Reticulum API, since all the necessary crypto primitives and such are right there. That being said, it would not be hard to create a small library completely independently of Reticulum, that could both generate and decrypt valid LXMF messages.
• The current implementation of the LXMF router depends quite tightly on Reticulum, since it uses the Reticulum API to handle almost everything related to transport, encryption and encoding.

So you could envision it as a structure like this:

• Reticulum provides reliable data transport and security over any kind of physical or virtual medium. It also provides various API functions for accessing this secure transport.
• LXMF is an application-layer protocol built on top of Reticulum.
• Applications (like Sideband and Nomad Network) can use LXMF to easily and universally send and receive messages.

I agree there is some opaqueness in the naming here though. Maybe a disambiguation of the naming would make sense? Something like LXMS (Lightweight Extensible Messaging System) for the protocol and system as a whole, and LXMF (Lightweight Extensible Message Format) for the packing format. I don't know if that would make more sense.

I am goint to transfer this to a discussion over on the general discussion board, since I think it will get more visibility and possibly some better input there.

[khimaros]

whoops! i realized i swapped LXMF and LXMS in my diagram. your diagram largely makes sense to me, though my brain seems to want LXMF to sit logically below LXMS since LXMF is a dependency of LXMS.

here's a link to the excalidraw in case you'd like to modify/run with this one: https://excalidraw.com/#token=RngIVRzMUlALsQC3mkg5m

[markqvist]

Yeah, I do get what you mean by that, it makes sense. In that case I just think I'd label it separately, since it is primarily handling the data structure of the messages, encoding/decoding and binary representation depending on transport medium (Reticulum link, single-packet, paper message, local storage, etc.). In the Python implementation, the LXMF message class handles encryption and decryption by calling the relevant API functions in Reticulum.

[khimaros]

maybe this helps clarify? maybe zeroing in on something :)

at least, i hope it is useful as a jumping off point!

[markqvist]

That makes sense to me!

[OtisByron]

I like the idea of separating the LXMF format. I am working on a project to simplify the JS8Call interface to a simple chat interface (and to make HF comms more programmatic accessible in the process) and I was looking at LXMF as a message format, but unfortunately the JS8Call bit rate is way too slow for RNS. It would be nice to use the LXMF format regardless.