Questions about Update and segmentation of the network

This company is not immune to the billion dollar bat to the head. We can all agree that this technology has great potential. As such it will be a very enticing acquisition target for those with deeeeeep pockets. What happens to privacy security and freedom once these giants set their eyes on Maidsafe.

First thing they’ll do is strip the system of anonymity. Then introduce a monitoring system. It will be subtle at first then eventually well known. Patents can be bought, GPL license eliminated (closing the source code), shares increased to the level of voting dominance, and as it stands the network will likely be upgraded and maintained by MaidSafe. Leaving the door open to attack.

How is the network going to survive under these circumstances? Have all the holes been sealed? If so how EXACTLY? What assurance do we the people have after all of this time and support that our vision of a SAFE world wont be undermined by the wealthy and power hungry? It’s hard to believe that an educational non profit will turn away billions that could serve the students in exchange for voting manipulation.


when the network goes live, nobody can stop it anymore.

1 Like

How will it become more efficient without updates? Who decides these updates? Who applies them? How will segmentation be avoided?

Welcome to the forum @BlazeThat

The questions you raise are large and there are numerous topics on this forum that discuss these issues. Can I suggest that you avail yourself of these discussions.

Being Open Sourced means that there will be people who can raise the alarm if any modifications are removing anonymity. But since anonymity is at the core of the design and code the removal of such will involve noticeable changes. It will be up to the people running the nodes/vaults to decide if they accept the update and install it.


Maybe, but if MaidSafe has the initial power to update the network then they could potentially be applied quickly leaving little to no time for audit.

How will this happen? Most users won’t scrutinize code or refer to information outlets prior to updates. The bulk of the network will consist of relatively careless folk who just want things to work. Their majority hold of the network is a security risk in this regard. Leaving those who don’t choose to upgrade with little cover and poor group security.

Quite honestly, I believe untainted upgrades to be the biggest hurdle for an autonomous and decentralized network like SAFE. I’ve perused this forum looking into a few discussions about future network maintenance and have seen nothing that suggests a flawless uncorruptible mechanism. A thread should be opened for this purpose. First here then distilled and advanced in the dev forum. This is very important IMO. Sooner than later.


There are many known ways to sign binaries and source code - this much is trivial. Auditing changes ad they are committed to the github is also trivial and just takes a bit of time.

Therefore, this is more of a question of how to establish a trustworthy process. Perhaps the client would seek approval from a list of external auditors, before updating itself? There are many options here.

This is way off topic tough, so I hope the mods move this debate. No need to pour FUD in the investment thread.


Will do when i get the privs. The answer is still unclear.
i don’t doubt the networks future viability; only its continued maintenance adherent to the current values.


Really? It’s hard for me to believe. If the things you describe start to happen, then the whole ethos of MAID will be destroyed and users will go back to the clear net. What possible motivation would anyone who is running this project or the foundation have to destroy it?

1 Like

Not the current runners but the future tempting big wigs. They’re the concern. Is MS immune to that venom? If so how?

You do bring up important concerns. The mitigation so far has been

  1. GPL (obv)
  2. Clean code and documentation (to allow others to work on it)
  3. Encourage core code contributions (pay 3rd party devs for work on the code)
  4. Core reward mechanism to encourage pods or other parties to also be involved in core.

I am sure there will be more in the future, but essentially if folks are bought in to SAFE and there are some with moderate coding skills then it can be maintained always free to everyone.


Coders can be bought, gpl can be changed for future iterations, and the speed of upgrades can make malicious code integration fast due to ignorance, public MS trust, and rapid network uptake. Like secure node joining, UNTAINTED updates needs its own RFC to work out the best method. As it stands, future network iteration can be manipulated to act against current ideals.

I agree somewhat, but mitigation starts with something, you cannot just remove GPL from future updates, these are derivative works, so this would be something like perhaps buying out the coders and create soemthing new. I think if you bought the coders from all over and made them do some bad work, somebody would surely squeal and we would all know. Even here on this forum we see the code getting committed etc. many more folks will watch, but I agree software is complex, bugs and bad things can happen

At least with GPL nobody can take away what is there, so this is a starting point.

code updates and things like reproducible builds all help and should be considered (although reproducible builds may not do what we want).

Manipulation to remove some parts will actually be very difficult, such as node name creation etc. Removing self auth would be a massive breaking change and cause big behaviour changes etc. We can just keep that in mind.

I think for now we keep this in mind, we won’t fix this before launch, if it is fixable, but to get as many folks familiar as possible and users using it I feel will the the very best way to ensure malicious changes can be spotted. Then decentralising the dev and future direction, rust does well, bitcoins shows the issues that can happen and they are serious. So I am not denying much of this, some is possible for sure, but right now my focus is on launch. This is always there in the background though.


I’d say yes because MaidSafe or at least Mr. Irvine isn’t building SAFE for the money or anything like that; I have heard many times in interviews that his real missions are getting it built correctly and successfully so that people can be free to invent faster and create things like future longevity tech, so we don’t all end up dying here like previous generations.

So in terms of MaidSafe being bought out for billions by Google etc, I never saw that as something to worry about, because if it did then he and us all would eventually just die because that innovation would never happen fast enough for any of us.

So even in the face of billions of dollars I don’t see that as something that would prevent SAFE. Feeling the same way about that topics is one reason I believe in his desire to legitimately see these things through no matter what.

Money alone can’t buy you more time. Only a world where people are free to innovate.


People can be corrupted, in usa they can even receive a national security letter forcing them to include a backdoor etc. And the only way to protect against it is to have open source code and enough people looking through it and at the implemented changes that a malicious change is spotted.

By having the developers staying pseudonymous the state terrorism part can be mitigated. By offering incentives the corruption part can be mitigated. But not entirely fixed since some attackers have billions to spend, and some people don’t care about money if they can cause real harm or gain control.


I think that if all that start to happen, it just means MAID is successful disrupting the internet and the way it’s today, so we will be happy we achieved the first goal :grin:


This shows that forks are a diversity function almost like in genetic theory of sex repro vs parasitism. Its why Tesla recognized early on that competitors were so important and opensourced to help get them started. Safety in compartmentalized numbers.