Nimbus on mobile

Archive Software Engineering
21

Important note on those PoW changes: Whisper in Nimbus has always used that new PoW calculation (To be fully correct: there is still a small difference on size calculation, which I could easily alter. But it does do the same hashing).

Is there a plan on moving to that version?

22

Interesting,
so is this POW calculation backward compatible? i.e if I send a message using the new POW calculation (1.9) will it be accepted by 1.8 ?

The reason I am asking is that when we did our experiments we would only get through 8 out 2000 messages for example, from nimbus to geth, wondering if maybe thatā€™s the reason.

23

Iā€™m pretty sure that they are not backward compatible. 8 out of 2000 sounds statistical in terms of randomly getting the right PoW. IIRC it had to do with what part of the hash was being checked for PoW (front or back) so to be backwards compatible we should check both.

This should be fixed asap in status-go or status-protocol-go, wherever it lives.

24

I think some work is already underway, https://github.com/status-im/status-go/pull/1617

25

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

26

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.

27

@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?

28

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

29

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.

30

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

31

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.

32

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
33

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
34

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.
35

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.
36

Daily progress update:

  • Fixed build errors in Nimbus wrapper when building with libnimbus.so.
  • Got the console client to build with libnimbus.so 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.
37

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).

38

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ā€).
39

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.
40

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