MaidSafe Dev Update - 20th September 2016

Development Updates
1

Last week, we released the first dev tutorial along with TEST 9.

The next tutorial will be announced in about 2 weeks. Our goal is to release a new tutorial roughly every 2 weeks (for a total of 6 tutorials).

The URL of the SAFE Dev Tutorials website is tutorials.safedev.org. The source code of this website is hosted on GitHub. Anyone can easily submit a pull request by forking this GitHub repository.

The source code of the SAFE Mail Tutorial app is also on GitHub. Even though it’s a desktop app built with JavaScript and Electron, it would be possible to build a similar app in other environments (e.g. a web application, a command-line application, etc.) and other languages (e.g. Python, Go, Ruby, Rust, C#, etc.) since the requirements for using the SAFE Launcher API are very minimal (developers just need to be able to make HTTP requests).

We don’t expect devs to build complex apps (e.g. a full-featured messaging app) right away, but we hope they will find these tutorials useful and will start using the new low-level APIs :slight_smile: To give feedback regarding SAFE Launcher API v0.6, please use this Dev Forum topic.

API Documentation

We are planning to move the SAFE Launcher API documentation to a static website generator. We are exploring a few options and we will confirm which tools we will use next week. In addition to migrating the existing documentation, we will also add documentation for the new low-level API endpoints.

SAFE Launcher

We are integrating the CI this week for safe_launcher now that we’ve finished the React/Redux integration. There are few minor bugs identified with the SAFE Launcher binaries from TEST 9, they will be fixed this week.

After the initial implementation of the SAFE Launcher API for exposing low-level APIs, there are a few more APIs which are pending to be integrated. Along with that we are also planning to improve the efficiency of the low-level APIs by mapping them directly to the APIs in safe_core. To propose this change, Krishna submitted this pull request earlier today.

SAFE Core

We are now aiming to provide a common backend for low-level APIs and nfs/dns API paths. For instance, the directory hierarchy encryption scheme is being changed to the following: use a random secretbox::gen_key() for each private directory and store this key in the parent directory (and in the account packet for the root directory itself). Every time we modify the content, we will generate a fresh Nonce and encrypt the content. The final data will look like this: serialised(nonce + ciphertext).

Apart from this, we are adding a few APIs that are wanted by Launcher - e.g. expose the version field of StructuredData and include the number of versions in versioned StructuredData in the data field itself for faster access.

Routing & Vault

A few more comprehensive tests for appendable data have been added and the routing table part of RFC 37 - Disjoint Groups is implemented and is currently in review. We are now working on integrating it with the core of the routing library.

There is also a lot of design work ongoing, and discussions about security measures like RFC 44 - Secure Vault Joining.

SAFE Browser RFP

@joshuef posted an updated version of the SAFE Beaker Browser yesterday.

This week we are going to start looking at options for packaging the SAFE Beaker Browser with SAFE Launcher. For example, there could be a checkbox that lets users choose if they want to install the SAFE Beaker Browser at the same time they are installing SAFE Launcher. We will also need to think about the user experience (e.g. should there be a button inside the SAFE Launcher that lets you open the SAFE Beaker Browser?). We’ll start a discussion about this on the SAFE Dev Forum next week.

46 Likes
3

Let’s get another tutorial in while the equity raise is live yo! Another good update, noses are definitely to the grind stone refining things for developers. Keep kicking butt maidsafe

3 Likes
4

Thanks for the update :+1:

Yeuhhhh, this is great news. Nobody will see the difference as it all happens somewhere on the background but this is a great step. I hope all tests go well. Is there any update on the minimum and maximum group_size before splits and merges?

6 Likes
6

I think that packaging the SAFE Beaker Browser in the Launcher is a great idea! For new (non tech) people it’s better to push them towards a secure browser. I would recommend to enable this option by default with the possibility to disable this.

Curious for the next tutorial in 2 weeks!

10 Likes
7

Thanks for another great update Maidsafe team,

Totally agree with this.

Small details, but maybe it’s time to start using safe:// instead of html:// for your SAFE Network url’s.

1276×664 94.5 KB

Use: <safe://the.odyssey.safenet for the URL
Your SAFE Beaker Browser will bring you directly to the site that way.

If you don’t, your SAFE Beaker Browser will show your visitor
This site cant be reached

ERR_BLOCKED_BY_CLIENT

It would also help in the demo app if the links are safe:// and if the SAFE Beaker Browser is the default browser that starts up when you click on the link:

1012×704 23.9 KB

I’ve wondered about this also, can’t the demo app just be another tab in the SAFE Launcher?

766×594 40.3 KB

10 Likes
8

Thanks so much for all of the hard work. What topics will the next 5 dev tutorials cover?

1 Like
9

My guesses are:

  • LifeStuff (saving contact lists)
  • WorkStuff (sharing ownership of files)
  • More instantaneous chat
  • (test) SafeCoin Wallet tutorial
  • Video chat? ← my least certain guess

Any other guesses?

2 Likes
10

I would think they’ll have something using data chains. I hope anyway, that is going to be massive.

4 Likes
11

Whats the URL for the network viewer anyone?

12

its as if they are swaped. demo gives me launcher and vice versa.

13

Still think splitting the community and information was a bad move. I certainly find less info than before and am sure many many more don’t have time to follow the DEV forum making progress seem stagnant. Creating a buzzing community in one place should have been the focus. This really annoys me.
Off my chest :rage:

14

Kinda agree, it’s pretty dead over there.

Would there be a way to merge it with this forum, but strictly only allow development-related discussions?

Not our call to make though.

Also, maybe the dev forum really is working at 100%, and it’s just showing us that we need more programmers in our group :stuck_out_tongue:

15

Haven’t decided yet what I think is/was the best decision. I do think we could have tried to make the development category very strict but having a ‘tech/dev’ only environment is also valuable and more easy to follow instead of having to search for tech topics.

We’ll see how it goes and we can always switch back to one forum of course, let’s give it a few months before concluding that it does or doesn’t work :slight_smile:

2 Likes
16

My opinion is it is far better for anybody to arrive here and see a buzz of topics a hotbed of activity so to speak, it is a more immersive experience. Now we have a watered down experience.

2 Likes
17

It’s definitely free of the junk. As a regular here I can easily filter just by looking at names and reading a few lines but a newcomer will have a much harder time. Even though I’m not a programmer I still like to read everything technical to try and really absorb and understand this project to grow my overall knowledge. Point is it’s frustrating to us because it’s already easy being a seasoned community member but this is to be easily accessible information for a growing community of newcomers. It’s like curated content, makes sense to me.

1 Like