Sneakernet support

[mofosyne]

It be interesting if messages can be passed between node via flash drive or sd card

[sparkes]

Oddly, my first idea on seeing the project was using QR codes to pass messages via the most improbable routes possible.

[markqvist]

This already works :) LXMF fully supports "paper messages", which is encrypted messages passed via QR codes or lxm:// URIs. This functionality is already available in both Sideband and Nomadnet, and any other LXMF client can implement it easily using the available API functions in the LXMF library.

[markqvist]

Full sneakernet support for the LXMF protocol is on the roadmap, but in a limited way, it's already possible:

• Set up an LXMF propagation node on a portable device, make sure auto-peering is enabled
• Have it automatically connect to RNS-enabled WiFi networks at various locations.
• Start out at location A, when the portable node announces there, any local LXMF propagation nodes will sync with it within a reasonable amount of time. If the propagation node is running within Nomadnet, the sync can be initiated manually from the TUI of nomadnet. The portable node now has messages from A on its local storage
• Move to another location, that is physically disconnected from A. The portable node automatically connects to WiFi there (or whatever else you'd want to use), and will initiate LXMF syncs with any available propagation nodes it knows there.

There's a lot of things that can be made easier and streamlined about this, and a full implementation is coming at some point (when I have the time and funds to do it), but at least it works in a somewhat limited fashion already.

[mofosyne]

You may still want to support the lower tech option of a paper sneakernet but your above idea is convenient if set up well.

However you can argue that there might be a very narrow case of paper or usb sneakernet that may still be very handy to keep in technology denied area (e.g. disasters or goverment repression). In this case, the lower tech option should be preferred.

Personally I just want to see it since it be cool, but I don't think we should overthink it as this is not likely a common use case. Just keep it simple and easy to maintain. So paper QR code would be preferred. (Btw... I'm hoping for a common standard for leaving 'QR code' dead drop for geocaching purpose... so if anyone is interested... I would love to figure out a reliable common standard for encoding a simple website into paper)

[faragher]

Rule of cool aside, paper messages are not the greatest ways of getting past people looking to stop you. Rather than getting a document, concentrating on it, and processing it, it's much lower profile to walk into a diner, have a meal, and leave, hundreds of megs heavier due to wireless transfer from a local node or another patron.

But it is cool. Since a QR code (or the PDF417, my personal favorite) is simply data, all it needs is a processor. It provides links with a http:// prefix and LXMF paper messages are lxm:// prefixed, then the data (IIRC).

So what you'd need is a prefix, a program that handles it, and the data. I'd suggest not sending full HTML, but maybe a compressed archive or just fields to be reconstructed, but you could probably get something up and running pretty quick with the right specification.

A maximum size of 3k is pretty low by modern bloated HTML standards, but you could get a lot of text, data, and even an image or two in there if you really tried.

[KenSamson]

Full sneakernet support for the LXMF protocol is on the roadmap, but in a limited way, it's already possible:

• Set up an LXMF propagation node on a portable device, make sure auto-peering is enabled
• Have it automatically connect to RNS-enabled WiFi networks at various locations.
• Start out at location A, when the portable node announces there, any local LXMF propagation nodes will sync with it within a reasonable amount of time. If the propagation node is running within Nomadnet, the sync can be initiated manually from the TUI of nomadnet. The portable node now has messages from A on its local storage
• Move to another location, that is physically disconnected from A. The portable node automatically connects to WiFi there (or whatever else you'd want to use), and will initiate LXMF syncs with any available propagation nodes it knows there.

There's a lot of things that can be made easier and streamlined about this, and a full implementation is coming at some point (when I have the time and funds to do it), but at least it works in a somewhat limited fashion already.

Long note full of food for thought.... it's possible some of these ideas are too complex to make reliable.

In one idea, one would be able to list in the config file of a fixed station a list of traveling LXMF nodes used for sneaker net. I could also list in the traveling node the list of fixed nodes that I want to auto sync with. (to create a closed network) Once my station sees that traveling node announce, automatically initiate a sync.

So in that case all you would really have to do is set the traveling node to announce fairly often (perhaps it could announce only over the RNODE interfaces very often) and then any stations that hear it could reply. If you want to make it super classy, read the local telemetry and have in the traveling config file GPS coordinates, and when I am xyz close to those coordinates, then you know to announce.

The next challenge is one I see where if 50 stations are in a Highrise complex and I pull up an announce, how do we make order out of the chaos of 50 nodes wanting to reply at the exact same time? Well, if I listed a fixed node address, then the coordinates, my traveling node could call out to each of the fixed nodes by "name" with a sync request specific to that fixed node, meaning there is zero chance of creating a traffic jam, and I'm not driving all over town spewing announces. I suppose we could use a button the screen or a physical button to initiate an announce as well.

It is possible that someone might want to be able to transport and sync LXMF 100% anonymously and randomly, and maybe even enable a traveling to traveling sync as well. (two friends have lunch in a central town once a week and exchange messages between populations of people in each of their respective towns)

If I were doing this on a raspberry pi mobile node, I would want to fire off a routine when I'm about to initiate a sync, fire off another routine when I get a reply and are working the sync, and then fire off something when I'm done. In my brain I would use the physical IO header in the PI to turn on indicator lights of these stages, so I can run it headless and still know all is well with the location and sync. I would know to sit tight until I got all of the messages from that location, just by looking at the lights.

This idea of off grid and remote, but still having the ability to queue messages is much more common in other countries like Africa, though it could really still be useful in areas where the infrastructure has been damaged, like a wide-spread fire in LA.

[KenSamson]

If the to: address was a "channel" name, like r:/jokes, then this sync method could then be used to send to everyone who subscribes to the r:/jokes channel, and bingo, we have "group" messaging of sorts. Too many ideas coming along way too quickly to get them all down, but I figured I would share some of the more useful ones.

[faragher]

This is an application level idea. Group messaging is available, but it's all single point e2ee, so traffic is relatively high. Multicast with a shared key and distributed routing is the big hurdle for "group" destinations.

If you're interested in a channel-like system with a server-client mentality, I mocked up a proof of concept some time ago: https://github.com/faragher/LXMEvent

There are group chats/boards/hubs already in place, but none are truly e2ee and require multiple packets with the same payload just encrypted differently, as well as trust of the central server. I'm uncertain what the status of any of these are, but they're all linked to somewhere in this repo.