rns.recipes

Hi all!

I noticed that "Content Destinations, and easy to use API for group messaging and discussion threads" was listed on the roadmap for LXMF. This sounds really exciting to me, especially if it could be implemented in a local way that works for small intermittently connected networks (like a large group of friends that occasionally come within radio range of each other). I don't have the skills to implement this myself, but I thought I would at least share my thoughts. Take the following with a grain of salt, I am certainly no network engineer and I am guessing that Mark already has better plans for how to do all this, but it was fun to think about!

The basic idea:

1. Users create content.
2. Users decide which content they are willing to share (contributing to the network, similar to a torrent).
3. Users request and receive content from other users.

An implementation idea:

1. Users create content in the format of an LXMF message. This can include anything that you can turn into an LXMF message. This content could also reference other pieces of content (by hash) such as a comment on a post or a reply to a message. The flexibility of LXMF is already enough here.
2. Users control who they send this content to, and to some degree, who can share it. If you receive and decrypt an LXMF message you can always verify it's origin even if you are not the indented recipient of the message. This is a limitation of including signatures in LXMF messages (this could be fixed by relying on a Diffie-Hellman key exchange to verify the authenticity of messages "off the record", that is to say that the recipient could simulate a valid signature). Anyways, a reasonable LXMF node wouldn't accept a message that wasn't addressed to it and no-one would send such a message, so this isn't a problem in practice. Instead, users could indicate how widely they want their content to be shared by including additional signatures in the LXMF message. Let's define three different publicity levels:
   • Public: This content is public and anyone can share it. For a public message, they simply attach a signature of the content to the LXMF message, which allows for it to be shared easily and verified by anyone.
   • Local Only: Only designated "local" users can share the message up to a number n hops away from the creator. For a local only message, we can attach a special "proxy signature" that says: "This message is valid if shared by 6b3362bd2c1dbf87b66a85f79a8d8c75" to the message, which indicates that a message is only valid if the recipient received it from that specific identity. This restricts who can share the message to only one hop. These proxy signatures could be extended in a chain to allow for a message to be shared only n hops from the creator. That is, the first signature indicates: "This message is valid if shared via a chain with less than n hops starting from 6b3362bd2c1dbf87b66a85f79a8d8c75", then each identity that shares the content must append their signature for the message to be valid, restricting the number of hops that it can be shared. If you configure your node to only grant these proxy signatures to other nodes you see over local radio links, then you could build a "six degrees of Kevin Bacon"-style social graph to help prevent bots and limit the reach of propaganda.
   • Private: This content is not to be shared by other users (it is a direct messages). No additional signature is attached, it's just a standard LXMF message.
3. Users decide which content they are willing to share (and who they are willing to share it with). This could be done in a very user friendly way similar to the "boost" button in mastodon.
4. Users announce their identity and the identities of a short list of other users whose content they are willing to share.
5. Other users request a list of content hashes. This list can be broken into chunks with checksums to prevent unnecessary data transfer.
6. Other users can then request each of the individual pieces of content based on these hashes. The content can be collected from many different users across the network allowing high bandwidth utilization similar to a torrent (announces make trackers unnecessary).
7. Users collect content from other users and add it to there list to share and contribute back to the network.

About Content Destinations:

• Destination addresses should not be derivable from the content, because this breaks the encryption and routing of reticulum and sending all request to the most recent announce would not be a good load balancing idea.
• Instead the destination should be derived from any identity and then contain the hash of the content in the announce packet. We already send out an announce for LXMF nodes so including a short list of 10-20 hashes in the announce data is an elegant solution. We can also include other identities here in indicate that we have content from that identity available. Which hashes to include in each announce should be dynamically calculated based on which content is not already available on the network by listening to announce traffic and keeping a table of hashes and where to get them.
• Then other LXMF nodes can request a hash list encoded in blocks (or not depending on link status) with checksums at the start and end to allow for partial syncing. Then with the hash list other nodes are free to request the content.
• Additionally the protocol for requesting hash lists should allow for filters by identity (LXMF address, origin, timestamp, hash index and so on) to allow for more efficient syncing and for users to search for specific content, such as content related to a forum, group chat, or identity.

TLDR,
I have some ideas about content destinations, but I am very excited regardless of how they are implemented. Having content destinations could allow for networks of local-first communities to be built on reticulum in a way that allows them to be preserved even after the original organizers leave and I think that will allow more people to use reticulum to do amazing things.