offline options for transport

[og1en]

Still a car loaded with disks is faster than any computer network.

I suggest adding transport via files. Simply part of the data, for example, Micron pages or the entire node cache packing to file. Put on USB falsh disc and walk to the other location.

Ols postman competition should return.

[faragher]

Sneakernet support is intended, but let me tell you what the capabilities currently are:

You can send a message through a propagation node. Doing so sends an encrypted file to be stored and propagated amongst the servers until the destination is seen and the message is passed along. An LXMF message can attach a file. (this is not currently supported by any client, but the specification is there and it's functional) In theory for small amounts of data (megabytes, not gigabytes) you could put these messages on the distribution net and use it for file transfer.

Since the propagation nodes all synchronize, you can take a node with these messages, physically transport it to another network, and it would send the files to online destinations or synchronize them with other propagation nodes.

However, since this takes up space on every propagation node, and the default storage space is 2 gigs for the entire system (and we're currently using . . . 1.14 MB, which is way up from the ~100 kB I remember, this is useful for asynchronous messages and small files, not large files.

If you have any thoughts on requirements and implementation, let us know.

[og1en]

There are many such networks, the most famous is https://ssbc.github.io/scuttlebutt-protocol-guide/
second is https://en.wikipedia.org/wiki/ANT_(network) I imagine that in a situation where we just have to send a lot of data, to bypass slow radio links we can use files.

Very often we have that some people move along a fixed route. Let's say there are vendors running between two cities. This could speed up transmission and make it independent of slow networks.

Very good example is https://git-scm.com/docs/git-bundle options.

[faragher]

But if Scuttlebutt exists, what's the advantage of making a similar system in Reticulum? If you're just transferring files, you don't really need a network stack. If you're building a file repository, you don't need Reticulum at all. If you're looking to make something that transports data physically and then peers can request it at the end point, that's an application, not part of the network stack.

It would be straightforward to take something like POPR (https://github.com/faragher/POPR) and convert it to serve files to authorized users at an endpoint. From there it's just physically transporting the files and uploading them to the repository.

Now. POPR isn't designed for multiple users for on-disk security reasons, but you can modify it if you need. Plus it stores LXMF messages, which, as mentioned, can store files. From there you simply write an application to download and decode the message, then save the file. It's a bit of work, but it's all already doable.

I'm not sure it requires any modification at the network stack level.

[og1en]

If there is a radio interface why a kiss or tcp interface?
In a crisis situation you will use all available options.
Same 'git' why pack everything into a package when you can send it over the network? Since there is a git:// protocol why use http:// and that's what it is.

[faragher]

What you're asking for isn't an interface, it's an application. I showed you how it can be done today. You wouldn't say "I want file transfer capability added to TCP/IP," you'd use the networking stack to make an application to do what you're asking.

To be even clearer, Reticulum doesn't even handle the systems I've described, Sideband and Nomadnet do. Reticulum runs the packets and routing that those applications use.

[markqvist]

@faragher is right here, Reticulum itself is a protocol and networking stack, and as such the offline transport options you outline lies outside of the scope of it.

However, the functionality you describe @og1en, is very useful and something that could be built on top of Reticulum in a very elegant and functional manner. Reticulum is basically perfect for building these kinds of systems.

There's a myriad of ways it could be solved and implemented, and I am personally working on some of those as well. I invite anyone else interested in such systems to do the same.

[markqvist]

Moving to discussions, since it is not an issue. Please read the contribution guidelines before creating issues.