MaidSafe Dev Update :safe: 8th December 2015

I would agree if the predictions we could provide were accurate, but I question that the value of providing well meant, but misleading information, particularly to people who are making real world decisions based on the information we provide. When you look at large and successful companies with some of the world’s leading talent, they very rarely provide new product timescale predictions. Quite often firms like Apple, for instance, announce a product literally as they launch it. This is also not about timescales applying more pressure, believe me when I say that no one could put more pressure on the team right now that we put on ourselves, it is simply about communicating accurate information. I hope this makes sense.

7 Likes

Comparing this to enterprises like Apple or Google is slightly misleading I think. Apple doesn´t host weekly updates on one of their products. Also the initial offering started with an estimation to have the product and to have that product at a certain point. Under this circumstances it is understandable that people keep asking no matter how good the argument is that stuff needed to be written entirely new after shifting to RUST. While the move may have been a good choice it spreaded insecurity, since it shows that long term plans cannot be trusted. Also, the move from giving estimations to not giving estimates at all will spread insecurity.

Is it really a big deal to say: “we give ourself 12 months to finish the core network”? As far as I see some people currently believe that we are only days from network launch - if that´s not true the record needs to be set straight. I think that giving a more realistic time frame (6-12 months) will rather lower the pressure on the dev team - and I think that´s needed to make sure you don´t burn out or make mistakes that will lead to major lashbacks in the future.

7 Likes

This gives the very binary view that we are keen to avoid. The core network is never ‘finished’ and what we do and will give a picture of is the planned and iterative roll out of the network. We have started work on a much more detailed and hopefully meaningful roadmap (don’t ask me when it will be released :smile:) that will indicate the order of the roll out, but will come without timescales initially. It may be possible to start providing estimates for new features once we have the Rust 5 deliverables in place, but as I’ve said until we have that any predictions are meaningless.

8 Likes

I don’t want anyone at Maidsafe to give any estimates unless and until they are comfortable. Just focus on getting a quality product out.

Also, the launch of the product is not an end. It is only a beginning. The real hard work will be starting after launch. If you start giving time estimates now, you will never be able to stop.

Also, be sure to take some time off for the holidays. A week is not too much. I think goofing off, sleeping, and daydreamimg are underrated activities.

4 Likes

And if you need a role model on how to daydream and goof off, as long as it doesn’t involve me working, I will glad to offer my mentorship.

3 Likes

I’m trying to write the second part of the Routing - Bootstrapping topic. Just a few little questions though.

  • Client (A) connects to Relaynode(B). They exchange their PKI’s.
  • The Relaynode also sents quorum_size. From which group is that? And why does A wants to know any quorum_size while it’s not even part of a group??
  • Node A does a GetNetworkName Address-request. It’s destination are the NAE Managers. It seems that this communication is encrypted using the public keys from the NAE Managers, because the relaynodes are certainly called relaynodes in the flow chart. But how did the Client(A) got these public keys from his NAE Managers? And how does the Relaynode knows who the NAE Managers of Client A are? It does route it’s messages back and forth. Are the managers just random nodes??

Not poking any Devs here just some questions for random users who know the answers ;-).

1 Like

Full Public, ID client messages are self validating (name == public key)

Clients will accumulate (this is the sentinel type check, where we ensure a real group sent at least QUORUM messages in agreement back to us) and security validate messages from network groups. On new network or full blown restart this allows the network to auto start form any location without people needing to start special nodes.

atm these are signed requests and can be validated at each hope. There are several messages from a->x to ask for network name. Then x->y to store PublicId (new name) and then for connect messages and each member of y will have exchanged keys and encrypt endpoints to each other. This disallows nodes in between finding IP addresses of network nodes.

The hash of the client name == NaeManagers of that client public name (this is a client trying to promote to node).

Steps of nodes are

Disconnected → Bootstrap (now a client) → GetAddress (try and make a node address) → Node (address accepted and now connected to at least 1 close group member (NodeManager))

Sorry for fast reply, we are all in Google Hangout (this last few weeks 5 of us from 06:30 in HO all day and then we get our 8-10 hours afterwards to gegt some more work done, so mad mad busy, but routing has transformed itself into what it should have been).

Should all be very clear secure and maintainable very soon. Very much a case of clearing up some complexity that should not have been there. Allows us to add and ensure appropriate security is in fact in place.

13 Likes

While I have sympathy for this position, I am not sure whether I would have invested in the crowd funding, had the predictions been so vague at the time.

I still believe that the network will be delivered as planned. However, as an investor, I would like to see incremental, concrete, deliveribles. Buggy test nets would give me much more to go on than promises of a bug free test net at an indeterminate point in the future.

Rather than promising the world and failing to deliver it, promising a small island and providing it , would be better. No promises or islands is not great though. Apologies for the tortured metaphor! :slight_smile:

6 Likes

That is very much what we are working toward. We are certainly not promising a bug free test network, however, what we are saying is that until we have said test network up and running with the Crust, Routing, Vaults and Clients integrated and users joining the network remotely it would be meaningless for us to make predictions about when specific features will become available. To this point we have attempted to make some predictions about when certain deliverables will be achieved and despite our best efforts not met these estimates. These provide disappointment to supporters and fuel for the non-believers and my argument is what purpose do these predictions serve?

I don’t believe that Rust 5 deliverables are too far away and what we’re working toward right now is a highly detailed roadmap that will give some insight to what is required to reach each new feature and a potential order for the feature roll out. As we work through this roadmap I expect it will become possible to derive a timescale range.

6 Likes

Another road map? …

What’s wrong with the first 2?

1 Like

The current roadmap lacks quite a lot of detail and the language used makes it difficult for many, who are not overly familiar with the project, to understand the deliverables and the order in which they will be received.

5 Likes

Why would you want to be dependent on the TLD / DNS system? It’s vulnerable at the moment. Maybe we could fix that too while we’re at it ;-). Someone could just “shut down” the TLD servers. Hmm, just read “the whitepaper”, Whitepapers/Project-Safe.md at master · maidsafe/Whitepapers · GitHub “The network is designed to be decentralised and has the ability to get rid of Domain Name System (DNS)”… Anybody working on that?

1 Like

It would be an “and” not “or” kind of thing, in all likelihood (although we don’t know how it would be implemented).
Like user-friendly names for bitcoin addresses.

2 Likes

Welcome to the forum. A lot of people here had the DNS already running. Locally, that is. If you search for DNS you’ll find more info. The idea is that when the network goes live the coming weeks you’re able to register your own name. Not using any DNS-servers. But all decentralized.

3 Likes

Fair point, but I was not talking about a "finished " version, but a usable one. You don’t need to do give an estimate, but given that there was an initial estimate that dated back to last year and given that the project is already developed for a decade I think it needs a rough and realistic estimate. From what you read, it sounds as if we are far far off from a usable network and rven more far away from a network with usable Safecoin. At the.same time some people believe it will come out in few weeks…

You said that anyone pressures more than the team itself - to me that doesn’t sound healthy. You shouldn’t stress out but take your time. To do that, a realistic timeframe will help the team AND the community.

To be more precise: I’m not really interested in a "time until finish " estimate. More a “don’t expect results until X” estimate.

9 Likes

Take your time, team! Whoever wants the project to move faster can join the work by checking the GitHub issues or the JIRA tickets. It’s easy to rant on the forums.

2 Likes

Nobody was asking the team to speed up and if I was told as an investor (as opposed to a dev/coder) I can help do the work myself by checking Github, then A) It is less than useless and B) This is very poor communication.

Again, who is ranting? Members of the community have expressed a reasonable desire to be given the dev’s “best guess” as to timescales. This lack has been explained as “not wanting to guess wrong”, because this would have a detrimental effect on morale/support/whatever. Unfortunately, not doing so has a similar effect. It is up to Maidsafe which is the least detrimental course to take for themselves until launch. We can express our views, but to what level communication is made to the Community is their decision really.
There does seem to be a lot of shooting the messenger going on here (by some of the community)) and over defensiveness in the face of any criticism. I think we should be careful not to “Deify” personalities here and end up in a sea of sycophancy…an ocean of obsequiousness…lol…a Religion!
As I thought this was all about being open and honest. My question to the team individually is "Do you have a “Best guess” in your heads - or no clue whatsoever? Once you’ve answered this, the second question is, "Would you like to share your best guess with the Community…as individuals, rather than as a team “official statement”?
I would suggest each dev gives us their best guess, no comebacks and the Community can then Crucify the Apostle, who is furthest from the actual day of Dirvine Creation…erm :smiley:

7 Likes

Yes the tone here has always been understanding and calm, but we have been receiving worrysome updates for some time now and I think we all just want to see something real. Rust-5 was ages ago and it’s deliverables have never been seen.

When I really think about what might be going on, I think perhaps there may be internal problems possibly? This is a huge undertaking and a very multifaceted, complex project, so it would be completely understandable if there is a substantial internal problem with development (beyond what has been said already in the updates, etc).

Just please tell us about it! We’re all in this together, and we all want to change the world for the benefit of everybody together

4 Likes

As a programer who has done multi year projects. This news is expected. At times it can seem like whack-a-mole. They are in multi-week bug fixing and one thing about bugs is that they like hiding each other. You fix one bug only to find there was another you could not see until the 1st one was fixed. And so on.

The problem we have as on-lookers is that the dev team had done an amazing job for Rust-1 through Rust-3 and we expected the same to continue for each sprint. But when Rust-4 was nearing completion the bugs that had been creeping in reared their ugly heads because when you bring the modules together they each shine the UV light on the other modules and those nasty bugs become obvious and wreak their filthy ways on the system.

TL;DR

To expect clear sailing through each RUST cycle is unreasonable and bugs have a way of taking an unknown time to be fixed, especially with modules that do things no one has done before. It is unpleasant for all but is expected and the updates are actually encouraging, because some programmers just fudge quick&nasty fixes so they can appear to be progressing fast. Those quick&nasty fixes often cause problems later on and actually take longer to fix in the end.

Without some other information the progress does not support nor deny that thought. But I would think without other evidence there is no reason to think this.

1 Like

Lets be real. Routing is one of THE most difficult aspects of SAFE and the teams’ inexperience with a very new programming language had then (during the time of fault) caused some critical oversights. Who could of guessed.:confused: It’s cool though cuz now every dev member has become more intimate with each module as a result. I’m glad sh!t happened the way it did (almost Dirvine in sequence):yum:. Now we have informational and experiential decentralization in regards to SAFE among the developers as well. I’m very excited!:grinning: Yes, things all around could have been better but keep in mind the imperfection of humans and the scope of the task. These are in many ways the results of the supermen of tomorrow (to the rest of society) attempting to juggle every day life and catalyze worldwide communicative liberation. Please, cut them some slack. The result I believe, will permeate all of society. If not, it will have laid the groundwork within a fairly short time-frame. Everything I said can be argued, but lets just chill and try our best to use the current available data to make our multifaceted estimates. Did I ever tell I you that I skydive with incontinent cow monkey mycelial hosts. It’s the most optimal land ammonia dispersal and land reconstitution method I was told. My rational left brain rejected it at first, but my right distorted mind held welcoming wispy arms and a veracious appetite.:grin: Ya know wut I mean son!:wink:

1 Like