Any time frame for the release of Dev Bundle #1?
In a few weeks D
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.
So the next sprint will contain yet another partial rewrite!? This looks very concerning, is it going to ever work?
so things should start heating up in a couple months, exciting
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.
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.
From Update 8th June
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 https://github.com/maidsafe/rfcs/issues/6 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.
Thanks. That thread gives a bit more . . . uh, clarity?
Shakes my understanding of safecoin based upon previous model, of course. but it also seems to open a lot of cool doors.
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,.
Yes, the plan is very much same :-). This is very important for us and it helps a lot in sharing knowledge with community members at design/code level. Also do keep watching https://github.com/maidsafe/rfcs for design discussions.
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.
Excellent - looking forward to getting tore in here.
This thread provides more clarity so far. It’s a little crazy for some of us who have a looser grip than devs on understanding the low level operations on the network but we’ll catch up with a bit of reading. I see an opportunity for someone with a platform to clear this up later
Glad to be working with such a great team. I did some code refactor, solved a fake bug (fails to compile on newer Rust), solved a real bug and now I’m already working on a real feature. I should be even make suggestions not far from now.