Nimbus on mobile

I guess we’re getting close to the point where we’ll need everyone to move to the new desktop and mobile clients, with new chat identities. And upgrade the bridge bots too, of course. cc @jakubgs

No they are not backward compatible.
It was not just the part of the hash that is being checked (the leading zeroes counted), but also the hashing done itself. They would actually do a keccak256 hashing twice (whisper v5 leftover). If you’re lucky to have enough leading zeroes also with the other calculation, your message will not be dropped.

If you want to remain compatible you have to either lower the PoW requirement even more (practically 0) or (temporarily) implement and use both calculations at receiving end.

@pedro I was waiting with the switch to new chat identities until Keycard initialization works properly. But now that I think about I’m actually not sure how that would work with desktop. If I create an identity on mobile with my Keycard I assume I’d need a usb card reader for my desktop to recover it there, right? Is that something we support?

Hmm good point, I’d hope so. Maybe @gravityblast knows something about that?

There’s no Keycard integration for desktop for now, so you won’t be able to use it. Unless you enter your mnemonic on desktop, which is probably something you don’t want to do if you have a Keycard.

Why is that? Would that work? Wouldn’t that just give me a different address without the Keycard?

It would give you the same chat key, but negates a lot of the security benefits of using a keycard, as the keys have left the hardware wallet and live on a very buggy alpha desktop connected to the dirty internet.

Right, so we(core contributors) might as well not use Keycard at all if we want to use desktop app for work in the future. Unless support for keycard for desktop is planned as well.

If that is the case then we might as well bite the bullet and pick a day to switch to V1 chat identities soon, right?

1 Like

I’ve been forgetting to post the daily progress here (I’ve been doing it in #status-standups), but where we stand currently is that we have a refactored status-protocol-go that is ready to receive Nimbus under a facade, and updated status-go/status-console-client that consume that facade. I’m ready to start working with Kim to bring Nimbus to status-protocol-go. Our bi-weekly meeting will happen today to coordinate efforts.

1 Like

Daily progress:

  • After fixing several issues with C <-> Go marshaling yesterday, I started investigating more complex scenarios like using the subscription to a filter to emulate the arrival of envelope events, but this requires ugly changes to the Nimbus API and is not really required for the console app PoC, so I’ve decided to focus on getting a minimal implementation working and work from there.

Daily progress update:

  • Back from vacations
  • Current state:
    • Nimbus wrapper implementation is halfway done, although the last 20% will be more thorny (e.g. envelope events), but we should have enough surface for a PoC;
      • Resyncing with changes in Nimbus side;
    • Go bindings of Nim methods still need to be tested in the field.
  • Next steps:
    • Need simple way to build Nimbus API (Kim suggested using Nix);
    • Integrate this Nimbus API build with status-protocol-go and status-console-client builds.

Daily progress update:

  • Fixed build errors in Nimbus wrapper when building with
  • Got the console client to build with and started looking into runtime issues. The existing proof-of-concept app polls in the main thread and doesn’t show any UI, but for the console client we need to show a UI, so ideally we’d do the polling in a goroutine. Unfortunately, the nimbus API library doesn’t support being called from other threads at the moment, so we’ll need to figure out a solution there.

Daily progress update:

  • we found a couple of issues that are causing a crash when calling nimbus_addkeypair:
    1. the call is coming from a different goroutine (within the encryption layer of the protocol project)
    2. The Nimbus API implementation is calling tearDownForeignThreadGc() too early

For 1, I’ll be implementing a request queue that will guarantee that the calls to Nimbus are done in the expected thread (the one where it was initialized).

Daily progress update:

  • Fixed crash in nimbus_addkeypair by implementing a request queue to ensure calls are made from the expected thread. Removed setupDownForeignThreadGc/tearDownForeignThreadGc calls in Nimbus API.
  • Started investigating encryption issue in messages passed to nimbus_post (“Couldn’t decrypt using asymmetric key”).

Daily progress update:

  • Fixed origin of encryption error in Nimbus wrapper code - the console app can now post Whisper messages to the network.
  • Will start working on implementing GetFilterMessages from message queue populated by message handler callback passed to Nimbus filter.

Daily progress update:

  • Added support for passing private key, listening port and cluster to Nimbus wrapper.
  • GetFilterMessages is now implemented in the Nimbus bridge. The app is now able to receive messages (although a hardcoded Sig public key value is required at the moment).
1 Like

Daily progress update:

  • Helped @deme investigate a bug on the Nimbus side, which he fixed, meaning we now receive the correct public key in messages, and we no longer have to hardcode it.
  • Cleaned up the code on the Go side.

The console app is now fully functional on Nimbus as well as Geth, based solely on a -nimbus command line argument. There are a few remaining improvements to be done on the Nimbus side, and now the remaining major issue is managing the dependency. Right now it’s being copied manually, but ideally we’d have some form of dependency management for it. One way to do it is with Nix, by building our branch of the Nim compiler, and then using that to build the Nimbus repository. That’s what I’ll be working on next.


Daily progress report:

  • Finished the integration of the Nimbus Nix build with the console client project.

If you want to take the Nimbus console client for a spin, just run the following commands:

git checkout -b feature/status-nim && \
cd status-console-client && \
make build-nimbus && \
./bin/status-term-client -nimbus -fleet eth.staging

then in the bottom line (use TAB key to cycle through panes), type /chat add status to open the #status chat.

Note: There’s a UI glitch in that you must first select a chat in the top-left panel by pressing ENTER before being able to post messages to it.

  • Current state
    • Nimbus node is fully integrated in console app. PRs are in review. Nimbus API library is built by console client project using Nix expression from Nimbus repo.
    • Some unused APIs are not yet implemented (e.g. NewMessageFilter, SubscribeEnvelopeEvents, GetFilter, SendMessagesRequest, RequestHistoricMessagesWithTimeout, SyncMessages), however this PoC should be enough of a foundation to clarify how those will need to be implemented.

I’m considering the console PoC closed for now, since it demonstrates that the idea works and can be extended.

Next steps would be to integrate Nimbus in status-react (without envelope monitor or mailserver functionality):

  • generalize StatusNode to use facades over the actual node implementation (tricky since there are many supporting types from geth):
    • plug in call to nimbus_start in StatusNode.StartWithOptions (in this case, we’d not register mailserversService)
    • add missing configuration options to nimbus_start (e.g. bootstrap and static nodes, etc.)
    • implement RPC functionality between Nimbus and status-go and abstract it behind a facade
    • implement facade over service management API (gethNode.Service(serviceInstance))
      • implement support for service management in Nimbus bridge
      • bridge with respective services in Nimbus (wallet, ShhExt, accounts manager)
  • Add an argument to params.NodeConfig to determine the type of node to use (this would be passed from the UI in status-react).
    • Add UI in status-react to determine the ETH node type.
1 Like

Daily progress update:

  • Starting to look at using Nimbus in status-react. This is a huge undertaking considering how closely tied status-go is with geth types.
  • To start with, I’m exposing whispertypes.Whisper as a geth service, to make it easier to replace the SHH node type in a single place in status-go.