Really great summary @oetyng
Does it mean, that there will be new milestone, project , epic or anything like this on GitHub ?
Btw. With CRDT it also means that to become Elder the resources requirements should be lower due less networking ? Are there already some expected optional requirements for potentials Elders (Like cheapest Raspberry Pi running 24/7 would still be OK) ?
I disagree with this. Fleming just needs to prove the concepts work. If it can do immutable storage quicker and better than the blockchain, itis already winning.
If people know there are lots of optimizations coming in the next versions, they will forgive performance for being slow. However, if there is nothing to capture new people, there may never be that all singing, all dancing, fast version - we will just run out of runway and fail to take off.
I would love to see a super fast, super reliable, world beating network in the long term. Right now, if happily settle for a slow, slightly buggy, but usable network with plans to improve in the future. This thing needs to be real and be launched, ASAP.
Could not agree more. You canât eat an elephant in one whole bite (apologies to any vegans in our midst). This is why projects must be broken down into iterative releases plotted along timescales that make sense. The rising tide that has historically raised all shipsâthe bitcoin halvingâis nearly upon us. We would be wise to ensure that the SAFENetwork does not miss this wave.
Once again @Traktion and @Sotros25 nail it.
You can eat neither an elephant nor a cauliflower in one bite.
Get it functional, get it out, make it better, get it out again. Rinse and repeat. Often.
For the things that are decided to be starting implementation, Projects are added in the respective GitHub repository (they should be linked in all dev updates mentioning the project as well).
For other things, the granularity of project management is lower than it used to be (is my impression). So I think a few more things happen without corresponding Gantt chart updates for example, since we became a smaller team. But the larger things, the important things, are kept fairly up to date I think.
If anything is clearly moving from an uncertain inclusion in Fleming, to being included, I think the overall roadmap would be updated to reflect it.
It could be, and logically it should result in this. If by that weâre actually seeing lower spec requirements is hard to say now. Maybe there will be need for other tasks that will require that additional spec instead. So, maybe instead the node will handle more tx/s. Just saying as a caveat, we canât be completely sure.
This is not something Iâm aware of.
I think this kind of optimisation is for later stages.
Thereâs of course always attention to resource usage (which is shown by the desire to use CRDTs for example). But that detail of knowledge is still to gather, what minimum specs will be required etc.
I am still uncertain if Fleming is intended to be permanent or if that is Maxwell? Maxwell is to introduce upgrades but could we easily transition to these big changes? Do we have to spend more resources on backwards compatibility for a perpetual network? Can we go from one type of Safecoin to another seemlessly enough? Once you get the proverbial ship to set sail, making changes to the hull canât be easy. Ethereum definitely benefited from being first to market but also has had delay after delay to get to a proof of stake model to keep up with the transactions. Ethereum is a big ship and they spend a lot of money to get these things done but again they were very early to market in this space when there werenât many options. Imagine SAFE having launched with all that C++ code back then and trying to get to where we are now. Different story today I know but interesting thought experiment.
Fleming! Fleming! Fleming! 
Iâd say unless the changes have the potential to cause data loss and post-Fleming data is supposed to be secure, then yes you have to be careful. If one or both of the aforementioned are untrue, then iterate, iterate, iterate.
Btw, Iâve not mentioned this before, but there can also be a fear of launching. The day when the work will be judged can be nerve wracking and delaying to to make everything more perfect can feel like a positive avoidance strategy. However, it is still an avoidance strategy.
FWIW, Iâm not saying that Maidsafe is suffering from this. I think they are genuinely just concerned with getting a quality product out, but I have worked in teams in the past where this has been an issue. I think the world will embrace SAFENetwork with open arms without it necessarily being perfect from day 1.
This could very well be the case.
But there is also another angle on this. We have been hearing a lot of âit is so close nowâ kind of talk, and how all the key issues are solved and now it is just about putting the pieces together. This recent enthusiasm about new ways of doing things really sounds like the goal posts have been shifted once again.
When you say:
⌠what does this âif time allowsâ actually mean? Time is the one thing that is never really talked about, otherwise than âcloseâ, âsoonâ, ânobody knowsâ etc. Ok, I think that it could mean that part of the team can work for these goals when they cannot be of help on more urgent ones, rather than be idle. But Iâm afraid that this leads to a situation, where you have different lines of developement âalmost readyâ all the time, and a desire to have all the lines ready, but actually perpetuating the whole process.
Not saying I agree or not but, once bitten twice shy.
After putting something out that was not complete, vultureâs swooped in pretty fast, even though it was juvenile.
The protocol should be launching almost complete state. Because it is not allowed to change fundamentals things of protocol after launching. The protocol is not like an application changing.
Why not have âproof of conceptâ protocol launched first, to show that Maidsafe can deliver, and then make new, better one?
The proof of concept protocol is already shown. And we wait full function network except upgrade.
And I think that if you are not an expert network engineer, you cant figure out the development process of SAFE. Then, next option is trusting Davidâs track record. He and his team has been developed this project over 14 years. They are the most well known people in the world. So, I want to advice you to respect teamâs decision.
P.S. Even only 1.5 years ago, the PARSEC is not complete and C-rust didnt replace quic-p2p. We are very closing to goal.
P.S. 2 If you want to price booom in a short term, contacting exchanges to list maidsafe. Because there is only a few exchange list maidsafe, it is really small money gateway.
This is why we are trying to discuss, define, and decide on what we feel is a Minimum Viable Product (MVP), and what is the Minimum Viable Experience (MVE), for a successful Network launch, and what can happily come after each of these.
Design and development wonât stop once weâve launched the network, but getting to a viable network, that will stand up and be resilient, as efficiently and effectively as we can is our aim.
Itâs not the MaidSafe teamâs decision alone what we consider MVP and MVEâand what we require before the big launch button is pushedâitâs a community effort, so please chip discuss it with us!
For example, the building blocks for the MVE are listed here.
You can see what we are working on, and what we anticipate being the minimum required for a successful product launch. But you can also see a bunch of desirable features that didnât quite make the cut for that, but that we can bounce right on and start designing and developing once the essentials are complete. We might be able to begin that even before Fleming is launched because not all team members are working on the same thing sequentially.
Itâs also worth noting that we often have to be thinking a few steps ahead, to the post-launch bigger picture, in order to make effective workable solutions for launch that donât paint us into a corner later on, when richer features are required.
So, if you feel like the goal-posts have been moved, please do chime in with your thoughts, and we can all plan the most effective route to launch together⌠thatâs what we all want after all!
Maybe Iâm just confused what these MVP and MVE refer to. I mean a year ago Fleming was only routing, nothing else - but in any case clearly an intermediary stop, proving something very prelimanary before launch. Then the goalposts were shifted (much to my pleasure) so that it became something closer to actual network. Now it seems to me that the difference between Fleming and launch is becoming lesser and lesser.
Thereâs a wee explainer at the top of that link, but iâll quote it here for ease:
What do we mean by Minimum Viable Experience (MVE)?
We often bandy about the term Minimum Viable Product (MVP) when trying to describe what we are working on, and what is left to be done before the inception of the living breathing autonomous network. But with many strands of work, different teams working on different layers of the Network, this term can be the source of diverging understanding, and confusion.
What we are talking about when we talk about an MVP are the features required for a functionally complete network that delivers full data retention and delivers on the security promises. This is the network infrastructure that underpins all other functionality. When we have an MVP, we can have a Network.
To the average user though, itâd likely be quite raw, need only a basic interface via the command line, and not necessarily even consider the basics of usability, such as human-readable URLs, as one example.
We need to go further than that if we want the Network to be buoyant enough for a successful launch. For that, we also need to build a Minimum Viable Experience (MVE).
The MVE is made up of features and applications that are necessary for our initial, early adopter user base to be able to practically use the network, taking into account their experience, needs and expectations. These are captured in the Proto Personas shown right.
The SAFE Network App is a conduit to this MVE. Itâs minimal, lightweight, and attainable, but it encompasses all we need to get the network to stand up, in the most efficient route, and then iterate from there, therefore most of the essential features of MVE will be built within or alongside the Safe Network App.
For me, this is a feature that if completed before Fleming critical things, will be included in that release. If not, itâll come later. This is non-blocking work, not directly related to solving the remaining, fleming-specific issues. (as @oetyng notes above, throwing more people at the problem doesnât necessarily make it go any faster⌠indeed, maybe slower).
Looking at tokens + labels. Non of that is needed for a fleming release. Iâm working on this in parallel to anything that may be required for fleming release (updates to browser / snapp).
Basically, just because weâre talking about new features, doesnât mean weâre blocking or delaying Fleming work. Fleming is still priority one, just⌠thereâs life after fleming, too.
Tokens and Labels touch/are touched by a few thingsâŚ
Permissions and data sharing APIs being one key area where there is a need for improvement over the status-quo. Especially when we look at the UX work on permissions and making this all simple.
Thereâs been need for overhaul there for some time. Data sharing, multi-sig type operations are known blockers for the decorum team, eg.
That is one aspect. Another is the APIs. Weâve spent a lot of effort trying to streamline our APIs and improve developer experience ahead of network launch. Part of this comes out with safe-cli and the the safe-api thatâs built upon. That got us somewhere good. But persisting data onto the network was still a blocker. We donât have good APIs for that as yet.
Part of the process there lead us down the road to labels instead of containers. This is quite the shift, but from all feedback, and my personal perception is that this is an important shift that will fundamentally change how we (and our apps) are interacting with our data on the network.
As such, it doesnât (IMO) make sense to flesh out a new set of APIs only to immediately get to work on deprecating those (weâve had a lot of API changes over the yearsâŚ).
And for me, labels/tokens are a good thing to be firing in with now in order to reduce API churn (and hopefully therefore developer engagement). As well as completely necessary for where we want to get to with our UX for data + permissions.
(The need for tokens specifically, is to be able easily validate some requests as data handling time, as opposed to requiring client handling code to do all this, as that doesnât have the requisite info. This also opens up cleaner/easier to comprehend data sharing too)
Itâs just the Maidsafe way to not cast certainty on anything. I must say they are geniuses at it. The Roadmap/ Project Boards were first released in May 2019 and no one knows whether we are 3, 6, 9 or 12 months to Fleming, Maxwell, MVP or MVE. Brilliant stuff