Comment by __MatrixMan__

Comment by __MatrixMan__ 18 hours ago

13 replies

I feel like the better path to resiliency is not persistent radio connections between hobbyists on other sides of the state but rather intermittent ones between people on opposite sides of the bus and an application layer that arranges for people who are heading that way anyhow to carry "internet" traffic on a filesystem in their pocket.

You just get a different type of threat landscape when each hop is also an opportunity to shake somebody's hand and attest that the holder of their private key is a real human. It creates a minimal trust layer you can then build on. You don't get that with a hardware address found drifting on the wind.

Both modes have some potential to attract harmful attention to network operators based on the behavior of their users, but to a very different degree. So far as I know nobody is kicking down meshtastic operators' doors looking to follow a transmission to its source, but I think that would change if the other modes of long range skulduggery were to fail.

The most resilient infrastructure would be one with no high value targets: one where each user is equally an operator.

goda90 18 hours ago

This idea sounds a lot like Secure Scuttlebutt[0]. I'm not sure the state of it. The client they link to on their website ceased development awhile ago.

[0]https://en.m.wikipedia.org/wiki/Secure_Scuttlebutt

  • __MatrixMan__ 17 hours ago

    I think that secure scuttlebutt (SSB) is a very good start, but eventually we'll need something besides an append-only log. Something that removes data that is no longer interesting. Something that, when it runs up against its storage quota, prunes data based on whether it is more/less trusted or likely to be interesting to a peer. Something that knows which peers I'm likely to be near in the future, knows which topics they're subscribed to, and which tries to be an efficient mailman based on that understanding.

    But yeah, my vision is pretty much just SSB all grown up.

Karrot_Kream 16 hours ago

nncp [1, 2] is probably the best Sneakernet tool I've found. It's very UNIX-y which makes it pretty hard to operate if you're not technical but would also make it pretty easy to wrap around with a UI. You have to explicitly add a list of "neighbors" to your configuration and you can send "packets" either by spooling to file or using a TCP/Noise connection. You can also send data hop-by-hop and is e2e encrypted.

[1]: http://www.nncpgo.org/

[2]: https://www.complete.org/nncp/

  • cbsmith 13 hours ago

    ...and it's close relative NNTP. There was a whole distribution structure built out of intermittent data transmission. We've had the tools for this stuff for a long time, we've just switched to centralized, always available services because that's easier to build a company around.

apitman 9 hours ago

Maybe I'm being a little too cyberpunk but it would be cool if the system somehow rewarded people for delivering messages over a long physical distance. You could end up with a courier community where runners spend some time walking around high-traffic areas collecting sent messages then jog to the other end of town so the encrypted messages can find their recipients.

  • __MatrixMan__ 9 hours ago

    At some point, somebody will set up long range wireless communications and then the reward for running a message would likely drop to so small that it wasn't worth it... but yeah that's exactly the sort of thing that I had in mind. That way if something happens to the internet, prices for running a message go up, and suddenly running messages is worth it again.

    The tricky part there would be working out a partition tolerant payments system. It's one thing to go offline in the middle of delivering a message, its another thing entirely to orchestrate payment across a smattering of disconnected networks (blockchains are not partition tolerant). I think it could be done, but that's an application layer concern... gotta get the peer finding and web-of-trust stuff working first.

roguecoder 15 hours ago

America is sprawling, unfortunately. That kind of approach would work in cities, but would be much less effective where people aren't taking the bus or even being around other people on a daily basis.

The advantage of something that can reach 6 miles is that it could cover suburbia and rural areas with ~20-40 acre plots relatively effectively.

  • __MatrixMan__ 13 hours ago

    Yeah it's not ideal for sparse populations but I think you could get a lot of coverage by just running a node with a solar panel wherever your mailbox is and also having your mail driver put a node in their vehicle.

    Really the thing I'm trying to push back against is the idea that the entire path between them must be connected all at once in order for two parties to communicate. If we design for short range, partition-tolerant, pocket-to-pocket background gossip, then that same protocol will work just fine if you attach specialty radio hardware and give it miles worth of range, and you've still got the fallback ready for cases where all you have is consumer grade hardware.

    On the other hand, if you design for persistent connectivity and then try to use it in an intermittently-connected context, you're going to have a much worse time.

hashstring 17 hours ago

> to carry "internet" traffic on a filesystem in their pocket. What do you mean?

  • __MatrixMan__ 16 hours ago

    Well "internet" gets quotes because if the source and the destination are disconnected when the message arrives then they're not on the internet.

    It might look something like this: As you stand in line at the grocery store your device notices that a nearby device (the guy behind you) belongs to somebody who is trusted by one of your peers in the "gardening" topic. You're not a gardener, but your room mate is. So your device pulls a gardening related update from their device. Then as you head home with groceries your device is not connected to anything, it's just sitting in your pocket with a filesystem full of data. And then when you get home your roommate's device gets a notification about a reply to their question on a gardening related message board. That data came to them on your device. It traveled a few feet wirelessly at the grocery store, and a few feet wirelessly at home, but the majority of the transit was handled the slow way, by hitching a ride on a human who was traveling that way anyhow.

    It would only work for small bits of latency tolerant data, and work best for information of broad interest (not so great for an encrypted email to a single party, pretty good for map tiles, open/closed hours, restaurant menus, etc). The simplest app to build on such a platform would be a sort of of distributed BBS. VoIP would be nearly impossible. But I think that small snippets of high latency text can get you pretty far.