MaidSafe Dev Update :safe: 19th January 2016

Development Updates
1

We have continued to make steady progress on the plans we outlined a couple of weeks ago; we are very much on course to deliver the RUST-5 objectives and for community testing to begin. Thanks as always to all the Dev team members for taking the time to share their progress with the whole SAFE community.

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

The team has been working on refactoring Crust and cleaning up code a lot. Every evening we have aimed, and largely succeeded, in ensuring all tests pass (@vinipsmaker is finalising a Windows bug in the bootstrap method). When this is completed we will be able to focus our efforts on ensuring Crust is as reliable as it possibly can be; a solid foundation of connectivity among peers. We’ve also been working on simplifying Crust’s API to make it more user-friendly and ease integration with Routing.

As of this morning the tests are passing again with the new API in place. Some further work will be required this week to finalise this library in a state we are happy with for launch.

Like Routing, we anticipate this will consist of a solid repeatable set of tests that show at last a multiprotocol router (NAT) traversing networking library for all peer-to-peer projects. Initially Tcp direct connections, udp hole punching and uTP transport are included. This will allow Tcp hole punching to follow as well as encrypted Crust layer communications from the first message (bootstrap). An important step!

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

We finished the documentation overhaul, so that Routing is now much easier to understand - without having to read the code.

A few minor changes have been implemented to make the network more stable on startup:

  • The number of simultaneously joining nodes is now limited
  • New nodes that failed to connect will retry after a short delay

Next we plan to address a few issues that turned up during small test networks, which prevent a node’s routing table from being optimally filled and the group authorities from having the desired size. @AndreasF has hit the ground running here and is already immersed in XOR routing table implementations and tests. Great to build the team strength, especially in this library.

##Vaults : Adam / Fraser / Qi

The Vault refactor is progressing slowly but surely. With @Viv off, @anon86652309’s time has been largely taken up filling that gap. However, we’ve still managed to progress Vaults somewhat with the bulk of the cleanup work having been completed and focus moving on to implementing the various message flows.

The flow for Putting data is complete (bar testing) and work has started on the Get flow. After that, Post and Delete remain. However, these should be simpler than either of the other two previous flows and should take significantly less time.

Once these are complete, we’ll move to reinstating unit tests for the much-reduced codebase and will be in a position to start running vault testnets again.

##Client - Launcher : Krishna / Spandan / Shankar

The RFC detailing the new approach for the launcher was discussed. Implementation is expected to start from the middle of this week. The community involvement was excellent; many thanks for all the suggestions and discussions.

The proxy server will be bundled along with the Launcher server. The idea is to provide the basic set of utilities bundled together in a single application. Most of the inputs received were in favour of bundling a proxy along with the Launcher and to provide an option for starting and stopping the proxy at the will of the user, thus we are opting to go with the most popular approach for now.

The existing NFS, DNS IPC APIs are to be ported to RESTFul APIs in the first version.
This will allow us to quickly develop a Drive application which shall interface with Launcher; this will initially be instead of a mounted drive. Going with a standalone application for now will allow us to quickly develop and use the Drive application to test the network with some real data. Below is a mockup for the Drive application that @Scott has been working on.

1073Ă—653 84 KB

We are aware that the APIs are a little limited for now. While the network is being tested the APIs will be added to and improved in parallel to this testing.

##Development roadmap : Shankar

Work on implementing a proof of concept for the new roadmap mockup is currently ongoing. A configurable module that will be able to render the designed user interface on desktops is currently being developed. This work is expected to be complete in the next couple of days, after which @Shankar will be working on the Launcher and Drive application implementation.

##UI Design : Scott

In addition to the Drive application mocks, @Scott has also continued to work on:

  • A new design for the revised Launcher
  • A new design for a simplified implementation of messaging
  • Various mockups of example applications

To prove that @Scott has in fact been very busy we thought you would also like to see another mockup, this time of the new Launcher applet:

1073Ă—653 105 KB

So a really good start to the New Year and exciting to see progress on all fronts. During the course of this week we anticipate starting to bring the individual libraries together and starting to run Routing against the new Crust API, while also integrating the changes made to Vaults, and of course getting the network back up and running on droplets. We will then turn our attention to the integration of Rust uTP.

Thanks again for the ongoing support, here is a link to the transcript.

52 Likes
2

So if I were to build an application that is stand alone, how would it be attached to the safe launcher and its application list?

4 Likes
3

Getting place to read!

4

The quality of these reports could be connected to the increase in the Safecoin price. Seeing the team execute great SW dev technique would give those with the most ability to differentiate between “BS” and “hey-- they’re solving real problems and planning for reusability and integration into other products!” Sweet! the context they need to make that judgement. For whatever reason-- for me-- this one especially.

6 Likes
5

@Krishna_Kumar is the best person to field this question, his timezone is (GMT+5:30) so hopefully is catching up with sleep :sleeping: and will pick this up in his tomorrow. Have you read through the RFC’s (and proposed RFC’s)? For instance > rfcs/0018-launcher-as-local-rest-server.md at launcher_as_server · hitman401/rfcs · GitHub
More here > GitHub - maidsafe/rfcs: Request for Comment (RFC) papers and discussions on Project SAFE core libraries and APIs

4 Likes
6

Sexy exciting stuff this week dev team! The pieces are falling together quickly for 2016!!!

1 Like
7

Again and as always, Thankyou for the update. Sounds like things are progressing nicely.

I do have one question though

Delete? Is that for messaging? Or was it referring back to vaults and deleting chunks from the network?

8

I know it’s not XXX, but those images make me drool
:stuck_out_tongue:

Thanks for adding images to this suspenseful sci-fi novel,so exiting times.

Thanks for all your hard work and dedication

3 Likes
9

Yes it is for all data that is not immutable data. So mainly structured Data types. These are signed by an owner(s) and can be deleted as long as there are enough signatures.

9 Likes
10

So you are working on implementing a proof of concept for a mockup of a plan… what about creating a plan for a committe to decide on a proof of concept implementation for the mockup of the plan? I feel like this statement doesnt have enough forward thinking synergy to effectively paradigm shift.

5 Likes
11

This is only to help with chrome right? Because they’re the only one that might not support “safe://etc.” but we’re still building the “safe://” internet protocol right? Please don’t say we’re giving up on that for some reason

12

Your mocking tone may be attempted humor, though it sounds like derision. I think if you tried to understand first or asked for clarification, you’d be less likely to be taken as a cynic or a troll. If it is an attempt at humor, it’s not very funny.

I don’t have the inside data, but it’s pretty obvious from just reading it with an eye to understanding that Shankar is working on a new form (mockup) of presentation for the roadmap so that it’s clear and useful to a lot of people, and then they’ll see how that form serves.

2 Likes
13

Omg omg omg it’s happening! We’re actually getting a functioning safenet with apps that can connect and transfer data and work omg omg omg! forcibly shoves hyperactive fanboy uber excited kid self back into the back room where you hear screams of glee, furniture being jumped on and the occasional piece of breaking glass

Ahem okay so to put this in perspective:

  • Will this network be using safecoin yet?

  • How much data can we upload and if so is it permanant? Are we looking at a network reboot wipe at some point?

  • Are there any other apps available than the ones depicted above? If so how does one access and install them?

  • How does one install the SAFE network as it is now?

  • On what OSes does it function? If it’s not yet available for mobile and some variations of Linux how long until it can be ported?

  • How are updates distributed? Will I have to go to github or something and redownload and reinstall everything at some point? Will I have to recreate my account if the network gets wiped?

4 Likes
14

Don’t have a cow man…it actually was pretty funny given @Ross’ wording of the process.

When (not if, when) other “basic utilities” are identified, will they be included into Launcher so as to make it one big monolithic piece of software? Hmm…it’s like a gateway, but more than that. Because…not less, but more is more, right…right?

Also, do I have the freedom to refuse to accept this code into my own Launcher? Will I be able to even compile the Launcher code from source without including the proxy?

Is there going to be a CLI front end as well, or will Maidsafe only be releasing GUIs for this entire project? (Think systemctl - it seems to work with monolithic pieces of software too)

Props on the documentation. Truly excellent.

1 Like
15

I think @feelz might have been referring to showing an example of how network dev and updates are managed by the community via road-map? How to best manage core updates to the network seems to be a popular topic and one I have not heard or seen a great POC on.

16

I’d been thinking about this recently and have had to draw some comparisons to Bitcoin.

Bitcoin uses the miners’ hashing power as votes - based on what they choose to run. As we’ve recently seen with the mass exodus of Core in favor of Classic, this is certainly a way to run.

However, the federated nature of mining is very scary when you realize that there may end up being maybe only three or four major mining pools who dictate which software to run.

Luckily, vaults have no such problems, as they are able to have a voice even if they utilized a decade or more old computer to store data. Also, the ranking system can give more established vaults a larger voice - useful if you consider that they are more invested into - and hopefully more knowledgeable about - the system than a newer vault would be.

However @feelz’ post was meant to be a jab. Read the corporate jargon BS that he humorously suggested:

C’mon, it’s the difference between having a thing, and having a thought. Right now there’s a thought. Cool. Good for them. Update us when it’s a thing.

17

Yes fair point, probably not the most assertive statement we have ever made. We are implementing a much more detailed roadmap and believe we have found a good way of displaying all this information at both a high level while also allowing the user to drill down into more detail. The intention is to implement a small section of the chart to make sure it works (POC) before implementing the rest. We’ll keep you updated with progress.

12 Likes
18

Can always wait every 2 weeks for an update if people are going to be jumpy about words on a monitor, shrug.

3 Likes
19

More explained here @whiteoutmashups :grinning:

20

Intention is certainly not that. We do understand the advantages of having a plugin based approach. Where the launcher would be the main application and the other bundles can be plugged in. This would make the updates lighter and you don`t have to update the entire application just for fixing a simple issue in a package. But at the same time, this level of flexibility can not be implemented in a very short cycle(2 weeks). It would be better to keep it simple for now and get the application out to help in testing the network. The quicker we start playing with the application we learn more about the practical problems (Hope things are smooth). Shorter cycles will be better to scale it up gradually.

We can split things as we progress.

This release will be a GUI based application.

16 Likes