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.