MaidSafe Dev Update - March 9, 2017

The next CEP HAS to be (test)SafeCoin Wallet IMO, because everything else relies / is built on top of that.

Project Decorum’s "Clike"s, all SAFE altcoin projects, every single app on SAFE that lets users post content, and even a decentralised exchange STILL NEEDS SAFECOIN functionality to even make sense.

I don’t understand how the test SafeCoin Wallet can be listed as “after Alpha 3,” that doesn’t quite make sense to me, right?

Before anything else, I think the test SafeCoin wallets need to be made so SafeCoin’s design can be agreed on and tested, and only then can we start to really make test versions of things like an exchange.

Everything else seems rather easy in comparison to the routing logic. So much could and has gone wrong. Once solid, it should be smooth sailing for the most part. The biggest hurdle IMO would be data republish and node ageing. Both seem simple but churn is a bitch. Again, with routing solidified this become much easier. Data chains acts as the glue that holds it all together.

I strongly believe that none of the upcoming features will individually take 2 - 3 months to properly implement. Being that some will be coded in parallel, the total time needed for full deployment should be no more than 6 -7 months. Most of this time will be spent tweaking the various features. Once there we’ll be in beta. I believe Maidsafe will then run beta for at the very least 3 months. Like a community soak test with real-time updates. Mmmm marinate… :yum:

Unless something catastrophic occurs or some overlooked detail rears is head we should be live around November-ish. That’s my prediction. There will a lot of pressure on the front end UI/UX team to make this happen. If I know Maidsafe they wont release 1.0 without a compelling full featured app (no more demos). Which will have an easy and intuitive interface.

If they focus on Data-Chains now and get the real-time upgrades in as a result, everything should move much faster. Tweaks and upgrades could be put into place with ease and less community frustration. Agility is key in this race against the clock. :grimacing:


A decentralized exchange just needs the mutable data type in place before one can be constructed with test coins of any kind.

They will likely integrate a rudimentary wallet before going all in. I think that’s what they meant.

Yep. Cant drive the car without storage for the fuel! :smile:

Not sure if you’re overall agreeing or not but

This still sounds like a waste of time and work, because it would need to be rewritten anyway to work with SafeCoin ultimately.

Test SafeCoin wallet should be a very very much more near-term goal IMO

It would almost trivial to switch over to the reserved data ID when ready. I might be wrong but isn’t safecoin just a piece mutable data? If they code the exchange with mutable in mind it should be a breeze to swap. :relaxed:

1 Like

One already exists. A few tweaks and it should be on SAFE with little effort. @bochaco ?

I think were very far along all of these roads. :slight_smile:

Good, even more reason to have test SafeCoin sooner, like in the test nets between Alpha 2 & 3

Not without data chains and republish in place. I know you’re eager but as you said before, you can’t have things without its prerequisites. Safecoins require perfect data retention to work. Otherwise it’s like transferring any other MD object we will have. The difference being the title. Seems pointless to implement prematurely if its just for the novelty. Hell, if you wanted to you could create your own “safeRcoins” with the mutable data type and go nuts!


…what? :stuck_out_tongue:

Maybe they require all that to work perfectly, but not to simply work.

I still think they should be broken into ASAP, and not be expected to work perfectly until the network itself is working perfectly.

I don’t see any reason to not start working on them now. But we’ve made our points and I’ll stop repeating

Why create test coin when mutable data exists? They would be no different than a mutable data object that is transferred between users. The moniker safecoin in this case is just that, a label. No point in testing something in conditions that don’t reflect its various functions.

Again, you can create something EXACTLY like safecoin by setting that as the name of any mutable data object. Use it as token for test goods as you would the true coin. Implementing TEST safecoin is multifaceted on the other hand as you would need farming in place along with the resource and value algorithm.

Otherwise its no different from any other mutable data object. So I believe there’s little point in coding those other algorithms when Data-chains must be in place to properly test farming and resource value.

The goal is perfection. Test coin would be of very little productive analytical value unless it can be tweaked dynamically by devs while they are in use. Else devs will just say well data chains will fix this or that when problems inevitably occur in a knowingly lossy network. It’s like putting fuel in a tank full of holes then telling us to drive knowing we wont get beyond the first block. When the driver complains or failure occurs as expected the driver has no choice but to wait for a proper gas tank to be put in place before successfully driving the vehicle.

Alternatively if a proper tank were in place (data chains) and loss or failure to occurs it would be both surprising and more meaningful. Tweaks can then be applied with the expectation that the feature will begin working as intended. As it is now safecoin failures would be obvious with nothing we could do until data chains are in place. Like you stated earlier:

Same scenario. :stuck_out_tongue_winking_eye:

The digital property “Safecoin” itself is not the point. Yeah, it’s a specialized Mutable Data object. But it’s a reserved type. The testing is to handle the algorithms and coding for the network creating (issuing) and destroying (accepting them for x amount of PUTs–a variable quantity based on network state), etc. The basic maths on these have pretty much been worked out, I think, but need to be tested and tweaked on an actual running network.


Data loss while data is at rest and during transfer of coins would skew the test results making it difficult to diagnose true issues with the algorithm. Data chains makes that impossible. Am I missing something?

As @fergish says

Plus the handling of the reserved tag “SAFEcoin” is very different than for mutable data with extra checks and other group consensus to ensure atomic transfer of the coin (MD). There can be no period of time where the SAFEcoin MD has 2 owners. 2 owners can occur when some copies of the MD is owned by one and the other copies by another which may allow a condition where the coin is transferred to yet another owner before the first one is finished. This could cause real problems in not knowing who the real owner is when the groups reach consensus. Mind you there could also be other race conditions. So SAFEcoin has special handling to ensure there is never a problem. Whereas the transfer of ownership of a MD doesn’t have such a consequence as losing coins.

Not exactly like, but any MD would allow basic testing of a wallet APP since the difference in handling is within the network code to ensure atomic transfers and resist attacks.

Not sure. More likely I’m missing something about your question. Now I’m unsure what your question is. If it’s about working on a decentralized exchange, I’m sure such could be pretty well solid prior to solidifying safecoin, as there’d need to be other MD tokens in play as well. Getting above my depth here, though.

1 Like

A distinction not worth going through the trouble of testing safecoins without data-chains IMO. With data loss on any level checking for ownership and special handling of the reserved MD’s will result in inevitable failure. We can already observe how data in general is handled by each test. Those extra checks are essentially the same process undergone by routing to verify and transfer data. Small changes would be necessary to ensure routing handles coins with greater care.

1 Like

That was @whiteoutmashups concern not mine. I suggested the same. Use MD’s to play with and mature the exchange until safecoin is ready.

This was in regard to being able to properly test safecoins and the associated algorithms. Handling coins on the routing layer is the easy part. Its farming and resource value that need data chains to properly tweak IMHO.


Yeah. And I do thing that data chains is planned prior to testsafecoin, at least per the list in the OP.


Yes, definitely definitely are.

Missing how important it is to start tackling the development of SafeCoin, which will have many parts to overcome

I think prioritising SafeCoin is sensible. If you look at the testnets we have a lot of churn because there is no real incentive to offer a stable vault. If vault operators start getting rewarded with ‘testSafeCoin’ then the vaults are going to start becoming more stable and ‘real-world’ in their operation.


The point of testnets is to stress them, and get something that works even with high levels of churn. Testing Safecoin with something that is significantly different from Safecoin is useful, but doesn’t tell us what we need to know, and just delays getting to the point where we can test with the actual implementation of Safecoin.

The most value would be in testing other things, but must of that can be done in other ways, as @bochaco did with his thankscoin.

I think MaidSafe know what they’re doing in terms of delivering the network. If developers have specific requirements that they feel would be addressed by a dummy or earlier Safecoin implementation, MaidSafe have said they are available to help out.

So I suggest that’s an issue for each Dev to consider - what might MaidSafe help you with from here on.