SAFE Network Dev Update - June 6, 2019

[maidsafe]

Summary

Here are some of the main things to highlight this week:

• RFC 59 has been published today. It describes a proposal to integrate Boneh-Lynn-Shacham cryptographic scheme into Routing.
• safe_client_libs is now actively using Jenkins To read more about Jenkins, why we introduced it and what benefits we believe it will bring us, see this forum post.
• We’ve put out a new edition of SAFE Buzz with @ravinderjangra.

Marketing

First off, thanks to @Sotros25 for running another SAFE Network: Chicago meetup - check out some of the pictures here! Along with helping the QA guys out with the Jenkins post below, we’ve also put out a new edition of SAFE Buzz with @ravinderjangra, who talks about the journey that led him to discover the SAFE Network.

Today, @dirvine’s been attending the Energy Innovation Emporium 2019 whilst next week, @dugcampbell will be down in London at the Web 3.0 & Decentralised Future stream of the CogX Conference. There’s a great line-up of many of the biggest decentralised projects across the scene and no doubt some fascinating conversations to be had - so if you’re also heading along, please do reach out for a chat. Finally, we’re now also supporting the Scottish Blockchain meetup on Wed June 19th where many of the team will be heading along to hear Andreas M. Antonopoulos talk in Edinburgh.

Some unfortunate news this week. Over the past couple of weeks, we’ve been forced to make a couple of redundancies to reduce the operations and admin headcount in the Ayr HQ with a view to maximising our engineering spend moving forwards. Alas, this has meant that we’ve had to part ways with @dgeddes and @kayley. Both carried out a truly sterling job for us over the past year or so and both were hugely well-liked throughout the team so we’d very much like to publicly thank both of them for all they’ve done and given to the MaidSafe cause during that time. They remain committed SAFE Network advocates and hopefully you’ll see them remain in the community moving forwards. We don’t anticipate any further redundancies at this time.

SAFE API & Apps

This week has seen some investigation into a new issue in the browser build process on Linux, and we’ve uncovered some issues with electron-builder itself. The electron-builder team is taking a look at the issue, so once a fix is merged we’ll update our dependencies there. This came about as part of our testing for Auto Update in the browser (which is otherwise looking good!).

The PoC $ safe CLI has continued at full steam during last week. As can be seen in this public project board, we were able to implement several sub-commands for both the keys and wallet top-level commands. For example, we already have the implementation (against an internal and temporary mocked safe_client_libs API) for generating BLS key-pairs, which are then stored in a Key on the mocked network. We’re even able to preload a Key with some test coins, as well as creating a Wallet and inserting Keys so they can then be used to make transfers between Wallets and Keys. We know it may be a bit confusing now, but we are planning to start shortly with a user guide which should make all these use cases much clearer and hopefully extremely simple to understand and use.

Right now we are finalising the review and testing of two PRs which would allow CLI users to use XOR-URLs based on CID (choosing base32 or base32z as the base encoding for them), as well as making test coin transfers between wallets and checking their balance.

We are also expecting to be able to remove the temporary mocked safe_client_libs API early next week, and start integrating it with the real APIs exposed by the safe_client_libs crate, using the new data types, which would allow us to start using all the wallet CLI commands on the SCL mock network.

SAFE Client Libs

This week we’re continuing with the work related to the new data types, the mock Safecoin, and some other nice things that come with them (like supporting multiple data owners and multisig through BLS keys). We are seeing some good progress with that and we’ve already implemented some of the functionalities of Unpublished Mutable Data in the mock Vault. We’ve also completed the definition of Append Only Data in safe-nd (the network data types library). Soon we’ll be moving on to FFI functions for Unpublished Mutable Data, Append Only Data, and Unpublished Immutable Data.

However, during this milestone we don’t plan on removing the ‘classic’ Mutable Data, used by the internals of the SAFE Authenticator, for example. However, we will expose the new data types for app devs, but won’t use them internally ourselves at this stage.

Routing

This week has seen further work on a few different fronts.

We continued to progress the RFC for making use of BLS keys within the network. This included a presentation of the current state of the RFC-in-making, and as a result of that, some further work has been completed, and the RFC is now published and has a corresponding thread in the forum.

Meanwhile, work to replace Crust with quic-p2p has started in Routing. Currently, we have a PR introducing a mock quic-p2p interface which allows us to test the integration while we complete the full replacement of Crust.

Some of the Routing tasks have been documented in a number of GitHub project boards.

Finally, work is continuing with the Vault proof of concept. This has involved both the vault crate and safe-nd crate, since the vault-level RPCs, the data types, and node identities are being migrated there from Routing. This will ultimately result in being able to break SAFE Client Libs’ dependency on Routing.

quic-p2p

We want to announce there will be no updates about quic-p2p in the coming weeks because we don’t anticipate any more effort (apart from the maintenance work) going into this project before the network launch. This will enable us to shift our resources into the other libraries to make them launch ready!

QA

This week we have reached a major milestone on the path to using Jenkins to deliver an automated release process for all our deliverables - safe_client_libs is now actively using Jenkins

Jenkins is a leading open source automation server, widely used to enable CI and to help facilitate continuous and automated delivery. A lot of planning and development time has gone into setting up a robust and secure infrastructure to ensure this setup works for us. It will be used on the safe_client_libs repo from now on, and will gradually be rolled out to other repositories when suitable. Kudos goes to @chriso for a huge effort in making this a reality - we are sure the benefits of this effort will be seen over the coming weeks, months and years.

If you want to read more about Jenkins, why we introduced it and what benefits we believe it will bring us, we have published a Medium article here and a separate forum post here.

[zero-ghost]

first… i hate people that say first

[happybeing]

Second haha!

Placed two weeks in succession

[Mendrit]

Good progress towards Flemming.

[davidpbrown]

@maidsafe

We’ve put out a new edition of SAFE Buzz with @ravinderjangra .

Enjoyed that… and ooh… will start working on SAFE mobile browser soon.

@maidsafe

test coin transfers between wallets and checking their balance.

exciting.

@maidsafe

XOR-URLs

Is there an example of the form of that… would that be a bitcoin like address length random string… and could it be converted to three words coded or similar human form?

Would be interesting to know or see some visual sense of which parts of code are relatively stable and which are high-flux. If there’s something stable that’s just bug fixing, it’s more tempting to take a closer look.

[Nigel]

Hate to see @DGeddes and @kayley go but I hope to see you still around the community and project! Wish you both well and it’s been a pleasure talking with you David. Take care!

Great update once again. Glad to see the connection layers resources are no longer a worry and can be allocated elsewhere!

The safe wallet/CLI stuff is really exciting stuff! Great way to drum up interest if you ask me.
Keep up the great work @maidsafe

[bochaco]

@davidpbrown

Is there an example of the form of that… would that be a bitcoin like address length random string

Some very early and random examples we are playing with while coding (this sequence doens’t make sense, just for you to see how they look like):

$ safe_cli keys create --test-coins --preload 15.342
Note that the Key to be created will be preloaded with **test coins** rather than real coins
New Key created at XOR-URL: "safe://bbkulcbnbzajdbjklusqkltoir4ax7jyx4j5e3ghp6rdab23qojfhb3nr2"
Key pair generated: pk="b439024614a9749414b9b911e02ff4e2fc4f49b31dfe88c01d6e0e494e1db63a66b0db6303359b275d2ca0b0bbf2b7f9", sk="41f6d0f08de264911a592d6e92db62e1112d6991155fe262c337922f4a0d0b3f"

$ safe_cli wallet transfer 25 safe://bbkulcaghlu6324bhx6ujviqbtiomw4sx5uj4ftpwfzyuunljnobc5ow4f safe://bbkulcbdybjgpb5mepivn3mpegyms3awqulnkzwz37tyiefik5esca5s6f
Transaction Success. Tx_id: 44dcd919-0703-4f23-a9a2-6b6be8da0bcc

[happybeing]

I’m sorry to see David @DGeddes and @kayley go in this way, it can be difficult all round. I wish you both the best and hope to see you on the forum.

The update is otherwise very welcome. I’ve already been noticing the progress on CLI and new data types on github, and watching them creep into existence is very exciting.

@dirvine I want to make a request here that the API docs are fixed for desktop. I have said this before, but I’m going to repeat myself because they are a real pain to navigate. They use ‘hover’ rather than ‘click’ to control the left hand pane which is awful. Every time I use them I want to smash the thing to pieces, so would very much appreciate that being addressed because with the new APIs on the way, they will be much needed and I may not survive this torture much longer.

Otherwise I’m a happy bunny working away when I get the chance, still trying to create a really easy way for Solid apps to use SAFE Network including the new WebID selector and user profiles. I’ve been held back quite a bit messing around with node module issues but think this are sorted now. I’ve also been investigating the experimental RDF & WebID APIs and have after a chat with @bochaco have a plan going forward.

[Michael_Hills]

@maidsafe

This week we’re continuing with the work related to the new data types, the mock Safecoin, and some other nice things that come with them (like supporting multiple data owners and multisig through BLS keys).

It’s great to see mock Safecoin being dabbled with. I’m excited! Great work yet again team, just moving right along toward Fleming!

[david-beinn]

Best wishes to @DGeddes and @kayley wherever life takes you. Great to meet you at the Glasgow meet-up David, hopefully there’ll be a next one too.

@happybeing

I want to make a request here that the API docs are fixed for desktop. I have said this before, but I’m going to repeat myself because they are a real pain to navigate. They use ‘hover’ rather than ‘click’ to control the left hand pane which is awful.

Haha, 100% agree with this. Like @happybeing I like to consider myself a happy, peaceful sort of person on the whole, but I too want to smash it to pieces! Same goes for the hover on the pop-up window in the latest Authenticator…

[happybeing]

@david-beinn

Same goes for the hover on the pop-up window in the latest Authenticator

Agreed, activate on hover is most often a poor UX IMO. Even major websites do this for navigation and I don’t understand it because it creates such a bad experience for me. Click I say, activate on click!

[david-beinn]

While we’re on the subject, I think the meaning of the padlock in Authenticator could be better signposted. I spent a whole day the other week trying to work out how I could avoid constantly asking the client to re-authorise the app, before realising that was what the very pale grey padlock in the corner did.

Maybe I just need to go to a lower API, but would be nice eventually to have an easy way of testing for authorisation without always triggering the pop-up. This would enable an app to only ask for specific container authorisations as they were needed, which I think would make everything more ‘real’ to the client.

Currently the only way to do it really is to ask for all the permissions as soon as the user lands on the app, which I can see leading to a GDPR sort of mindset where clients are just clicking to make the box go away without even thinking about what permissions they are giving.

[Secretariat415]

Thanks so much to the team for all your hard work!

Good luck to the outgoing admins in all future endeavors.

[bochaco]

@david-beinn

Currently the only way to do it really is to ask for all the permissions as soon as the user lands on the app

Just to add info here, there is a separate type of request apps are expected to send for this scenario, which is the containers auth request, so after an app was authorised with a set of permissions, the app can request for more permissions to be added by calling that other type of request.

[JPL]

Oh no! @DGeddes and @kayley That’s a real shame, you’ve both been doing a fantastic job. I hope you’ll be back on board once the engineers have done their thang and eveything takes off. Keep visiting here til then. Another nice SAFE Buzz video - thanks @ravinderjangra and @Cgray.

[david-beinn]

Yeah, thanks, the sort of example I had in mind was, say, I have an app where the user can choose their own theme, which is stored in, say, public container. However, if someone hasn’t authorised access to public container, there is a default theme. The only way I can check whether the theme has been stored though, is by requesting access to the public container, which automatically triggers the pop-up. What I’m looking for is an option to even just throw an error, which can be used to revert to the default theme, rather than triggering the pop-up. In this example, the pop-up would only be triggered when someone wanted to actually choose a theme.

This sort of thing would be particularly useful when using getConnUri, so that a previously authorised user could be served whatever they have saved, but a new user us untroubled by any requests for access, until they are really needed.

Hope I’ve explained that clearly (and that I’ve understood the API right)!

[jeremyjpj0916]

Really appreciate the efforts of @dgeddes and @kayley , hope you both will swing in from time to time and maybe even return one day. Its always tough having to adjust as a company for the focus or need at a given time but its required in startups where budget is limited.

Glad to see SAFE team leveraging jenkins, we use it at the co I work for all the time, builds/deploys/real time validation cron jobs/code scans. It really provides a robust toolbox of goodies. Onward march.

[happybeing]

I’ve not done it myself yet, but I’m fairly sure you can check permissions without requesting them. I think I saw it explained on the Dev forum a while ago.

[david-beinn]

Thanks, I’ll have a dig around there and see what I can find.

[happybeing]

See here

https://docs.maidsafe.net/safe_app_nodejs/authinterface#getContainersPermissions