Thanks Maidsafe devs for all your hard work.
It’s not easy what you guys do, matter of fact, it has never been done before. 
Totally agree
2 Likes
Keep up the good work 
1 Like
+ i would like to add here "and hang out a little bit in the hidden forum on http://projectdecorum.safenet/category.htm?id=hidden " 
oooooh i love you all @dirvine @Krishna_Kumar @Ross @ustulation @Shankar , … and @Seneca this is SOOO Cool!!!
5 Likes
Only natural, this turn of events. (i.e. Shed the hold-up; deal with it separately and at a later time.)
Now we are only days away (how many…?) from a massive field trip of field testing, with everyone’s vaults.
You could really feel it—at the end of February—with the devs shouting confidently/like never before, about the test-net, for days on end, leading up to its eventual full-blown release.
…
I yearn for those days once again, that feeling the devs create in themselves; thus the community.
3 Likes
I am confused. Can someone from maidsafe please clarify if this is Discuss Proposed - 0016-launcher-data-types-api · Issue #77 · maidsafe/rfcs · GitHub or not? I can’t decide whether it’s worth my effort to review that 6 month old issue and add my discussion there or if I should wait for this “RFC […] being worked on”…please help with all of this confusion.
1 Like
There is the linked RFC which is how API’s are provided by the launcher and then there will be several RFC’s for SD types and handling of them. Internal debates have been on what the launcher allows and how that relates to people going straight to client/ffi and grabbing those API calls. We are looking at the client/ffi API being the Low Level API and the launcher being the easier higher level API.
So in launcher it is an attempt to make it single login / authorise apps.
Direct low level access may mean an app is doing the wrong thing (as it’s able to at that level) and may not be safe (in lower case).
Many of the RFC’s aged while we were in the middle of the big push there and getting pulled way down to routing refctor then crust issues. So now we hope to have more resource in upper layers and around these RFC’s.
Hope this helps. @Ross will help shepherd people through the process and help to link up with specific devs when required and also when we can pull a dev off their tasks to get to the RFC. I hope this will get easier as we add resources and make some more hires as it’s tight right now, but very important we get thorough the RFC’s as well. This is a major part of Ross’s new role and a vital one. He is the guy for it though 
7 Likes
Thanks for the info. I will provide feedback on the launcher API in Discuss Proposed - 0016-launcher-data-types-api · Issue #77 · maidsafe/rfcs · GitHub then. Speaking a bit selfishly, the reason I use the launcher API instead of linking routing/core/etc is due to licensing. Also, I love that my app does not have to manage user credentials.
2 Likes
No worries, we are busy and tight right now, but in the rfc process don’t feel wary of shouting for attention. The more the community are involved the better it will get and by a long chalk. So please do shout and also help out where we see any way to violate safety and unSAFE app usage etc.
Thanks again.
3 Likes
So the MVP will simply be the current feature-set, but with decentralized vaults? No testsafecoin? No messaging?
Will the MVP be considered 1.0? Even though the MVP will not be a permanent network (reset for testing)?
Yes data only for now then reintro of farming rate calculation then messaging added back in. MVP will be a decentralised autonomous network with self_authentication, structured data and immutable data with launcher etc. (dns and others).
The key here is proving all this works (it does) then at scale pushing boundaries i.e. we are running tests to set vauls space very low and filling network to see how it reacts and ensure there is no data loss when network goes read_only (which it should never do in the wild). Then we add the next (small) phase which allows vaults to delete sacrificial data (think as a buffer) and make sure the farming rate increases to make farming more attractive etc.
Then messaging in vaults → then client (we want to see a load of these apps)
This allows multisig to be used
Then safcoin and client wallets etc.
When Utp is all OK and tested we move to Beta.
Hope that helps.
13 Likes
Beta…
is…
the…
best.
4 Likes
So the issue of free versus non-free GETS might be settled by clients scripting massive amounts of GETS of some popular file? All in the name of testing, of course.
1 Like
But, of course 
2 Likes
This issue keeps coming up. If you do massive gets on a popular file you wont really stress the network. Maybe some close nodes where the data is cached but that’s it. If you really want to stress the network hard, you need to script massive amounts of gets on NON popular data. One access of a file, then let it sit for an hour while you get other files. If its still in a cache on your route, there is no GET request. I’m all for stressing the network, but got to have the right premise.
4 Likes
Approximately how long do you think it’ll take to go from a TCP enabled MVP to adding UDP functionality on top of it as well? Are we talking a couple weeks, a month, 6 months? And about how long until a TCP enabled MVP is available?
“Dad I know you want to just stop and see the giant ball of yarn instead of drive all the way to Dinseyland but still are we there yet?”
Also I’m curious, how much of a practical difference does TCP compared to UDP make? I mean what are some of the things one can or can’t do with the connection types?
2 Likes
I can’t comment on the time, however TCP vs uTP for the end user really will boil down to configuration for most people.
If you’re behind a NAT router (majority of people) you’ll most likely have to go to the settings and set up “port forwarding” to the computer you want to run your vault on.
There are other differences, but to (vast majority of) us end users, that’s the only real practical one we’ll see. Please correct me if I’m wrong.
2 Likes
I think this is splendid news, good results there are absolutely vital for the feasability of the entire concept of SAFE.
12 Likes
Beta < TestNet3 < Dev Bundle 3 < Dev Bundle 2 < No Roadmap < MVP < MVP without Utp < We have arrived!!! 
1 Like
OK, but wouldn’t that make that data “popular”?
I guess I worded it poorly. A single get on massive amounts of different data. By making something popular, you don’t require gets anymore, it’ll be in cache. So if you can compile a list of every file on the network, then know when it was last accessed you could put maximum stress on the network by waiting about 5-10 minutes since the last access getting that file. Script this for every file you know of on the network.
This is obviously not possible, but I hope it illustrates what im trying to say.
If a file is really popular, it won’t be getting many gets because it will be in cache along the route.
1 Like