MaidSafe Dev Update - February 23, 2017


I don’t know for sure.


Free gets, or even safecoin transfer, can be a worse attack that the mutation of small data as the attacker must sign and send each order of mutation.
Too much work for such small benefits for an attacker but this free mutation can be fundamental for the acceptance of the Safe Network in huge markets like control of small devices or IOT.


It seems SAFE has sprouted so many new capacities. I get that a lot of the implications are implied in the core architecture and amount to a single line of code or a tweaking. But I need to learn about what mutable data is and what mutations are. I know data chains are super deep and will unlock a universe of features like distributed computing. Still it seems some fundamental changes have come that could be important to an end user to know about and I don’t know what they are or grasp the implications. Hoping for a clarifying video soon.


Simple way to think of it is

  • of a SD growing from 100KB max to a MD with 1MB max
  • MD can have “fields” that can be changed separately without the programmer worrying about other fields
  • each field can have different permissions
  • At this point in time changing data in a MD will cost something


Apologies for not following the latest thoughts in how divisibility of safecoin may be implemented, but if it’s implemented with mutable data, that would make micropayments possibly less attractive. Thoughts, everyone?


The use of MDs is really for the wallet database and the sub-coin balance is one field


Hello everyone,

I’m not quite sure if this is the right place to report a bug about the Safe Launcher, so you may replace it.
Currenlty I am running it on a Windows VPS, and had no problems untill now. The Safe Launcher stopped updating about 6 days ago. So I guess there is no connection to the network.
Was there maybe a update that I missed? Can somebody help me with this?
Thanks a lot. Best regards,


Safe Launcher won’t be used anymore.
Wait to see today’s update.


Hey Piluso

Thanks for the update.


Things are worse than I thought in some posts above: independently of the new pay for POST, the datamap will not be stored directly in the directory object anymore:

Master branch:

pub struct File {
    id: XorName,
    metadata: FileMetadata,
    datamap: DataMap,

Dev branch:

pub struct File {
    size: u64,
    created: DateTime<UTC>,
    modified: DateTime<UTC>,
    user_metadata: Vec<u8>,
    data_map_name: XorName,

The datamap is now stored as a name pointing to an immutable data in the network. This means that updating a small file (less than 3KB), which was free beforehand, will cost 2 units from the put balance: one unit to update the directory and another one to store the datamap. For a medium file (between 3KB and 3MB) the update cost, which was 3 units for the new chunks, will become 5 units (directory + datamap + 3 chunks).

The price increase is related to the increase of the number of requests sent to the network, but that’s not a justification because the implementation could remain the same with less traffic and no increased costs. For GET requests this is even totally illogical because these requests are free and Maisafe should try to reduce their number instead of increasing it.

Here is a table to have a global vision of the evolution:

|                                  | Previous implementation | New implementation |
| Update cost of small file        | 0 units                 | 2 units            |
| Update cost of medium file       | 3 units                 | 5 units            |
| Requests to update a small file  | 1 POST                  | 1 POST + 1 PUT     |
| Requests to update a medium file | 1 POST + 3 PUTs         | 1 POST + 4 PUTs    |
| Read cost of any file            | 0 units                 | 0 units            |
| Requests to read a small file    | 1 GET                   | 2 GETs             |
| Requests to read a medium file   | 4 GETs                  | 5 GETs             |

Traffic sizes on the SAFE network
MaidSafe Dev Update - April 27, 2017
Trying to develop
SAFE Network - Test 16
Traffic sizes on the SAFE network

Very good info to have. I would have never known this.

I assume like most things it’s just for testing but still, should be getting more efficient with releases, not less.


As far as I understand Mutable Data is all encompassing for the purpose of mobile but I don’t doubt that @tfa knows more about this. Don’t you advocate to keep something in particular about structured data?? But is mobile at all affected by what you suggest?


It seems to me that all changes need to have a cost, simply to prevent spam. If a PUT (post/unit) ends up buying less on average, the price of PUTs should also fall to compensate. The cost should ultimately reflect the load on the network to complete the operation.


Do you have anything to back that opinion up?

Don’t you think it is much more logical that restrictions will be added and efficiency lost in the process of figuring out how to make the network actually work in the wild (as opposed to work as a concept in David’s head)?

The project is still trying to figure out if it is even possible to implement. Don’t be surprised if a major rewrite is still needed as we get past alpha2. Currently the project is in the fifth or sixth major design paradigm.


The skeleton of SAFE is complicated and has to be perfect, that’s what has taken all the time and re-writes. If and when those foundations are solid the fleshing out should be much quicker and easier. David has made quite a few comments referring to the transition into simpler and faster iterations and feature additions.

I think we’re well past the point of figuring out of this is possible, it is now just a question of making sure this project gets it right.

It’s fair enough that you’ve become a little jaded and pessimistic. It is frustrating waiting a long time for something so exciting. I think we’re all victims of our own bias though, whether that be optimism or pessimism.


Not pessimistic, just realistic. Your enthusiasm seems to blind you from the truth.

We know most parts of the system are sound, just not if it all can work together as originally envisioned.

It would be immature to not expect at least one further rewrite/redesign between first public release and final release (safecoin no-return).


I’d raise one eyebrow to your wording. It seems quite unlikely to me. Although it depends what you mean by a rewrite I suppose. If you’re talking about the whole fundamental architecture then I’d say it was certainly more pessimistic than realistic to suggest that is ‘likely’, let alone suggesting it is so certain that not feeling sure of that was immature…? Tbh I’d describe your confidence in it happening as more immature. The truth is no one knows so insulting the opposite pov is the immature response given the absence of any real substance to either guess.

Each to their own, you’re free to be a pessimist. No one ever thinks their bias is anything but realistic, that’s why they hold their opinions, because they think they are realistic.


Maybe optimistic, rather than immature I think. I’m just thinking though (totally not my area) but does it even matter how many PUTs there are - is it not just all relative?
I’m no techie, but if something costs 1 PUT @10 cents, is that not just the same as costing 10 PUTs @ 1 cent?
I’m sure I must be missing something here, as not getting how it matters? :smile:


With rewrite i mean what is currently happening. A new paradigm of how the network is arranged. What it looks like to the user/developer.

As i said, the major parts, the technologies are somewhat tested and at least seems to be working. The concept, the complete system and all the interconnected aspects are totally untested since nothing remotely resembling a release has yet emerged.


That can become very subjective though pretty quickly. definitions of things like “major parts” “complete system” “rewrite” etc. There is no doubt the system evolves to launch, but I think we are in a place where we are surely iterating and not rewriting. Sometimes a change is big, like disjoint groups to allow data chains. That was a huge change, granted, but it’s not clear what iterations will require through launch. They feel contained for sure, i hope others see this from the updates.

tl;dr Iterations will mean change, but constrained change and thorough testing. It’s the best way to handle a complex offering and it seems to be working out nicely, ofc we all wish it was faster, but it’s as fast as we can go, I know that part for sure :wink: