Meshtastic integration with Secure Scuttlebutt
Secure Scuttlebutt (SSB) is a decentralized data platform, specifically made for offline-first social networks. There are many similar decentralized platforms out there, famous ones this days seem to be Mastodon and Matrix. But for my use-cases, communities that have no connectivity, they both lack true p2p, relying on servers, which disable device-as-infraestructure.
There are spaces where federated and p2p have been converging, Mastodon example and Matrix example. And as convergences happen they start facing similar issues, like identity spread around multiple devices and device storage for example.
There’s lots that makes Scuttlebutt special, specially the community and end-goals behind the protocol. But technically, it’s been growing for the offline/off-grid first perspective. So it’s advanced a lot on how to enable security and at the same time discovery for completely p2p gossip networks that don’t rely on DHTs.
The reasoning behind integrating SSB and Meshtastic is that they both provide the cheapest transports possible. First SSB turns every device into a node which communicates within Bluetooth or Wi-Fi range and can carry messages sneakernet-style. LoRa is the most accessible long range transport out there, so it’s naturally the next option for extending a network, say to another community for example.
Next steps would include a Wi-Fi long range link, HF, satellite or cable. But all of those are in another order of magnitude of accessibility (service-provider availability, licensing and cost) and usually open up to the Internet, which is not desired by every community.
Challenges
SSB relies heavily on cryptography to be secure. Hashes are long pieces of data that are terrible to carry over a low-bandwidth transport such as LoRa. A simple “like” in SSB looks like this:
{
"key": "%a8acTq/Bss5G1j7JsggyHibLJ+PIM/1XvhifOLEXqUA=.sha256",
"value": {
"previous": "%z0IQ/vul09vRhnk+nvpVGrzHE6K7UD99h9NdL2gr+8s=.sha256",
"author": "@2RNGJafZtMHzd76gyvqH6EJiK7kBnXeak5mBWzoO/iU=.ed25519",
"sequence": 377,
"timestamp": 1518257352380,
"hash": "sha256",
"content": {
"type": "vote",
"channel": null,
"vote": {
"link": "%ehhSqb2l/GbqhdWhvrHs0LkfTjA2LB4krK/kdY/eCqg=.sha256",
"value": 1,
"expression": "Like"
}
},
"signature": "yrXKc7C5riUVXB6ckaLZ7zzvn63G6AdzIEPM1esuu3EDS2whDr5DL2N8ILPGoa4pzp9cMd4O6kJEJEkr1/IPB==.sig.ed25519"
},
"timestamp": 1580754824704
}
That’s 543 bytes for a *Like message×, about 400 bytes just for the envelope. But a message can easily be well over 1Kb. All this in JSON format of course.
Is this even possible?
We obviously don’t want to replicate the whole SSB network over LoRa, that’s insane. But it makes sense to replicate messages of key types. For example, we’d want to replicate identities (public-key, identity-fusion, name, location) over Lora, and maybe public and private messages of a type “Emergency”.
The networks we’re thinking about are composed of neighboring communities. So we can expect and play with certain amounts of trust (less security concerns).
ssb.proto would look something like this:
message SsbMessage {
message Value {
string previous = 1;
string author = 2;
uint32 sequence = 3;
uint64 timestamp = 4;
string hash = 5;
string content = 6;
string signature = 7;
}
string key = 1;
Value = 2;
uint64 timestamp = 3;
}
We could use distributed hash tables over LoRa and a shared secret (maybe the channel name) to hash the hashes into smaller-sized hashes that are re-constructed after each send/receive. As our chances of collision will be very small in a such a small network. But don’t even know if it’s worth it.
We could also automatically break the messages into smaller chunks, sending first headers then broken up chucks of content.
But then the biggest issue is on SSB’s side. It keeps an append-only log for each feed (key pair), where every message refers to the last one, so that logs are temper-proof. Receiving a special message from LoRa without having previous messages to check will break its security. But it’s probably a worth-while trade-off, as ssb-partial-replication has done (?).
Conclusion
The end experience we’re aiming at is for complex, multi-user, multi-threaded interactions that SSB offers, while using LoRa as transport in remote locations. I believe this and voice-over-LoRa are key features that would perfectly fit within the ecosystem of applications that can satisfy needs of networks of offline communities.
Thoughts?
That’s actually much better then I was expecting.
