MaidSafe Dev Update :safe: 12th January 2016

As promised, we are back into the normal Dev Update cycle and continuing on from the Update a few days ago. By popular demand we shall continue on with the same format of assigning team member names against the peer programmed tasks that we are currently focusing and working on.

##Crust - uTP / API : Vinicius / Peter / Andrew / Spandan / David

@ustulation , @canndrew , @Peter_Jankuliak and @dirvine are continuing peer programming the mini refactor in Crust; the objectives are to get a better understanding of current Crust functionality, clean up the code and tests along the way, but mainly to get on the same page in designing the new API. The current API, while feature complete, requires too much decision making to be done in the upper layers (read Routing) and it has been decided that Routing has its own set of responsibilities it has to deal with and that Crust should shoulder as much of the burden as possible from any user of the library. @vinipsmaker reckons uTP looks very solid and he is in the midst of testing and verifying this, so we are looking in good shape here now as well.

##Routing - Vault Integration : Andreas / Brian / David

The Routing documentation is currently being expanded to make it easier to understand and use, with enhanced explanations of the bootstrapping process, churn and handling the different data types; work continues in this area.

##Vaults : Adam / Fraser / Qi / David

Vaults were further pruned down and refactored to match the updates to Routing’s new API. There is still more to be done, but with @qi_ma back on board this isn’t anticipated to take too long.

As advised in the last update, Routing now has an example which closely matches the anticipated behaviour of Vaults. While this is useful on its own as an example (and test) of Routing usage, it’s also highly useful in implementing Vaults. If Vaults follow the paradigms set out in this example, it stands to reason that if this example works, Vaults should work. If Vaults stop working and we’re suspicious that Routing is to blame, we can examine the differences between Vaults’ use of Routing and this example to try and see if or why that hypothesis is correct.

With @Viv off for the next month, @dirvine and @anon86652309 have correspondingly increased workloads, but despite that, we’re hopeful that much of the work required in Vaults can be picked off by @qi_ma and @adam . This should let us have a testnet of Vaults up and running in the not too distant future.

##Client - Launcher : Krishna / Spandan / Shankar

A POC for the new launcher approach was demo’d last week. The approach has been detailed in this RFC.
We are expecting that this approach will make the lives of the end users and the developers much easier.

To make it simpler for app developers, the APIs are exposed through a local RESTFUl service instead of the IPC approach. The RFC also details the advantages of using a local HTTP proxy component along with the local server. Browsers will be able to serve requests, which end with the .safenet TLD through the proxy.

This week the two RFCs (Old vs New approaches) are to be discussed. Once one of the RFCs is accepted, implementation tasks will be planned and added to JIRA.

##Development roadmap : Scott

The initial design for the roadmap is now complete. Last week saw the design of the mobile interface mocked up and the UI will be slightly different to desktop. A menu on top and a descriptive view to drill down into. There is no graph style interface and in its place is the description of the feature and which tasks / features are dependencies and which ones are dependents. The graph was removed on mobile because of the obvious lack of space and the impact this would have on the user experience. The finished design for mobile is attached below and implementation is planned to begin at the end of this week.

So steady headway is being made on the tasks we outlined in the last Dev Update, the team’s heads are down and spirits up - a very good start to the year.

Link to the transcript


you’re great at this, Mr. @Ross !


Thanks so much for the update. Keep up the good work.


Fantastic routing documentation and WIP - Launcher Documentation! Kudos!


I really like the direction of building out documentation in a very clean interface. Having all of the hyperlinks to keywords and especially to sources seems like a no brainer, but many fail to do it. Having all the connected documentation will keep me connected with SAFE:)

I also love the mention of individuals. I want to have each one of team memorized by the time SAFE blasts onto the world. When flood gates open, I want to already know who made the effort when it really mattered. I want to know who to who to give thanks to for the rest of my days.


Keep going! :smiley:

1 Like

Is this the current way that the chrome vs. firefox plugins are being addressed or am I just missing something and this is in reference to something else…?

The launcher will be exposing APIs through a local RESTful server instead of the old IPC. These APIs can be directly consumed by applications.

To facilitate serving contents for browser based applications (without any addons), the local http proxy is used to intercept the requests which end with the .safenet TLD and redirect it to the local RESTFul server for serving the data. The custom protocol scheme has to be compromised and instead the URLs on the browser would be something like, maidsafe.safenet, blog.maidsafe.safenet.

There are minimal standards defined in the RFC for web development, that will help us to serve the same code across platforms (mobile/desktop).


Will “safe:” still work in Firefox and the other ones besides chrome?

All this talk is just for finding a way to make it work inside chrome right?

probably not with the standard launcher/proxy setup. While this might seem like a limitation, its to allow and encourage people to structure the website code such that it can be supported in a wide range of browsers than have to cherry pick specific codesets based on browser type. Url protocol handling is not just for the top level url but also embedded links / essentially any content linked from a site. so it scales a bit.

More like “to let it work on browsers apart from Firefox too and not be coupled to a single browser”. This isn’t a limitation with just chrome.


I just opened a discussion on the “new” approach here.


dang man so no more “safe:” ever?

we aren’t building a true internet protocol anymore?

This is a discussion, so we don’t know, and you can go and make your points in the discussion.

Also, the “safe:” issue really is only a compatibility feature - compatibility with the old internet. If SAFEnetwork were to become a replacement, we could migrate users to SAFEbrowser where this would not be an issue at all.


Pardon my naivete or if it is discussed somewhere, but will the REST API handle streaming data well? After reading rfcs/ at ab085b8191221b67e0a4389be0db17a895c21e13 · hitman401/rfcs · GitHub it appears I can provide an offset. If I wanted to stream data, would using the offset in a paginated way be the preferred form? Would I then be expected to handle file modification midway through my paging requests (by looking at the mod time since there is no hash that I can see)? Or should I take it upon myself to add a hash in the metadata maybe since it is returned on request?

Also, what if I want to stream content before saving the entirety of the content? Would I be expected as an app dev to chunk that as separate files myself whilst constantly deleting previous ones? I would assume messaging (once implemented) wouldn’t have enough throughput or low-latency to stream lots of content like HD video, correct? Sorry for all of the questions…

1 Like

I think your approach would work. We don’t know the performance characteristics though so only teasing will identify the best methods for different cases. I agree messaging is probably not the way though! :slightly_smiling:

You don’t need to worry about chunking data for the network. You can treat it like a file system when you want to save data. Chunking is taken care of by the core.

1 Like

I am afraid I have to worry about chunking into files due to the fact that I want to stream and delete pieces right after instead of having them persist forever. Otherwise I can only treat things as an entire file which makes it impossible to have an infinite stream of data.

The streaming, like VOIP, are a feature to be implemented in the future. The actual SD o immutable data (chunks) are not optimized for this task.

Speak about it in post like that: