If I were going to continue along that way (using the --tunnel to tie into existing things) … maybe something like Secure Scuttlcebutt https://scuttlebutt.nz/ (Manyverse, Patchwork, Planetary, etc etc are clients built on it. Usually works over WiFi/Lan but the --tunnel makes a lan, so…)
It has “sync when I see you” baked in as well.
Though I think a “no videos or images” client might have to be forged.
Not sure how often you check Mastodon. Here’s a little proof-of-concept bot/bbs-starter in bash. It watches for a “command word” and responds.
Needs much much much extending but it shows that a node can be used to watch and pipe out info. This is a lot like what my “bash simplex repeater” started out life looking like.
Image on Mastodon: HowToPhil (Phillip R): "@singletona@bitbang.social More good news, with …" - Mastodon
Bread crumbs and proof of concept. Very hacked together but it shows that more can be done.
What modes are you using btw?
Well for me the appeal is it provides a fallback if the Internet stops being w thing that can be relied in. This thought born both of my loved experiences pre internet as assumed always there thing, my rural life since, and the sheer possibilities of making something fun.
That script should work with “any” mode since it just waits for a message with a command word and sends back some other text.
The --tunnel methods seem to only work in the fast modes. Might work in the slow modes but I ran out of patience while testing those. Might try tomorrow 
Here’s an update of that meshbbs.sh script that adds some more functionality to make it clearer as to what kinds of things can be done just with some bash scripting:
Actually, you could just use fidonet. It’s still there but in a sort of “underground telnet bbs” space now.
I feel dumb for not realizing that fido itself is an option.
Mind keeps circling the idea that maybe there are tricks to save bandwidth by going with something LoRa specific instead of abusing the fact this is literally a tunnel.
All that said would setting the connected node as a repeater help? Thinking again drifts towards a new ‘server’ role in the protocol to denote ‘hey this node is connected to information that the mesh should have access to’
The thing I now wonder is how does one make a fido route when the differing content island might end up changing addresses? Use the nodes channel/name etc identifies as the address when reconnecting for the sake of data synching?
You might be able to get a script to “beacon” the IP addy of the node every N-seconds to the mesh network… Or respond to a request for tunnel IP (added as an option to that BBS/Bot shell script I made or something more robust).
You could also use things like the codegroup or base64 encoder/decoder programs to encode any data to text and then chunk it for transmission through the mesh as normal text messages. I have some scripts that turn data into encoded text and then chunks it into qr-codes so you could print… some data to store on paper or laser-burned on rocks. That could also be modded to chunk data into encoded mesh text messages… Then decoded on the other side. This old bash script of mine:
Here’s an example bash script showing a possible way to send base64 encoded data files as messages over the mesh:
I think I’d have the other side count up the lines and report missing lines… maybe include the line number either way (–ack or not)… I’d also do the --ack and have the sending machine pause and “watch for node return” before sending the line again and continuing… Things like that…
Also, something like this could be linked into the mesh network to give the ability to have asynchronous “social media” style posting to some bot/BBS style program:
It’s flat-text based and several different clients exist for the specification.
Again, I feel dumb for not realizing the tunnel option allows for a lot of options via terminal.
Biggest stumble is making graphical clients for users wanting to use their phones, but that is something that can be done.
The question I now have is what range can you get between nodes running things like this? Short/fast from your bbs demo is obviously best at transmission, but med/fast looks tolerable.
Are we talking a mile? More? Less?
Like many radio things, that’s going to be more a function of the height of both antennas (sender and receiver), topology between sites, and atmospheric conditions.
I think there is a base64 encoder for Android. So, someone could currently by-hand the same concept as in that bash script.
My general thought-process is:
“These modes are all pretty much old dialup speeds and anything that worked on old dialup should work on them, at the same level of speed. IRC and all the things that work on IRC? Good to go! Old-style BBS? Should be fine with patience! etc etc”
I might quickly be proven wrong though 
That was my general thought process. On paper these are dialup speeds and we had a thriving internet with that.
If ngircd (IRC server) is configured to deal with the long waits (adjusting “pong” settings etc) it appears to work in all the --ch-[short|med|long]fast modes over --tunnel.
That gives file sending over dcc a chance though it is slow.
Connected with Hexchat (IRC client).
Note: flwrap (part of fldigi) might work better for sending “data” over meshtastic than base64 hacking since it has the resilience to lost parts of data baked in:
I updated the sendmeshfile.sh script to include md5 checksums for the previous base64 line sent. This should allow “error detection” if a receiver misses a line (much notes in the bash comments):
I personally don’t like the idea of downloads over mesh, but am glad your’e working the problem since network/grid down situation and you’re trying to get someone across a many mile gap a PDF on how to fix something (as example,) is something I view as a good use case.
That’s basically what I’m thinking. Schematics, maps, directions on food sources and medical treatment; those all need to make it through in clear and exact ways.
I’d probably go epub instead of pdf as that’s lighter. Or even just “the lowest useful resolution jpegs”
I think, if people take into account the speed restrictions, then small but precise files can add a lot of usefulness to a bad situation. People transferred files on 300 baud, so there’s no reason is should “never work” on meshtastic speeds, I think.
