While I wholeheartedly agree with you, this would seem to be necessary for critical mass of adoption.
Luckily, this won’t be baked into the core of the network, but rather the extension/addon for browsers. I forsee desktop applications (much like apps in regards to smartphones) becoming more popular than whatever can be displayed inside of a browser (which is limited).
BTW @Ross, those diagrams are excellent. Can we expect to see more in the future - in my case I am hoping to see one that addresses the fulfillment of a GET request.
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.
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.
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 
) 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.
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.
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.
I’m trying to write the second part of the Routing - Bootstrapping topic. Just a few little questions though.
Not poking any Devs here just some questions for random users who know the answers ;-).
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.
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! 
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.
Another road map? …
What’s wrong with the first 2?
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.
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?
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.
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.
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.
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.
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 
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
