No worries, my approach is, during research then timelines are almost useless unless you know the speed of solutions to peoples brains As we don’t then timelines are no more than deadlines, so finish by X or die. However as I am indicating the research side is almost (if not totally) done now in terms of “the big questions”, i.e. login to decentralised network, incentivise mechanism, value transfer, consensus in public hostile networks and so on. we all know those big questions.
So now we move to a new phase, a phase where we do not know every detail, but we do know every mechanism required to get to MVP/Beta etc. Working out the details, improving the RFCs for that, designing or speccing out the implementation of remaining work is still not able to estimate these 100%, but much closer than previous iterations. We will though be able to identify critical path to launch and then more clearly identify dependencies and give overall estimates, which of course are all based on task estimates. So we can now show a much clearer picture that will definitely change and show an overall timescale that will definitely change as all projects do. However we are close to being able to supply this to everyone. Its a big job that is being worked on for the past while. We will be able to show a much clearer picture, it will allow folk to clearly see the picture, but it will also allow a ton more critique and fake news etc, but it is price worth paying and we will pay it
As MaidSafe approaches VCs and other potential sources of capital, how is the team weighing trading control in exchange for value beyond financing? For example: how much control (i.e. setting priorities regarding the projects direction) would MaidSafe be willing to cede in exchange for financing and strategic alliances/relationships to enable,
I suppose with the right partner, the vision should be aligned, but seldom do people who are already on the same team completely agree. That was more of a rhetorical question in the “food for thought” variety. No detailed answer requested, as I wouldn’t publicly answer in detail so as not to weaken my negotiating position. These are times when everyone could use a rich uncle with no-strings cash to give…
With regards to PARSEC: I’ve been on/attended multiple calls/conferences with so called DLT experts/market analysts as I investigate opportunities for an initiative at work. I always make it a point to ask them about PARSEC. The response is generally the same—they’ve heard of PARSEC but don’t have much to say because:
They don’t understand PARSEC due to their lack of technological know-how (while lots of people like to talk a lot about DLT, very few actually understand it’s cryptographic underpinnings)
PARSEC’s very nature disproves what was long held to be true
Those two things when taken together breed silence until someone(s) who are both well respected and not directly associated with MaidSafe speak up and loudly vouch for PARSEC’s validity. Absent that, people see too much reputational risk to stick out their necks in support of something that remains untested in the wild. Fortunately, these are matters time, good work, and strategic networking (e.g. a number of reputable peer reviews) can surmount.
Control over roadmap, introductions they can make, the value they place on the company, the level of equity involved, do they demand preference shares, board seats…etc will all weigh heavily on our decision making and at this point I couldn’t prioritise one over the other, we’ll need to see the entire term sheet(s) as a package and evaluate from there.
Agree 100% - that is why the team have spent time working on getting more formal validation and peer review by working with University partners.
Of course, the rate of dilution is decreased, but often these late rounds are not planned and that was the point I was highlighting. But I think we can agree that letting people know about your funding strategy is advantageous when it is nailed down and known, and that is something we’ll continue to articulate in future updates.
Have you caught the Fleming updates (Topics tagged fleming) - these explain from a high level perspective many of the big questions that the dev team have been working to overcome and provide an insight into the challenges faced.
Thanks @happybeing. I think many (including me) were under the impression when getting into the SAFENetwork that the team had identified a solution and were now working on implementing that solution. It’s more and more seeming that they had only identified the problem, and are working on a solution and a design at the same time.
You have a much more detailed knowledge and view of the status and the history than most, without being an insider. Would you be willing to give some examples of cases from memory that can help us understand how it seemed to the team that a solution had been found but in fact when it came to implementation the conceptual solution wasn’t complete or functional?
In fact @Stark gave a good response to this question just above. Would love additional thoughts from you too though happy’.
This is an exciting update and Spandan is a wonderful engineer, but this seems like an exercise in exactly the kind of optimisation you said you weren’t prioritising until after MVP.
To reiterate the concern, it is that finite resources are being spent on sub-projects which don’t contribute to the core design. The reason this matters is that once the core design is proved, the tech and investments are de-risked. Crust was already an example used of a potentially non-essential project as port forwarding would do the job MVP-style. We now learn that crust is being largely reengineered.
@opacey As an outsider I’m not sure I could do more than catalogue the development (which is available to anyone willing to go through the updates and pick out relevant forum announcements). I can’t add anything on what the team ‘thought’ about various aspects that isn’t in the public record.
I guess you are hoping I have a good memory for this kind of stuff, and be able to reel off key events, but I’m not good at that.
“we’re hungry enough to understand that if better solutions exist that let us get the Network ready for you faster, without any compromises, we should take that opportunity and grab it with both hands”
… so this isn’t perfectionism delaying the network, but a worthwhile change that can improve the network and also solve some problems that could make it faster to get to launch.
It’s a brave decision after significant sunk costs on Crust, but if it means faster to launch among other advantages, it seems to be a great decision.
You are right, but after Oscars post I started to wonder if the whole Crust was that important - from the MVP point of view.
Of course Secure Access For Everyone, requires some kind of solution to these problems, but from the MVP point of view, does it really need to be everyone, or is it enough if the secure access is only for those who happen to have right kind of connectivity? It could be expanded from there.
I’m all for developing different aspects of the network in parallel, but it is true that it needs more resources than developing smaller slice of things.
I can see what you’re saying, and it’s a fair question.
However, for a product called Secure Access For Everyone, to be viable may mean being accessible to most people who try.
For a Beta, the requirements may be lower (possibly harder to connect etc), but for an MVP that is truly viable, I expect it’s essential that there is no hold up in adoption due to SAFE being only for the few (SAFS network - Secure Access For Some ).
I think it is fair to say that at crowd fund time a prototype had been developed using C. I also thought that the finish line was much closer at the time.
I think it became clear that a number of things weren’t sufficient over the years since:
Rust instead of C to help scale the code base.
Flexible consensus algorithm (PARSEC) instead of case specific consensus rules.
Data chains to allow splits and restarts to be handled.
Library bindings needed to support mobile platforms and also improve performance compared with local rest proxy.
Custom browser needed, as plugins could never provide reasonable security.
Crust to provide a way to work around home routers without requiring upnp settings, which would prevent home vaults.
I think the basic principles were probably close at crowd funding time, but taking them to something which is reliable and can scale was unexpected by the team. Perhaps they were overly optimistic, but the source code and papers were available to read for those able enough.
In isolation, regardless of the above, maidsafecoin has been a good investment, especially for those who sold at the end of 2017. In contrast with other projects of the time, such as ethereum, it has been a relatively poor investment. However, I still believe the product with be more useful than those counterparts and the team seem to have the vision and the skills to deliver it.
I think many of us are feeling a little jaded at this time, but this is the deepest depths of the bear market, imo. With signs of the market recovering, it is natural for people to take stock and check the horse they are backing is fit to make the distance. The evidence suggests that it could be, but I think we are all looking forward to getting something more substantial to reassure us.
Thanks for the ace reply. Indeed these are darker times than we’ve had in the past.
Your list is a great answer to my question as to what things were unexpected. From that list I’d say that Rust (maybe), bindings for mobile, custom browser and crust are non MVP. It is better planning to focus available resources on the core things (like Consensus/PARSEC) in order to become cash flow positive and then build the other things after. If MaidSafe need new funding but receive a ‘no’ from the market - what then?
Not really, this is a move that gets that layer complete faster than we could with CRUST (and with less resources). That means we get to MVP faster with quic-p2p than trying to bend TCP and use our own encryption mechanism for securing the network. quic does way more than crust did, we could keep bashing crust into shape, but it would be wasted effort. When we started and until recently nothing was available, lib-p2p an some are getting there, but crust is still in front in many ways. quic just makes it all simpler, more secure and standards based and best of all, we don’t need to write it, the quinn crate exists, we tested it, it works (so far) and does what we want barr a couple of points like bootstrap cache etc. We added them to quinn, released quic-p2p and the crust type design work is now redundant. So this is a solid Engineering decision, based on speed to launch with the superb side effects of increased speed, better security and becoming a global standard.
Good point and I think it should be expanded to ‘who is the initial target audience and how does that audience change as the product matures’. Identifying audience and their required feature set is very important.
I love the GUIs and easy workflows (it’s what got me into this project in the first place), but that’s probably meant for an audience well after the mvp. Hurts me to say this because I value ease-of-use so highly.
Yes, it is a balance though, the network is 3 classes of people/things
Resource providers (farmers)
Resource creators (publishers)
Resource users (consumers of the data/resources).
It is easy to think, we only need to cater fro 1 and a bit of 2 and it is MVP, but it is likely not, it is likely a dead network of a few nodes we run ourselves. without 3, everything breaks and that is not obvious. So we need 3, so we need glitz and , fantastic user experiences etc.
We need most of 2 as well. So out project critical path say, will be to a workable network, not necessarily a working network (as that needs 3). Without 3 there is no adoptions and that probably breaks everything, but getting 3 means clicking that magic app, or magic service that works. So critical path is clinical to working system, the apps etc. and frontend are critical to an adopted system. The latter being inordinately difficult to evaluate, but we will try as we move forward.
Hope that makes sense? Seems unclear, but it really is not, I think it is realistic, but happy to hear otherwise (as usual)
It’ll be fun to see what happens where these two roles merge, eg email is very-much a combo of these, forums also… I’m a little anxious about the hurdle between consumer to producer but if the interface is right then it really will look after itself.
Glad to have such talent on all fronts of the maidsafe vision.
Thanks again for the response @dirvine. That makes a lot of sense and despite emotional attachment to the invested effort in a creation which is always inevitable, ditching it for a better solution is indicative of solution driven design.
I’m still of the view that this functionality could be dropped aside for MVP and replaced with port forwarding or UPnP but I’ve made that point enough now so I’ll shut-up.
As we don’t then timelines are no more than deadlines, so finish by X or die. However as I am indicating the research side is almost (if not totally) done now in terms of “the big questions”, i.e. login to decentralised network, incentivise mechanism, value transfer, consensus in public hostile networks and so on. we all know those big questions.
