I’m pegging my date on 2024 May to be precise 
Anyone coming here for the first time will see any positivity being pounced on with a dose of FUD time and time again.
We are all here because we believe in this project and the team behind it.
So if people are unhappy they should pack up and not let the door hit them on the way out.
I think FUD is different than concern. The fact some of the concerns seems tied to a demand of action is difficult to address as those concerns will not be addressed at this time (marketing, focus on awareness) until launch is much closer.
This doesn’t seem like FUD to me but it isn’t worth harping on either, so. One poll and a short conversation, fine but discussing it ad nauseam would end up being more destructive than informative so I would agree there.
Strength in numbers but let’s all be strong individually to make the collective strength that much stronger, eh folks?
That’s it from me here.
Really?
I’m no closer to the project than anyone who follows the updates. Everything I’ve written over the years has been based on public information, what I find in terms of consensus in the community and what MaidSafe tell us, filtered through my own experience. I gave up making predictions quite some time ago, but here you are making a poll when you already believe that folk here are delusional and predictions have always been wrong so far. 
I understand the strategy of starting a testnet and after 12 months of beta uptime stating, “hey folks, guess this is a safe network”. However, it would be a shame to not have a festive launch party and official countdown after all the years of hard work. Is a “post-launch” party just as exciting? I don’t know.
Thing is, there will not be any festive launch party unless you want EVERYONE at that party to be arrested and put in jail by the time it’s launched in 2023.
So either launch it and have a discreet decentralized post-launch party, or wait till 2023 have a launch party crashed by swat team to arrest all of you and have no launch at all.
Obviously it seems like you prefer the latter. Launch party or no launch! Because why? Parties are essential!
@warz , Thanks. Your explanation shows the facts and is very reasonable to me. When we are convinced of something, it is hard to look away from it and see ourselves. Your writing makes me think calmly about the realization of SN.
There are many people in this community who have a good purpose but are enthusiastic about SN’s goals. At times, some of the members seem too enthusiastic about SN. So I see that they unconsciously hate pessimistic writing about SN. Of course, this great belief belongs to them. I can’t say anything to him about this. However, I want the community to be more open about expressing different opinions. Of course, it’s basic to talk based on facts like @warz .
Most cryptocurrency projects use Ledger technology, such as Bitcoin, in which nodes in the network manage a single replicated ledger. This is a proven technology. Therefore, in this case, adding new features may not be a big problem.
However, unlike other projects, SN aims at anonymous web + cryptocurrency withs DBCs at the same time. SN wants to develop both at the same time. This is entirely up to the SN team to decide. But I think it’s easier for SN to launch cryptocurrency first and then add anonymous web functions later.
In addition, unlike other projects, SN team proceeds with development based on goals (20 fundamental principles https://primer.safenetwork.org/). Other projects certainly seem to be focused on faster development and making money than these principles.
Just as humans have to make a choice every moment, the SN team made the choice. However, SN’s choice is also different from what I think. In other words, I think now is an ‘era of privacy,’ not an ‘era of anonymity’. Despite these differences, SN’s sincerity toward their goals is too good for me. Also, SN looks like trying to implement something more fundamental.
In particular, I was fascinated by DBCs and Spentbook. In other words, I’m very excited about SN’s DBCs and huge fan of DBCs. It also seems so beautiful to me that clients handle almost everything by using AT2 concepts. So, I think SN’s the big direction is set very well now, thus I guess the development will proceed well. Thanks @warz
Going with late 2023 now. I hope they stop scope creep and make something basic where the fundamental ideas are implemented first. I fear with all the UI mockups its already much deeper than a MVP kinda launch though. Been away and will come back to crypto and maybe this project more once the bull run has finished its cycle and I can pickup coins 70% off from these levels.
I have heard this plenty of times and here is a way to think about it.
Which part of the core network would you do without or replace with any existing tech?
Your fear is correct, however, those are client-side work. The core network and testnets can launch with a simple CLI and as we progress then these features can be implemented by anyone. We will impl them in client-side but only after we have a working network. So you don’t need to worry there.
The reason to do this parallel task is to keep focused on onboarding non-tech savvy people and also people that don’t know or don’t want to know, what crypto is. It’s significantly more important than we think, otherwise we are building a cruise ship in the desert.
Hope that helps.
Hello all, Captain delusional here, I voted for 2022 … I know I’ve been way off in the past … so what. Only the lucky accurately predict the future - and that’s a fact.
My predictions have, prior to the last two years, been ‘it’s two years away’ … every year prior to 2019, that’s what I felt. But in 2019, I thought it was a eighteen months away and in 2020, I thought it was a year away (i.e. the end of this year); Now I think it’s six to nine months away.
Am I being unrealistic? Maybe - I don’t know what I don’t know right? That’s the problem with predictions - the universe don’t care.
What I can see in my predictions is there is a reduction happening in them … maybe that means something, but probably not.
So what’s left to get the core done and to launch – as David says, the GUI isn’t needed for launch, so we can ignore that …
After that, we are at full Fleming right? Am I forgetting something?
Then we just need upgradability for Maxwell … I don’t know how others feel, but that doesn’t seem like it needs to take more than 3 months or so to my mind.
Then launch.
So I don’t get where these 2024 and beyond guesses are coming from - but I don’t think they are coming from a reasoned view of the technicals, probably just from people’s frustrations.
So yea, I think 2022 is the year. Am I delusional? Maybe.
Nope, that’s it.
I hope so, it’s not simple, but then until we find the key it will always feel hard. I personally think it will include decentralised upgrades from any source, but check for no break of the fundamentals.
This is reasonable looking only at the technical to-do’s that we outside MaidSafe are aware of.
But the point isn’t the technicals. It’s the history, and that’s what those predicting a much longer timeframe are basing their estimates on. Their unstated assumption is that the technical to-do’s remaining that they’ve been told isn’t the full story and that something will happen to delay release further as has always happened in the past no matter how reasonable that something is.
And that’s indeed true if you look at the history of the project. Such a pattern is there (as understandable as the causes are). It doesn’t mean that anybody is to blame. But it’s important to recognize that pattern and do everything to break it by remaining especially vigilant against any factor that might be lurking that would once again break the hopes of the community.
It’s also important to be patient with those who express their frustration with that history and address their unstated assumption that something is yet again going to happen. It’s not fair, and it’s hard, and inside one might also be reeling from those potentially unpredictable factors, but it’s the right thing to do and it helps keep focus to minimize/mitigate such unforeseens as much as possible.
You should check out tezos on-chain upgrade mechanism: Tezos Agora. Seems they’ve solved the problem, and it could be readily adapted for Safe.
Edit to add:
Potaeto potato … Frustrations from ? … the history of the project of course. We are saying the same thing. Or at least I was attempting to express the same thing.
IMO, looking at the history of an R&D project without looking at the technicals remaining get’s you nowhere - as there is no means to predict any deadline … e.g. one could also look at the history and simply say it’s never going to get done.
The full story is simply keeping to the promises made at the ICO … which they are doing. Aside from what I’ve listed, there is nothing else that needs to be added. So if they wanted to add anything else people would have a valid complaint.
My view is that the ‘extras’ that some people think have been tacked on, are really just detours around intractable problems.
I suppose if DBC’s turn out to have an intractable problem, then sure there could be another detour … but you can’t make predictions on what-ifs. You have to go with what you know. Otherwise you can come up with any number of what-if scenarios, there is literally no end to that.
And will do so until it doesn’t. Same is true for any novel technology project. An R&D project is not a new toaster factory where 99% of the costs can be factored in as everything is known tech.
No, it’s not – because it is a novel tech project that requires a huge amount of R&D, breakthroughs could happen tomorrow, or never. Looking at an R&D project like it’s just another toaster factory is unrealistic and is only going to cause more frustration as these things are radically different animals.
It would have to be network-wide and I suspect with a version-1 compatibility baked in to avoid sync issues. So to do a breaking change it will need 2 upgrades. In such a system I think we would need a sync mechanism and that’s where Anti Entropy creeps in and works well.
i.e. Where currently we have
It would change to
That’s the 10,000-foot view, it’s more complex, but not too much. A big issue will be getting humans involved there to let the Elders get permission to upgrade, but that is the area I am keen to “solve” where humans are not needed.
It would already be a tremendous win to at least get started with a version where the humans behind the elders are needed and then use an upgrade in the future to add the version where the humans behind the elders aren’t needed.
The only thing this poll tells me is that building the impossible network isn’t something done overnight. And no one knows when it will be done, because its never been done before. The other thing this poll shows me is that there are people on the forum who will always believe in the superhuman hard work of an honest team and company, who will never give up. Personally I feel the network will take to flight indeed. Thanks for the poll.
I never thought of this, since to me the coin has always just been something that makes the network run, like oil for an engine, and nothing really important by itself. But now, with DBC and spentbook, this is quite different, and could be of real value by itself, and not just to speculators.
All this with the assumption (reasonable I’d say) that keeping ‘just’ a spentbook in sync is easier than keeping a whole network, with simultaneous data writes, versioning, different data storage systems, etc…
They sure did and it should. 
I don’t know the process 100% but the gist is anyone with a “roll” (10,000 tezzies) can vote. People who do not have a whole role can delegate to a baker and that baker can accumulate voting power. As long as a super majority of bakers vote in favor of an injected proposal it will take effect.
Also as you say, we don’t have bakers or delegates rather we have elders and sections.
The most important part really I think is the ability for an update to be injected and adopted with no forking, and they seem to run some kind of parallel nodes to test the upgrades, plus a ton of thought goes into an upgrade and there is a ton of active participation amongst bakers and developers, which makes me curious with a decentralized and anonymous web how we can address that openness and remain resilient.
@dirvine has mentioned in the past that there could be sacrificial nodes with the updated version that run alongside others to check for expected behavior and perhaps the Elders within a section vote for this to happen. In Tezos, the bakers want to keep their delegates because they take a cut of the baking rewards and as a baker if you don’t vote on a popular proposal then those delegates will not be happy and move to another baker. We may need some similar form of incentive to keep Elders accountable to important upgrades, perhaps punishment?
If I understand correctly we have an important component of upgrades being built right now, yes? Idempotent sections using Anti-Entropy, like CRDT for sections. So that way sections have a way of propagating the update and all come to an agreement in a lazy way.
It’s the injection, vote or adapt upgrade, and Elder accountability to section participants parts that will probably be the trickiest bits I’m guessing.
On the topic of launch, I think the tweaking of token economics is being ignored a bit in this discussion and will take some time to tweak to get right. The fact that the new member is FinTech and will help focus on tokenomics means Maidsafe is gearing up and should be ready for it 
We aren’t yet sure how much SN Token might be valued at, how we will try to increase demand for SN Token, how much app developers will earn from PtD (I’d love to know! lol) also how PtD will be enforced or if any published item like a blog could be applicable, which I advocate for.
I would like for users within an app to not only control their own data but also curate public data and be rewarded for its popular consumption, by self publishing that curated list of others (already published and earning PtD) content. PtD could do this just as well as PtP, in my opinion. Having to add an app specific token for this or fulfilling several different roles gets overly complicated and muddy.
This last bit about PtD reward amounts and accessibility is something that should take some deep consideration and I haven’t seen it get discussed so I imagine that will add to the timescale a bit but would love to start discussions about that now if anyone else is interested.
PtP, PtD, etc. could be added through an upgrade. So it shouldn’t delay launch.
True. I’m not sure if there is a point in having both PtP and PtD, I started a topic and I’d like to hear your opinion on it. I personally would like a ROI on app development on launch and think the incentive should be there but if not I would still make the effort to launch ASAP.