^December 25th launch date confirmed 
Just kidding, thank you for your patience with us. At least you know thereās an avid community, just chomping at the bit to get involved, start nodes, and spread the word of freedom to the world once itās available 
Totally understand and to be honest weāre exactly the same, the thought of being able to start to use something we have been working on for close to 10 years is very exciting. Weāll also enjoy spreading the word with you.
If SAFE takes off, then it might start making sense to register the TLD. For now .safenet is less likely, but itās thereās little incentive for anyone to apply for such a long TLD. But that can change.
My thoughts as well. It somehow feels wrong to change a technically correct and sensible format because some browsers are very restrictive in their plugin capabilities. Maybe itās my perfectionist attitude compromising pragmatic judgement, but Iām inclined to say, let them adjust to us instead. Weāll use Firefox in the mean time.
Besides, itās probably wise to use a separate browser installation for SAFE surfing anyway, if you care about privacy.
I think ease of adoption is a higher priority.
We simply must attract and retain as many users as possible because the success of the network depends on it. Then, if we succeed, we get the chance to write new standards, which I think will be more radical: our own secure SAFE OS with the SAFE Browser, that you can tell to include the old net if you really really must! 
The ease and simplicity of the safe networks under the hood security is also a very high priority and what will help generic web surfers adopt it. If they can be easily tricked itās not serving that purpose. I think some browsers like chrome are inherently restrictive, could change at their own whim and itās their loss. Itās like the team would be doing them a favor, yet you have the opportunity to capture a fraction of chrome users. Pay out doesnāt way out to me personally.
āIf you build it, they will comeā.
Should we be focusing on servo, the next generation browser?
The developers who are close to the code have a viewpoint unavailable to the all but the most intelligent and enthusiastic few. An insight, even if somewhat vague, might prove useful to those who are invested in the outcome of the project and need to make real world decisions.
I think guesstimations by those at the coalface would have real world value. Far better than a blanket ban on this sort of guess work. This information, even if it proves ultimately inaccurate, is not of zero value.
150% agree and applaud your delivery of this very delicate subject. People are hanging off this on a daily basis and that is pressure for the all devs. IMO the team needs to put realistic delivery window of 6-12 months. Hopefully that window can benefit you and make it easy to make your āreal world decisionsā. After a decade & millions $$ this team has no choice but to get it right ā¦ āYou never get a second chance to make a first impressionā ā¦ pressure? Yep.
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.
