My name is Mahmoud Moadeli and I have been working at MaidSafe over 4 years.
Last week we were delighted to welcome Vinícius dos Santos Oliveira to the team. Vinicius’s skills and expertise will be invaluable to further improving Crust (MaidSafe communication library). It was also great to have Peter Jankuliak at office the last few days of the week and we look forward to seeing the fruits of his in depth routing discussions with Ben and David.
Our time last week was mainly spent on addressing the outstanding issues reported on GitHub and also the bugs/issues discovered by QA in order to deliver an operational routing network. One such issue was the bootstrap updates which helped in starting seed nodes on droplets using the preferred port option in the bootstrap file. These seed node contacts can then be added to the hardcoded contact section of the bootstrap file and can then be provided with installers so that they can be used as fallback endpoints in case a node is unable to connect using bootstrap cache and other default methods. By addressing this, and a few other issues, the end of the week saw a network of 18 vaults running on droplets. This is a significant achievement and one that shows the routing network, with address relocation in place, is operational. Of course, scaling up the network is of prime importance and will be one of the objectives of the coming sprints.
Those who follow the weekly updates should be aware that each library has primary and secondary maintainers. To help everyone (MaidSafe and community developers) become familiar with all libraries, the start of this week has been set aside to enable the primary library maintainer to present their libraries. Each presentation is followed by a Q & A session, which the secondary maintainer of the library will be responsible for. We will be posting these presentations shortly. Please note that there will be a slight delay in sharing the Types and Self Encryption libraries, these will be posted in the coming weeks.
Sprint RUST-3 is the next sprint and is due to start on the 6th of July. This will be an interesting one! The following are potential objectives of sprint RUST-3:
1- Implementation of safecoin
2- Implementing messaging infrastructure
3- Removal of Transaction Managers
4- Implementing app launcher infrastructure
Please be aware that the realisation of the sprint objectives depends on the volume of work and available resources to deliver and we have just started the planning phase, so these objectives may alter during the course of the next 10 days. Clearly, realising the objectives of the sprint involves significant work at each library. To ensure a seamless integration the planning phase will involve extensive collaboration between cross library maintainers.
Hi @Konstantin_Lomashuk, I am documenting and exploring the many ways in which MaidSafe will sustain itself as the network launches. Monetisation is about how we as a company will generate income/turnover from the SAFE Network, such as core development, apps and other external sources. Funding is more about locating money on the promise of things to come, such as EU funding, VC, crowd funding…etc… we’re exploring all these things so that we don’t have all our eggs in one basket. I hope this makes sense.
As JRN mentioned, it was supposed to be released last week. However, due to an issue with unauthorised put, development of installer for a short time is delayed. The main reason for not proceeding with implementation of unauthorised put, was the fact that there might be no need for it by introduction of “Removal of Transaction Managers”.
So Dev Bundel #1 should be available by the end of sprint RUST-3.
Every time we touch the code it’s a partial rewrite (which is fine as long as wire protocols and serialisation + API does not change), I would not worry it is working (it is working) but if anyone ever writes code and everything is perfect first time then we would hire them (especially at this pace). Concerning for me would not be improving as we release and beyond. This whole network was just written in 5 weeks of code with a few weeks planning, surely we expect to polish it up?
Think like building a house, rough work first, get it erected, then finishing work before you move in (next sprint). It’s pretty straightforward, download the code and run it now, we have nodes running but are not yet happy it’s refined enough so we are making some adjustments. You see in the way we built routing we have oversubscribed the number of messages per action considerably high, so this is the kind of thing we now need to adjust as we can now measure efficiency.
We really are going at a very fast pace, surely it must be fast enough? I cannot think you will see a team working as hard and quickly as this one considering the rewrite we are just doing at this stage, no small feat at all. Importantly results are there for folk to play with different parts as we progress, so I think this is pretty good and a great way to honestly let folks see where we are.
I read the removal of transaction managers and it makes sense. I suggest everyone else read it as well. These fundamental changes are easier to implement before launch I presume and only reduces code base for increased security and likely less bugs. Hassling the devs doesn’t clear their minds to code faster, most likely just stresses them out. Be patient Imit will be worth it
In terms of implemented features there is hardly a delay, it just so happens that installers are delayed, which happens to be something many people look forward to. I guess the decision won’t delay release by more than maybe a few weeks, maybe even less?
Edit: With “release” I mean the moment we get real SafeCoin implementation and farming.
I have read it. Several times. Some of it makes sense to me. I can see that it is a simplification. What I don’t understand is that I thought Transaction Managers are a key part of safecoin, but we’re talking taking them out and also implementing safecoin.
Like I say, sounds good . . . except that I really don’t have the foggiest.
I’ll wager I’m not alone. Maybe @BenMS or @dirvine could give a catchup in simple terms for the rest of us, now that the cat is out of the bag and running around the yard.
Here’s a quote I pulled from Ethereum’s last development update,
“We continue our preparations for the Frontier release. While we’re still uncertain of the precise release date, we are becoming increasingly happy at the resilience of the Olympic testnet. As the Olympic testnet’s failure was ongoing, the adversity caused some reflection over how we might mitigate such problems in the future. The depth and duration of the consensus failure can, roughly speaking, be put down to two problems: firstly that there was a bug in the Go codebase causing it to accept invalid blocks (in this case, blocks with an invalid proof-of-work nonce); secondly that there was a huge problem with upgrading the network since miners continued to mine on the ‘bad’ chain and were slow to upgrade their nodes so that they mined on the correct chain. Essentially, the first was a forensic problem and the second an problem of organisation.”
That said, I have complete faith in David and his team and the success of the SafeNetwork.
Are this plans still on to involve the dev community in the sprint that starts 6th July. It will be nice to see the implementation and the help to drive the project forward
It is foggy to me as well. But there is a a discussion here RFC 0000 discussion · Issue #6 · maidsafe/rfcs · GitHub that @chrisfostertv had posted in another thread about the removal of transaction managers. In te discussion there is talk of safecoin being a series of structured data types chained together (this is only being considered as far as I can tell) The only thing I am unclear of is what you’re saying basically, if safecoin is not recoded then how will it be verified/signed/etc without the transaction managers? But it seems quite a wide range of possibilities opens up with these changes which are described a bit in that rfc discussion. I think I have a general understanding of this but Ill be rereading a few times.
It sounds related to David’s breakthrough a few months back.
Allowing globally unique structured data types paves the way for much more than safecoin, by the sounds of it. Instead of having a specialist application layer for handling Safecoin, it looks to be possible to implement it at a higher, common, level.
This means that any application can easily take advantage of the technology. It could allow alt coins, massively distributed computing, etc.
It sounds like a mechanism to securely store data in a specific format, which can then be accessed by the chosen recipient (then, potentially processed and sent back, etc).
Lots of reading between lines by me here, but it sounds like a big step towards providing an open standard, from day one, for complex and distributed applications.
Bang on This is now about getting more involved in client side logic and associated types (network side is sorted in terms of methods and algorithms, just some tidy up and reduction of messages required, so not difficult at all). At the same time looking at using the network for compute/dns types/search index’s and so on and this rfc opens all that up and at the same time reduces code significantly. I am about to publish a slightly updated one that allows transferable types that just gives us almost complete flexibility.
I feel with this we can show some apps, not only to reflect the current apps people know, but we could create apps that just do not exist today. This is my goal here and I feel this is a vital first step. Also when it makes things simpler, more efficient and more secure by reducing code, I tend towards feeling more comfortable as well. It means we are re-factoring effectively. I mean re-factoring here as it should be, making the algorithm more concrete, so not re-writing but factoring just like secondary school algebra. I also feel it means faster more efficient launch,.
As we progress with our planning, we will share more details on work planned. We will initially have tasks from one library open for community members as a test for the new process.
D
