Few notes and leasons learned while developing the Zignals app

1. SN works

My main concern was if the SN posseses all the required ingredients for creating a real life app. Well, it does.

2. Native bindings are hard to use directly and there is a need for a wrapper lib

I did not used the safeapp because it contained a lot of statics which interferes with the dependency injection, unit testing and thus CI. Instead I have created few layers of abstraction. The idea is (1) To insulate the developer from changes in the lower layer (since the API is still not stable and it will change); (2) To create convenience classes that are easy to use.

Currently the zignals app have following layers (starting from bottom):

  • Native bindings - this is the java “bridge” to the rust code. It is provided by the SN team
  • Prospero lib - fancy named pure java library that provides mostly interfaces like KeyValueStore wrapper around mdata and also wrapper exceptions for the errors like InvalidEntryActionsException, KeyAlreadyExistException, etc.
  • prospero-safe-alpha-2 lib - contains implementations of the interfaces specific to the alpha-2. When we move to alpha-3/flemming/maxwell this lib will be replaced,
  • prospero-safe-alpha-2-android - contains android specific classes for bootstraping like ProsperoSnRealInitialisationAndroid and ProsperoSnMockLocalInitialisationAndroid.
  • Zignals lib - pure java library that contains the zignals functionality, i.e. it can be used potentially not just for android but also for desktop and CLI.
  • Zignals app - contains the android interface to the zignals lib

Probably similar set of layer should be used for all apps.

Weight distribution:

  • Prospero lib - 1020 LOC
  • prospero-safe-alpha-2 - 2306 LOC
  • prospero-safe-alpha-2-android - 43 LOC
  • zignals lib - 1280 LOC
  • zignals app - 3026 LOC

As a rough estimate I expect that fully featured:

  • prospero lib will grow to about 10 KLOC - with 200 lines per day = 50 days, 2.5 months
  • prospero-safe-alpha-2 - 20 KLOC - 100 days, 5 months
  • zignals lib - 10 KLOC - 50 days, 2.5 months
  • zignals app - 40 KLOC - 200 days, 10 months

3. Documentation

One of the main problems is the current lack of documentation. I expect that when the API is stabilizied this problem will be fixed. Most important at first will be documenting what errors may happen during a (NativeBinding’s) method call.

4. Safenet debug server (local)

Currently we have mock/non-mock. Mock is for local, non-mock for alpha-2. The problem is that for some apps we will need a SN server that simulates the network and in the same time it is local for the devs and testers group. The reason is that currenly we have 1000 PUTs cap per account and it is not enough for high throghput apps. Even if that limit is raised - there is no need to burden the alpha-2 net if there is a option for local SN server.

5. Open sourcing

Initially I meant to publish the zignals app and libs on github but later decided that probably it is not good idea at this time. From my experience with previous open source project I know that each published repo requires a lot of time to support it even there a relatively few devs using it. Currently I don’t have that time :frowning:
Probably I will publish it when we are using Fleming, the API is stabilized and the zignals app and libs are somewhat more mature.

I am amazed by the work that the core team is doing. The entire SN concept is mind blowing and I can hardly imagine how hard is to implement it. Great job!


Awesome, the detailed feedback is really much appreciated and we are taking it to heart. This should be helpful for other app devs, as well :slight_smile:


Thanks for the extensive feedback!
We will most definitely take all this into consideration moving forward! :slight_smile:

The initial release of safe-app-android was put together to give Java / Android developers something to play around with and give their feedback. We will iterate over this to soon provide a better, more developer-friendly API. In fact, there is a plan to have simpler Rust libraries so that the API in all languages will be the same and super-easy to use.

Along with this we will most definitely work on improved documentation.

In the meantime, if you’d like to see the list of possible errors, this would be a good starting point.

For this there is already something available, you can run vault(s) locally and connect to them to test your apps in a local LAN setup.
This post should have all the information that you need.