Tunneling Briar messages

[SvenRuin]

I have seen that the combination/integration of Briar and Reticum has been discussed before, but as I understand the Briar team seems to have no ambitions in that direction. Now I'm wondering if would be possible to transport Briar messages via Reticulum, without participation of the Briar team? One idea is tunneling Briar messages between "islands" (where Bluetooth or WiFi is used locally), in a similar way as a VPN tunnel between a workstation and a server.

[faragher]

I don't know how Briar works, but in the island situation, generally, you'd need to write an application that acted as a server, sending and receiving Briar messages. If the destination was in a list on another island, the application would package the message and send it to the island's server over Reticulum. You would also have to develop a protocol for each server to synchronize the user list to know where to route it.

An alternative is to mimic a propagation node, where each island would have a local server, and they'd synchronize amongst themselves, storing all messages. When an application calls in and says "any messages for me?" the message is sent, marked for deletion, and then deleted locally. On next sync, the other servers see it's marked for deletion and wipe it from their own stores.

In either case, don't reinvent the wheel. You're passing messages around. The distribution nodes for LXMF do this, POP3 does this for email (and my own POPR for LXMF), and Usenet did it for arbitrary data. Find their protocols, see what works and what doesn't, and once you have your own requirements, build what you need.

[faragher]

Likely not. Reticulum needs routing information to operate, and Briar lacks this routing information. You'd either have to develop an application that routes betwen known users or an application that shares all messages with all similar applications and broadcasts them blindly.

Basically, look at how Briar uses TCP/IP and see how you can replace that with Reticulum.

[SvenRuin]

I realize that an application (plugin?) would be needed at each end of the tunnel, to handle for example the Briar messages by Bluetooth there and relaying messages. In the simplest form, the tunnel would go between two Reticulum/LXMF peers. Thus, the routing would be done by Reticulum, in a similar way as today between two known users.

[markqvist]

Also worth mentioning is the FIELD_CUSTOM field types defined in LXMF.py, intended for carrying arbitrary datatypes and encapsulating other protocols over LXMF:

# For usecases such as including custom data structures,
# embedding or encapsulating other data types or protocols
# that are not native to LXMF, or bridging/tunneling
# external protocols or services over LXMF, the following
# fields are available. A format/type/protocol (or other)
# identifier can be included in the CUSTOM_TYPE field, and
# the embedded payload can be included in the CUSTOM_DATA
# field. It is up to the client application to correctly
# discern and potentially utilise any data embedded using
# this mechanism.
FIELD_CUSTOM_TYPE      = 0xFB
FIELD_CUSTOM_DATA      = 0xFC
FIELD_CUSTOM_META      = 0xFD

[SvenRuin]

Thanks for the replies. Great to see that bridging/tunneling over LXMF was already envisioned! This concept should be useful for more than Briar. Mark, you have done a fantastic job!

[markqvist]

Thank you! I'm glad you found it useful!