ssb-mobile roadmap

green is done
yellow is in progress
gray is untouched

notice also some hashtags, they describe the knowledge needed to tackle each piece.

(PS: I'm calling it roadmap, not tech tree, because according to the dictionary there's nothing in "roadmap" that makes it strictly a list: "a plan or guide for future actions")

Hmm, for "fix all crypto to be callback based" that is gonna be a pretty mammoth task: but, if we do the easiest parts first, not such a big deal: shs will be the easiest, because it's decoupled from everything else. Then signatures (for message verification) and private messages.

Hmm yeah and I realized this task doesn't need to be done necessarily after react-native-sodium. So it's not depending on anything else in order to be started.

We should time things like this for when they are most exciting to work on. We want it to feel like something has happened, theirfore it should wait until at least we have a usable mobile client.

Agreed. And when it comes to using async crypto everywhere, we can at least be aware to not add new sync crypto code in the stack.

Another thing I could add to the roadmap

• Use node-ssdp (UPnP) to allow LAN discovery of SSB peers

In a quick test with two android devices in the same LAN, they weren't able to find each other through sbot's own multicast dns thing. Maybe there's some bug there, but it would anyway be good to have a fallback for LAN discovery.

@piet shs is secret-handshake. I think most of the work with changing to async crypto is rewriting the javascript, especially the parts of the application that assume a function is gonna be sync.

If you really wanna get your low level hands dirty
I think the most enabling thing here would be a proper fs interface.
It would need open, read, write, stat, readdir, mkdir, ftruncate, fsync, fdatasync, close ... just the low level functions in the fs module, i.e. the ones that are about file descriptors instead of paths.

This will enable flume & blobs (and the various other things that use fs)

my linux on andoid can receive my laptop's UDP multicast, at least. Phone is providing the wifi.

Good to hear, @Piet!

@Soggypretzels

How hard do you think Bluetooth would be to implement?

Hard, but certainly possible. There are actually some libraries out there that do this, but none (that I know of) are open source. For some reason people want to make a business out of bluetooth P2P.

• http://underdark.io/
• https://www.opengarden.com/meshkit.html

Either we would have to hope they open source this, or we need to build it ourselves with plenty of hours of effort with Java development and ObjectiveC or Swift.

@dominic

I think the most enabling thing here would be a proper fs interface.

Yes, agreed. Enabling blobs is quite important.

my linux on andoid can receive my laptop's UDP multicast, at least. Phone is providing the wifi.

That sounds normal, I think I did the same. But two android devices receiving each other's multicast didn't work, for some reason. When I ran arp -a on one of my phones, it showed my LAN gateway and my computer only, not other devices.

Updated the roadmap!

(would probably make sense to put the svg itself in git, but it's also nice to have it visually in Patch*, so maybe I won't make it a git repo)

Okay I just confirmed that udp broadcast works both between my laptop and phone and back, both ways.
This is running linux in a container on the phone.

But if that works, the problem is somewhere between the app and that, but there isn't a firewall, obviously. I feel that is something I'd definitely want if I was writing a game, so it's gotta be possible.

I looked at mdns and stuff when I first started building this stuff, but it needed a binary addon, etc, and just made a quite simple thing quite complicated.

Entirely updated the roadmap for ssb-mobile, and basically we can scrap the previous roadmap because it had an entirely different approach. Notice that I highlight that the iOS path may not be doable, it currently totally depends on a proprietary component. The Android path looks better.