Implement Telehash?

[n8fr8]

Maybe BluetoothLE, StatusCast, etc, can just be a transport for this: https://github.com/telehash

[chrisballinger]

Wow it looks like they're building something almost identical to our design. Will definitely check that out.

[n8fr8]

Yes, but only over UDP for now!

[fd]

@n8fr8 well not really. UDP is the basic transport but any other transport can (and many will) be supported.

[n8fr8]

@fd yes, understood. We are interested in exploring using our interoperable BluetoothLE layer that is under development here, so it seems like a good fit.

[fd]

@n8fr8 Cool. Be sure to contact @quartzjer about the BLE transport as he might have some tips/wishes/ideas about that.

[quartzjer]

Count me in! Telehash has become a lot more like OTR, a generic way to send/receive end-to-end encrypted data through any transport, and all the implementations support UDP as a baseline but really any app can "bring their own transport" and we need to show that off more.

While it would be ideal to have an interoperable set of BLE GAP/GATT/UUIDs and services that can work across any app, I would love to collab/help with it working just within a single app first.

The chunking to enable low-MTU packets was just implemented/merged in both the C and JS, so that a BLE ~20byte payload should work easily out of the box with those codebases... there's been some work started to wrap telehash-c to work in objc by @dwaite but it's not avail/usable yet, if it was then this would be a lot simpler to try :)

[n8fr8]

... and the Java/Android code? Seems a bit farther behind, and probably doesn't support chunking yet, right?

One thing we have been experimenting with is cross-compiling Go onto Android, and using that as a native binary engine within Android Java GUI code. Perhaps that might be possible here, if the Java code is not going to be kept up-to-date... or we could just contribute to the Java code, perhaps, as well.

[fd]

@n8fr8 cross-compiling Go is definitly an option (especially with go.mobile and Go 1.4)

[quartzjer]

The Java code is older/v2 based from earlier this year, cc @simmons in case he was planning on updating it soon. Cross-compiling Go is really interesting though :)

[n8fr8]

@fd go.mobile is exactly what we need, so we don't have to use a binary, and instead can add a proper JNI interface.

@quartzjer just so you know our context, we've the team behind ChatSecure on iOS and Android, and are moving our focus away from XMPP as our sole focus to supporting non-internet, device-to-device focused communication. We have worked on other mesh systems in the past (Commotion/OLSRD type static IP meshes), but found that they weren't suited for mobile, as they needed too many modifications to at the WiFi layer to work out of the box. So, we ended back at messaging-oriented meshes, starting with some work I did using Bluetooth device name's as a transport (https://github.com/n8fr8/gilgamesh) and now moving towards the BLE work that @chrisballinger and co have been doing.

[fd]

@n8fr8 go.mobile is expected to be finalised (along with go 1.4) some time in december. There are plans to add iOS support by 1.5 (this summer).

[quartzjer]

@n8fr8 hopefully I can speak with some authority then, since you were based on XMPP, that what you described is exactly the goal of telehash as a generic protocol, a modern and complete re-think of XMPP to support privacy and distributed architectures natively first-order :)

It's taken a while to get here with the history of telehash, a lot of real-world learning and evolution, but the recent v3 milestones have solidified and after there's some stable implementations I expect to spend a lot of 2015 working the parts of it through standards groups.

Wish the timing was better and it was immediately usable, but we wanted to get things done right so it can become a solid tool for the next decade.

[simmons]

@quartzjer and @n8fr8 -- It's true that the Java code is quite far behind. It was a proof-of-concept implementation of Telehash v2, and never reached a point where it had any polish, and likely also lacks memory stability.

I personally think that using a Telehash module implemented in Go (or Rust, or some similar language) within an Android app is a fantastic idea. A Telehash implementation is theoretically self-contained aside from network sockets, some sort of streaming scheme to move buffers to/from the rest of the app, and the occasional API calls. This self-containment should relieve the usual obstacles with moving Android app code out of Java (i.e., mainly the need to interface with the Android API). I've occasionally toyed with the idea in my head of using pipes for streaming between an app and a hypothetical native Telehash thread, to (maybe) reduce JNI overhead of calling channelRead() a lot.

Telehash v2 was heavily DHT-oriented, and I eventually came to the conclusion that live mesh maintenance on a mobile device (e.g. over LTE) is just not practical from a battery usage standpoint. (See: http://cafbit.com/entry/battery_cost_of_periodic_mobile ) I think this became a point of discouragement for my Android-centric Java implementation of v2. A future v3 implementation may make a lot more sense.

@n8fr8 -- Your reputation precedes you; thanks for all your work on the Guardian Project! I'm extremely interested in secure/private messaging. I'm overcommitted with other things until after the new year, but maybe when things settle down I can think again about ways I can contribute.

[chrisballinger]

@fd I am anxiously awaiting Go support on iOS because it will allow us to more easily support obfs4. I'm most excited about cross-platform development in Rust but that is probably a bit further out.

As far as this prototype is concerned, our "mesh" network is more of a store-and-forward messaging system with automatic proximity-based syncing in the background. It's more of a sneakernet than a mesh network and any protocols we use need to be designed for ultra high latency (days) and non-guaranteed delivery.

[n8fr8]

@chrisballinger exactly, you are acting as UDP in this case, which is great. Telehash should worry about the rest.

[quartzjer]

Telehash supports both modes, synchronous/connected sessions which will do reliable/ordered streaming (using a streaming cipher) which is best suited for when two devices have a BLE session open, and an async unordered/lossy messaging (just encrypted blobs, up to the app to handle), for the store-and-forward models.

The internal API is called End-to-End Encrypted Exchange (e3x) and there's a draft of interacting with it here: https://github.com/telehash/telehash.org/tree/master/v3/e3x#api

Channels are the synchronous, messages are async.

[n8fr8]

Channels/syncro might also be well suited for Android where you can open up an old-style Bluetooth RFComm socket or a WifiDirect connection, between a known set of people in area... say a group of friends in a classroom or cafe, or a meeting/data exchange between specific people.

[chrisballinger]

Telehash is certainly interesting but I'm not sure if it fits this use case entirely, please correct me if I'm wrong. This current prototype is designed to be a public network, similar to Twitter, where everyone's identity is their Ed25519 public key, and all of the plaintext/public data transferred over the network is signed to prevent spoofing.

Direct messaging with E2E crypto is something that I would like to eventually support, but it would come at the expense of the rest of the network. There's only so much data each intermediary device can store, and the BLE transport is very bandwidth constrained, so private messaging would require altruistic nodes that don't mind shuffling around data meant for others at the expense of their own. I worry that if too many people use direct messaging it will adversely affect the network.

If network bandwidth and storage is no longer concern, I'd only want to implement direct messaging using a protocol with support for asynchronous forward secrecy, so Axolotl seems like the obvious choice there.

Telehash's DHT could still be useful for figuring out how to efficiently route direct messages between nodes, and it seems like there'd be no problem cramming something like Axolotl inside of Telehash.

[n8fr8]

@chrisballinger there is some interesting work/papers that I and one of my friends (SJ who worked on OLPC's mesh: http://one.laptop.org/about/people/samuel-klein) have been looking into in introducing lossyness purposefully, to avoid the network congestion you fear. The idea is that you only forward on say 20% of the messages you receive that are not for you, knowing that, based on the density of the network around you, there are others who will forward them. The original sender will also eventually send again if they don't receive a delivery receipt/ACK. Here is one paper on the subject, at least in how it relates to a sensor mesh: http://asp.eurasipjournals.com/content/2014/1/57

Overall tho, I trust your instinct Chris, in that we might need to mix and match a bit, depending on the mode or need of the user, to fit the specific features or expectations we are starting to design.

[quartzjer]

You're definitely correct in that telehash is not the use case of public messaging, it's designed specifically for the opposite of that, private ones, and aggressively encrypts/cloaks everything on the wire :)

Understanding the goals of a public relay, I would still wish for the individual device-to-device direct comms to be encrypted and telehash could be relevant there (atop of any bluetooth security that is enabled) and shouldn't add any more overhead than it's worth having. It may seem silly if it's an open accept-anyone mesh, but it's just a first principle of mine now to want every bit encrypted.

The telehash messaging model also implements async forward secrecy, and yes I would definitely want to use it in combination with Axolotl and it should be a perfectly natural fit to combine them and have redundant levels without added complexity.

The DHT was removed from the current version, since it conflicted with the privacy goals, and it's difficult to secure a DHT without intimate knowledge and design of the exact app and trust model.