Dev diary: building an SSB app for Android

Started making an SSB app for mobile.

Using React Native. Probably will eventually use Cycle.js with TypeScript and React Native, but for now the most important is getting a proof of concept working.

Started the RN project, and then simply did npm install scuttlebot. Of course everything broke. But it helped me to know what broke.

Installed rn-nodeify which gives me some basic node packages like fs, dgram, path.

Then noticed there is no react-native-sodium library. There is gladly sodium for Android. So next step is developing the react-native-sodium library and then from the RN project settings I can alias chloride as react-native-sodium everywhere. That's what keeping me busy now. Main challenge is simply finding what is the full API for node's sodium so I can mirror it correctly. I would be happier if @types/sodium existed, which doesn't.

Found chloride-test, thanks Dominic.

I might be already utterly screwed, because RN native modules can only be asynchronous, and it seems like sodium has mostly synchronous APIs?

Oh, scrap that.

libsodium-wrappers which is libsodium compiled to javascript via emscripten if performance is important but code size isn't

libsodium-wrappers it is then. Just trying to make that work.

Ended up using sodium-browserify-tweetnacl which was the only one that seemed to load as a module in RN's packager. After hacking some packages in node_modules to refer them to use the alias "chloride"=>"sodium-browserify-tweetnacl", I'm now trying to get ssb-keys to work.

Yes! I got ssb-keys working. It generates a key in this example. :D

Sorry for the huge image.

Repo if someone wants to follow %+gCL8LS...

@andrestaltz chloride/small gets you sodium-browserify-tweetnacl

what sort of fs access do you get in react native? does the polyfill give you everything?

also, what about net?

net is covered already by https://www.npmjs.com/package/react-native-tcp.
fs is covered by https://www.npmjs.com/package/react-native-level-fs which in turn is covered by mafintosh's fs on leveldb, and leveldb itself is in RN's AsyncStorage. In the end, all goes to AsyncStorage which is just a cross-platform abstraction for "storage, but expect things to work asynchronously". http://facebook.github.io/react-native/releases/0.42/docs/asyncstorage.html It's backed by RocksDB, if available.

@andrestaltz this is super exciting

I you get ssb servers running on mobile, this space could get very radically transformative

I might be already utterly screwed, because RN native modules can only be asynchronous, and it seems like sodium has mostly synchronous APIs?

having JS crypto is great for a proof-of-concept, but its at least an order of magnitude slower than native crypto. is there any way around this restriction, or any plans for React Native to support synchronous native APIs? and if not, are we willing to write and use only asynchronous APIs for sodium in order to have first-class mobile support via React Native? @Dominic

also hey roots working in React Native already: @gregkan @sararrrgh @iainkirkpatrick, it's happening.

Yeah I thought about the same, @dinosaur. I'll see how far I get and how it feels. Our choices are: (1) reimplement SSB entirely in Andoid/Java, letting go of the existing JS code, (2) write an async-sodium library and reorganize our existing SSB code to use that API.

(1) is the long-term plan and we should probably do in the following years if SSB grows.
(2) is probably worth trying if (and only if) the JS crypto feels truly slow to users.

I estimate the JS crypto will just make private message threads too hard to run on mobile. That might be ok to start with

@winmix hmmm, as long as the private messages are indexed, it shouldn't be too bad. I'm now indexing them in patchwork and the performance is much better.

Note to self: if thick layers of abstraction for the db (react-native-level-fs to level-filesystem to asyncstorage-down to asyncstorage to RocksDB/SQLite) turn out to be too slow, I could try https://github.com/litl/android-leveldb, and in particular, making a library react-native-leveldb.

To be more precise, that library would be react-native-leveldown.

Milestone: got storage and fs to work so that ssbkeys.loadOrCreate works as expected.

@andrestaltz sounds like good progress! it wouldn't be too hard to reimplement the crypto as async, because the changes would be relatively contained. The biggest difference is asymmetric operations, symmetric crypto is fast anyway.

The parts that might go slow are verifying messages (on receive) and decrypting messages (although, I have changes planned that will make the asymmetric part cacheable.

I expect the storage abstraction lasagna be a problem.
It doesn't expose the right low-level primitives, but i did find proper native modules: https://github.com/johanneslumpe/react-native-fs

that could be adapted, though.

I saw this react-native-fs, but noticed it doesn't mirror the node fs module (e.g. it's promise based). Might be possible to work around that though.

Today's progress comes in the form a video, through webtorrent https://ferrolho.github.io/magnet-player/#6a2699e4b192ef86423180a517ba173eb8955c53
(My VPS is seeding this quite slowly. Every few seconds it chokes, then it comes back. If you download it quickly, it's because I'm seeding from my computer)

Alternative link https://instant.io/#6a2699e4b192ef86423180a517ba173eb8955c53

hey great update @andrestaltz!

i'll try and seed the video on my computer for some time to speed it up for any future watchers.

you mentioned saving and restoring gossip peers. just in case it's helpful, that's handled here by reading and writing ~/.ssb/gossip.json.

Oh, good! Thanks for the tip. Interesting that it's not in leveldb.

This issue is making my life very miserable right now https://github.com/nodejs/readable-stream/issues/260

@andrestaltz where is that coming from? we have nearly got all the node streams out of ssb, there can only be one or two more. My guess is that this is from levelup?

Yep, it's mainly from levelup, and more specifically level-filesystem and level-blobs. I got over the readable-stream complications, and got stuck with level-blobs in an infinite while loop https://github.com/mafintosh/level-blobs/blob/adb3411fedc611ea05ba1a3462eab53aa7de4324/index.js#L259-L284

It was basically getting a key like /.ssb/secretÿ00001a and incrementing it to /.ssb/secretÿ00001b and repeating that ad infinitum.

I'm wondering if I need to do a fundamental migration/change in how storage should work. I'm not sure what do android developers (or react native developers) use for storing images, but I'd guess it doesn't need to go through React Native's asyncstorage which is like a localstorage of sorts.

And just to clarify: level-filesystem uses level-blobs to store every type of file content. These aren't just "blobs" as we know them in SSB.

Note to self: experiment building a library react-native-fs which maps fs API to React Native's AsyncStorage. This could replace react-native-level-fs and the entire level-filesystem jungle. Then, for ssb-blobs, I can make a react-native-ssb-blobs which uses android and iOS's own image storage thingy. Thank the scuttlebutt gods for making the plugin system in scuttlebot.

That concludes today for me, I'll sleep over this and have a fresh start tomorrow.

really, blobs should just be stored as files. leveldb isn't designed to store things like that, and will do a lot of extra work to do so. So if we multiblob work on one of those react-native fs modules we'd be good there.

If a portability rewrite in Java ever becomes a serious possibility, we (you? everyone?) should also consider C. Everything either runs C or has an FFI to it. It might come with a lot of ugliness, but it for portability it is probably still the best choice.

I'm not saying whether a rewrite is a good idea at all though, just wanted to put this here...

That's a good point, Android indeed has an NDK (native dev kit) and I would say that is the long-term plan. Right now I'm in proof of concept mode, which is ultra short-term.

@xstt I think that Decent is based on the liteclient (relies on pubs, but stores the private key on the device), but @andrestaltz is working on a full peer (that is, fully decentralized and stores the messages and blobs on the device)

Yah, the lite client is pretty useless if your device is offline. However, not syncing the entire database might be a benefit if the device has metered data.

@andrestaltz intends to write a new UI, but once he gets sbot working on mobile you could certainly combine it with a different UI, this one or another.

For now, I'm trying to make this a proof of concept. A full peer on the phone is important for LAN gossip, and making gossip spread like wildfire, specially for people who's only computing device is a phone. Down the road, if previous steps were successful, we could consider local db pruning (of blobs e.g.), hybrid client (syncs data only from certain handful of accounts, the rest works as a lite client), and whatnot.

Little bit report on (un)progress: I can't get TCP sockets to work, even though they really should, there's even a package for that https://github.com/PeelTechnologies/react-native-tcp

Discovery: react-native-tcp doesn't support server.listen(1234), only supports server.listen(opts), while multiserver net plugin uses server.listen(port). I'll make a PR to react-native-tcp.

https://github.com/PeelTechnologies/react-native-tcp/blob/75afd35a6b2c1ce13dea74da236d75b6bfdcff0c/TcpServer.js#L66
https://github.com/ssbc/multiserver/blob/58073dc0fc7bed93460b3fa718d3114dc2d4ec3e/plugins/net.js#L21

No, I'm wrong, react-native-tcp creates the opt object if a number was provided.

Yesterday Dominic and I did some pair programming to troubleshoot the bug. We ended up finding two bugs, one in secret-handshake/protocol, the other in tweetnacl. None of these were "our bug" though, so we didn't solve the problem. There are two vectors now: (1) try to reproduce the bug by making a smaller project with React Native, react-native-tcp and pull streams, to see if the interop between these parts has a problem, (2) use websockets instead of TCP. Web Sockets are supported in React Native even without a polyfill library to separately install.

Nice to hear that you unearthed the problem at least partially. I find these things extermly tiersome.. kudos to you for struggling!

I guess dominic already let you know this but ssb-ws is already a thing for the patchbay/liteclient experiments.. So not all is lost if (1) doesn't work out, which I'd encourage you to try since it would be less wasteful, I think.

Thanks for the pointer! (I was looking right now how to actually use WS)
These things are tiresome (I've been at it for weeks) but someone has to do it, and it seems theoretically possible.

Did good progress today to solve a bug. Discovered that our tcp socket polyfill supports only net.createServer(onConnectionFn) while multiserver/net attempts to call net.createServer(opts, onConnectionFn)

Still a good while to go before I can get a functional sbot on the phone, but at least I was able to do some kind of replication of data between sbots, one on my computer, another in the phone. Still rough and can't take off reliably. 🛫

Update: somehow I'm getting sbot on android to talk to sbot on my laptop, but it's not reliable. I digged into the debugger and noticed that createLogStream wasn't sending out data from leveldb as it should, which led me to discover that...

asyncstorage-down@3.1.1 is depending on an old abstract-leveldown (v0.12.3) while that one has been updated to 2.6.1. So I'm going to poke around with asyncstorage-down and see if I can get it compatible with the latest abstract-leveldown.

It's a pretty dirty job I wish I wouldn't have to do. :D

@andrestaltz you're rad. I think it's important to note that you can't easily see how many people are cheering you on.

If there's anything we can do to support you in terms of morale, tech, testing, snacks etc let us know.

@andrestaltz we can make you some anzac cookies. It's actually a biscuit recipied designed for being sent by post to from nz to europe. They where a thing from WW1, but are now just part of NZ culture.

Thanks people :D
No WW1 cookies needed. These messages are already enough support

That said, I'm warming up to the idea of traveling to NZ and meeting all these geniuses. And the nature.

If you're gonna come, you should come soon - it's cooling off down here !
You're most welcome to come visit, would love to host you and show you around. @widdershin and @raquelxmoss are around here somewhere too :P

I realized https://github.com/Level/leveldown-mobile would probably help a lot to get speed improvements (compared to all the deep layers of abstraction we have now for storage). If anyone wants to help, porting that project to React Native would be good in the long-term. For now I can go with the inefficient solution as long as it's the easiest/quickest to get things working.

And I was getting excited to see if I could even make anzac cookies on in my boat galley (well equiped for cooking, but poorly for baking)

Update.

I've been struggling and doing slow progress mostly due to the feedback cycle being quite slow, I have to nuke node_modules and restart the app often.

I rewrote asyncstorage-down to be compatible with the latest abstract-leveldown, got all tests passing. But hit some problems because some db keys were intarrays and the way gt/lt/lte/gte ranges was implemented in asyncstorage-down had lexicographic comparison of keys, and I don't think that quite works with intarrays (it works well with keys). So I basically disabled gt/lt/lte/gte in asyncstorage-down, which made it not anymore pass all abstract-leveldown tests, but at least I got it working for sbot on android.

Next problem I hit, which I'm currently trying to solve is related to logDB. In secure-scuttlebutt v15 (not the flume one), we have this logic for createLogStream:

 db.createLogStream = Limit(Live(function (opts) {
    opts = stdopts(opts)
    var keys = opts.keys; delete opts.keys
    var values = opts.values; delete opts.values
    return pull(
      pl.old(logDB, stdopts(opts)),
      //lookup2(keys, values, 'timestamp')
      paramap(function (data, cb) {
        var key = data.value
        var seq = data.key
        db.get(key, function (err, value) {
          if (err) cb(err)
          else cb(null, msgFmt(keys, values, {key: key, value: value, timestamp: seq}))
        })
      })
    )
  }, function (opts) {
    return pl.live(db, stdopts(opts))
  }))

The important part is var key = data.value and db.get(key, .... I'm hitting the situation where data.value is actually an ssb message, like {author, content, sequence, timestamp} etc. It's an object. And down the stack below db.get(), bytewise.encode will fail to encode that object.

So currently I'm trying to figure out why does pl.old(logDB, stdopts(opts)) serve SSB messages under data.value. I believe data.value should be here some valid SSB ref.

Edit:

-and I don't think that quite works with intarrays (it works well with keys)
+and I don't think that quite works with intarrays (it works well with STRINGS)

sorry, my reply should be here: it's level-sublevel

@andrestaltz yes that will work! base64 is more compact, but unfortunately the lexiographic order of encoded base64 is not the same as the raw binary!

@andrestaltz yup that will work!

Good news! It "worked"! I got a message from the computer to replicate to the phone, and vice-versa. If it were an airplane, you could say it flew. But quite soon it crashed into the bushes. I'm getting different kinds of problems, it's very unstable (e.g. tweetnacl erroring on "no PRNG" even though it looks like it should be there). I'll keep on fixing these and eventually commit and push. The code is in such a crappy and patchy shape that I wouldn't dare pushing it. But soon, I promise.

It works! GOSH this took long. I pushed code to https://github.com/staltz/poc-ssb-mobile. There are some crude instructions there on the readme too.

What works:

• Basics: crypto identity generation, "leveldb" storage
• LAN sync from remote sbot to mobile sbot
• Posting feed messages on mobile sbot and viewing that on mobile sbot feed

What works unstable:

• LAN sync from mobile sbot to remote sbot

What does not yet work:

• blobs
• ?

!!!

YUSS!!!

LAN sync from mobile sbot to remote sbot

So this one actually works too. Both directions of syncing works. What doesn't work, which I'm investigating currently is: ssb on mobile should be able to fetch its stored feed and display it. But it can't, unless it connects to another peer. As soon as it is connected to another peer, subsequent calls to pull(ssb.createFeedStream(), something) will work as expected.

So two news:

• I accidentally left Patchwork opened on the computer and my phone started syncing my real feed data!

Was so fun to do this mistake and see things working :)

Second news:

• Could not get two phones replicating their feeds in realtime through LAN

Because Google apparently pooped on Android: https://android.stackexchange.com/questions/49188/how-to-get-mdns-working-for-chrome-on-android

I figured I have to use something called jsDNS for Java and/or Android. Might be time for creating react-native-jmdns. Or I could try using react-native-ssdp and wrapping that as an sbot plugin.

s/jsDNS/jmDNS/

Okay, found something that could revolutionise everything: http://www.janeasystems.com/blog/node-js-meets-ios/

Basically, running normal node.js on a different thread than React Native's JS thread. This would have the benefit of (1) not having to carefully hackily port node.js stuff to RN, (2) being on a different thread than JS for UI.

Point (2) was actually spinning in my mind already when I accidentally started syncing my phone with my computer's ssb feeds. It's not a good idea to have hard core SSB stack and UI in the same process or thread. Patch* already separates these, as far as I know. Even when you run sbot server on one terminal, and sbot feed, you also have multiprocessing going on. So it would be natural to expect multiprocessing/multithreading for mobile.

I'm going to give that approach a shot, while pausing this approach, but just for a while, I don't want to spend to much time on this detour.

Another link (discoverable from the first, but not so obvious): https://github.com/janeasystems/node-mobile-react-demo

Peer-to-peer shared album app, based on Node.js on mobile running a PouchDB server, with a React Native interface.
The app uses Node.js to set up a UDP broadcast communication layer that enables synchronization of the PouchDB database between all the peers on the local network.
PouchDB uses MemDOWN for the levelDB adapter, which stores the database in memory only, with no persistence between runs.

And... for Android https://github.com/InstantWebP2P/node-android

And gosh, this may help a ton, even though it's API doesn't match with fs, it's still an incredible asset to use: https://github.com/wkh237/react-native-fetch-blob

So I spent some hours trying that approach for scuttlebot (normal sbot as a background thread in ChakraCore in iOS, normal ssb-client in React Native) and basically I can't get it started because the background thread can't find native sodium and leveldb on iOS. I think there should be a way of getting https://github.com/mochtu/libsodium-ios into one of those npm sodium packages that bundle prebuilt bindings (should be an easy PR, right?) and same thing for leveldb, but this is far from my skills as I've never touched node.js native bindings.

@dominic some hints here?

I still want to push for this approach for a while since, once the native stuff are figured out, we can use our conventional approach of sbot server + ssb client with muxrpc to fetch data and display it, and it would be quite good as a basis for development since we wouldn't have to worry about performance due to a hacky stack of modules.

I could push the two efforts: the previous one for Android, and this new one for iOS. Whichever approach "wins" first in convenience and quality, we try to port to the other platform.

@mafintosh just pointed me to a version of blake2b that he handwrote in web assembly (supported in node 8 and all browsers except IE) it's only 1/4 the speed of c sodium, and the output file is only 1.5k! possibly this is will just make crypto viable as is

Current status: trying to compile node-sodium for iOS. Managed to compile libsodium for iOS arm64 (haven't tested it though), but to make the file build/Release/sodium.node I need to fight a bit with GYP and C compilation flags.

@tom: ssb-mobile roadmap

Super disappointed with a critical piece of software being closed source: https://github.com/janeasystems/node-mobile-react-demo/issues/1

Node.js is open source but they want to make Node.js-ChakraCore-iOS proprietary. It's not the first time I hit this wall when building something for Scuttlebutt, previously I bumped into http://underdark.io and OpenGarden MeshKit (how can you even name it OpenSomething if it's not open?).

Some good news: I'm investigating the possibility of doing that same iOS approach but for Android, and I found this: https://github.com/dna2github/NodeBase

So far, it's good! I got a full node.js process running in the background and it ran an http server which the React Native app was able to request.

That looks really good, and whats more, it's actively being developed! and there only a moderate amount of code to read!

in the readme it says:

Android NodeJS Platform to Build Sharable Application (Android as a Server)

Share application with your friends in the same Wi-Fi!

sounds like he's on a p2p vibe too!

Yep! And the node.js binary compiled for arm is v7, that's at least half awesome.

Update: I'm creating react-native-run-background-node-process (will find a better name) and hope it'll be a good foundation to build more stuff on top. E.g. next thing would be react-native-scuttlebot which just puts that one and scuttlebot together and it just works.

Hmm, I was under the impression that you couldn't start another process in a non-rooted phone, but it looks like he's just starting a process?

https://github.com/dna2github/NodeBase/blob/3976239d8e268622572dc18fba2f2f5d12e3d3fa/app/src/main/java/seven/drawalive/nodebase/NodeBaseServer.java#L117

Where does the arm node binary come from? is it the standard node arm binary? we gotta get sodium into that somehow.

Yes, that line you highlighted is what does it, and currently in my react-native-run-background-node-process I have that same thing going on. The arm node binary comes from here: https://github.com/dna2github/dna2oslab/tree/master/android/build

And yeah, my current status is trying to compile node-sodium for linux arm. libsodium already has a make system for android, so that's done. Next is to get node-gyp to do the job correctly. Sailing uncharted waters here, no web searching seems to help.

IT FREAKING WORKS

I don't know how else to say this: it works!!!

Basically I'm running a real node.js process in the background, which runs full scuttlebot (leveldown swapped for memdown, sodium is fully in JS, but fs and net and dgram and all the rest are the real shit) and the react native app uses ssb-client to communicate to that, and things... work.

Here's a video to prove it: https://instant.io/#3d7243c78252b94f6f803259123a64f9edefbf31
laptop can sync with phone and vice-versa. I'm also going to test phone-to-phone sync, but it should work too.

Next steps are getting the code published in different packages, and allowing each part to evolve separately. Obvious steps are getting an actual native libsodium and native leveldb, but those can evolve separately and then get plugged to the app later on. That's important so UI development can progress independently from the underlying infrastructure.

I'm super excited for this milestone

@dominic

Phone-to-phone sync over LAN, basically in real-time (judging by the naked eye, less than 100ms delay).

PS: I like the background process idea because when it's managed as an Android sticky service, even if you close the app the process can still be running. We could use this to enable proactive data sync, so when you open the app you just browse the latest content as if it was always there. This could of course be user-controlled in some settings screen.

So exciting!

WOW awesome! Can't wait to try this!

@dominic to get the repo reproducible for others, I'd need you to merge a PR for noderify first :)

The repo is http://localhost:7718/%25XnPjP9GWJ4z7W51Hh%2FUkc0aouHbY1AvxcQE5mkPLDwc%3D.sha256/tree/sbot

and branch sbot

Images work too. I just put serve-blobs.js from patchwork and it hosted the images like any other web server does, and React Native <Image> knows how to consume that localhost URL. The nice plus is that you can also open the URL in the mobile browser! (Finally you can run a localhost node.js server on mobile easily)

Just published react-native-ssb-client https://www.npmjs.com/package/react-native-ssb-client

API looks like ssb-client, but is meant to be used in a React Native app. See my sandbox repo, branch sbot for an example usage. Basically just put "react-native-ssb-client": "1.0.4" in package.json dependencies, then in index.android.js, import ssbClient from 'react-native-ssb-client'; and use ssbClient like you usually would use the npm package ssb-client.

I just moved that to the ssbc org: https://github.com/ssbc/react-native-ssb-client

wowowowow, very exciting, excellent work @andrestaltz

I kind of finished react-native-scuttlebot, once @dominic releases the new version of noderify, I can publish it.

Usage would be quite sweet: scuttlebot.start() then use react-native-ssb-client like we use ssb-client, both in index.android.js.

Here we go:

• Create a new React Native project (android-only)
• npm install https://github.com/ssbc/react-native-scuttlebot
• npm install https://github.com/ssbc/react-native-ssb-client

Use them in index.android.js like specified in their readmes

See http://localhost:7718/%25XnPjP9GWJ4z7W51Hh%2FUkc0aouHbY1AvxcQE5mkPLDwc%3D.sha256/tree/sbot for an example

Lots of congrats, Andre!

@RubberDuck not yet, but once I do I'll certainly update this thread.

Today I got all the pieces in place, to start actually building the app: I have a RN app with the SSB modules I made, plus some framework stuff, some basic components, the app's GUI skeleton, icons, etc.

The four tabs are:

• News feed
• Channels (?)
• Metadata
• Notifications ('mentions')

Metadata is a screen showing your connected peers, gossip data, a dashboard of ... metadata, etc. This will be a place where the user has access to raw data about everything they store on device. You add pubs here, you accept invites, etc.

I'm not sure if I should have Channels as a tab. Channels can also live in the menu accessible from the menu button on the left. Maybe I should have

• Public
• Private
• Metadata
• Notifications

Thoughts?

This was what I achieved today and tomorrow I'll start making the basic news feed screen with messages and publishing, hooked up to background-scuttlebot and using some patchcore primitives.

@andrestaltz nice !

I prefer public / private / notifications / channels. I think meta is mainly useful for diagnostics, and for getting set up.

I guess initially users will be people who already have SSB identites on network. They can friend their phone identity and that will side-step need for onboarding (pub invite) functionality in this app. I know it's needed in the long run, but I'm a fervent believer in "just build enough to get people using the thing" and there's an active group of people who we can test with before going wider.

OOOOHHH boy, I'm pretty darn excited for this. If I even have read-only I'll be ready to pretty much drop FB

Yeah maybe I should do public / private / ...

Don't get too excited just yet (I know screenshots have that effect ), it really does nothing for now. Mega important features to build are: thorough and fully-supported messaging publishing and markdown rendering, but really: efficient storage. Just think how long it will take to sync with your desktop scuttlebot, if it even fits on your mobile device! :D

from the latest Patchwork (which i'm enjoying most):

Public / Private / More --- Profile / Mentions

where More has

• Channels
• Gatherings
• Extended Network

Well, notifications can come from public or private, they are basically "mentions". Like I can mention you here like this @marco28. Also notifications will include a few other wildcard things like "Set up your profile" when you open the app initially.

I bring news:

And repository: https://github.com/staltz/mmmmm-mobile

Milestone for today was using patchcore and sbot to fetch feed messages, and render them. The raw JSON box you see there will be displayed only for "messages of unrecognized type". Currently all message types are "unrecognized" but obviously it's just a matter of time until we build message components for each message type. The feed works. I tested it: with patchwork on my desktop, a new message appeared in real time on the phone.

Of course, consider this app to be a work-in-progress for a long time. I think I'll consider it "ready" when it's in the Google Play Store (unfortunately to reach a lot of people I need to go through that disgusting paywall).

@CustomDesigned Good point, SD card storage will be a must. Right now it's using the app's storage space, which is usually not in SD, but this type of configuration is possible, for sure.

hey @andrestaltz I'm not the sort to blow up with expectations. I mainly want to make sure you're getting enough positive vibes and encouraging feedback :)

I'm very realistic about the alpha nature of this, AND am really happy and willing to wade into testing alpha apps to support people doing rad work <3

The apk on github https://github.com/staltz/mmmmm-mobile/releases/tag/v0.0.1
cc @dominic

I got basic metadata like connectedPeers appearing in the app, using patchcore modules, but I had to pause to figure out how to display that data in the app in the correct way.

So I did some bit of designing in Sketch, and here it is:

The 1st screen (on the left) lets you choose to see either the 2nd or the 3rd screen.

Feedback?

Exciting :).

On the 'Peers on the internet' screen are the dots on the globe an accurate representation of where the node is based, or is it just a way to signal to the user that they are 'somewhere remote on the internet' and the location of the dots on the globe are not relevant?

@happy0 my guess is, it uses geoip to map the location. So if the node uses some kind of vpn or proxy it could be anywhere but it's still a nice way to visualize it, I think.

It will (doesn't yet, it's just design) use geoip to pinpoint the location.

Here's an update: I coded the first version of the above. This screenshot is real data from my LAN:

looks great! what if you animated latency (peer.ping.rtt.mean) by showing dots moving between the peers?

@dominic I had planned to do that ;)

News

Markdown rendering

Simple compose message field, that actually works

Expand/collapse local peer metadata

Really could have used this on my vacation. Glad to see it coming along nicely!

version 0.0.2

https://github.com/staltz/mmmmm-mobile/releases/tag/v0.0.2-alpha

newest thing is like counter and like button

Just installed it and peers around you is working! How do I set up so I can see messages?

This is really exciting @andrestaltz!

Seems to be as easy as following the local peer. Nice!

@keks That's good feedback, I'll try that. Also makes sense given that Twitter mobile app also has notifications tab as the 3rd tab, not the right-most tab.

@ub|k It should work if both phone and computer are on the same LAN. Make sure your phone's WiFi is on, and maybe reinstall the apk.

In general, this is very early alpha software. I'll label it beta once I start believing it's usable.

Build for 7.1 on 32bit HTC m8 https://instant.io/#9648b7d2e061431cc97fd1437725b35d42755ae3

worked great, just got stuck when I was running weird react-native commands instead of just doing npm run

I think it's actually syncing faster than my macbook pro did first time round

@ub|k scuttlebot broadcasts its address on UDP and detects addresses it finds broadcasted, adding them to the gossip table. the actual SHS connections are unicast.

@ub|k
with zeroconf, peers broadcast queries and respond to queries that they see broadcasted. this is a more standard way of doing local peer discovery.

sbot local peer discovery is basically just hello packets repeatedly broadcasted (every 10 seconds) - there is no query/response.

UPnP is used to tell the router on your network to forward a port to you from the WAN. eventually we might want to use this to let home nodes automatically become pubs.

Great to hear @n8fr8! That's awesome, I'm aware of Orbot.

I'm not sure if you know about this already, but I think SSB supports Tor too, inside multiserver: https://github.com/ssbc/multiserver#onion

About SSB on mobile, we need help. Most important problems to solve are:

• Node.js on iOS: collaborating with these folks https://github.com/janeasystems/node-mobile-react-demo
• Support armv7 in react-native-node
• Migrate react-native-node to J2V8 https://github.com/staltz/react-native-node/issues/5
• Compile leveldb to arm64 and armv7 for android
• Compile sodium to arm64 and armv7 for android

Both leveldb and sodium/chloride are huge important pieces of the infrastructure that currently aren't working at all. (we use RAM for "storage" and slow crypto-in-js)

:)

@crasch the model i'm using for my p2p app toolkit is something i'm calling "anonymous pseudonymity". basically, your identity is an asymmetric keypair that can't be linked to a specific physical device, network address, or location through normal coms so, if you want strong anonymity you can discard your key after every session and/or keep certain keys around to provide a reference persistent or semi-persistent identity.

https://journal.xj9.io/posts/2017/what-am-i-doing-with-my-life/#router

Hey @andrestaltz been trying to learn more about #ssbc, projects and the grants system and something got into my head which I don't know how it could work. My main doubt is how can you have the same identity in more than one machine since we can't have forks/merges of the log. The mobile version would use a different identity than the desktop/home version?

@SoapDog, check this: %JjSO5d5...

thanks a lot, that is much simpler (as in more straightforward) than I imagined. I thought about breaking changes to the protocol. Glad to learn that it can all be solved on an upper level.