Implementation of multi ownership

The blog post Beyond a copy of the Internet shows possible usages of multi ownership offered by safe network. The problem is that I don’t see how the MD structure allows this.

The post indicates that the machinery already exists and is based on MDs:

SAFE has multisig data types (the machinery is there, but not yet enabled), these data types are called Mutable Data (MD) and can be mutated by the owners.

It also gives some details on how this works:

With multisig this means ownership is the majority of ‘owners’. Now we have a data item on a network that is not owned by any of the companies involved, but editable by the majority of those owners.

The problem is that I don’t see in the code how this is implemented. There are 2 potential mechanisms but none of them seems to work for me:

  • owners field: The first problem is that any owner can change the owner set and another problem is that it only controls changes in the owner set, meaning that it manages itself but nothing else useful!

  • permissions field: Three permissions allow insertions, updates or deletion of entries. There is a fourth permission that allows modifications of the permission set. Someone having this permission can be considered an owner because it can grant himself the right to modify the entries and can grant the same permission to others. But there is the same problem here: any user having this permission can unilaterally grant it or remove it from other users.

In these two definitions of ownership, an owner can modify the owner set without needing a majority. So, I don’t see how this feature described by the post can be implemented.

A solution could be a centralized one where an entity has the “manage permissions” permission. This entity would then define the owners as the users having the right to modify the MDs entries. If would also create an app that allows these owners to vote for adding or removing a new owner. Then this entity would update the permission set depending on the result of the vote. But I am sure this is not what is planned by Maidsafe because this reliance on a controlling entity is contrary to the safe network principles.

I am certainly missing something because multi ownership with a majority control has been previously implemented in a trustless way with SDs. Can someone from Maidsafe clarify how multi ownership can be implemented with MDs?


I’m waiting too the Dev solution about multi ownership but, as Safe use Schnorr signatures, exist a solution using Key Tree Signatures.

For example if we have 3 owner (A,B,C) and want a 2 of 3 vote to change the MD we need any of the following keys (KeyA+KeyB), (KeyA+KeyC) or (KeyB+KeyC).

Hope I can help, please be aware this is not 100% flushed out and may change slightly.

The owners field is a vector of size 1 right now (hashset/vec, makes no diff really). It can be an outright majority (> 50%) but may be more granular (from your next point.

instead of just the owners field we can have granular controls, so owners could be Ford, Tesla etc. with sub organisations/managers in the granular controls fields.

So the post says the machinery is there, this is the Vec, however its limited to 1 entry right now. The part that prevents us (apart from time, this usual) is the messaging of signature gathering (this is the part to flesh out). It is not difficult though and there are two pretty clear options IMO

  1. The network holds signatures to alter an MD until there are “enough” to make the alteration. (State on network is not always good though).

  2. Clients pass round the MD item to be signed and append sigs to this until there are enough. (not so nice and bad clients may consume and not send this, although we can use a broadcast/collect system to subvert that).

We have plenty of options though and data chains will allow the ability to have data act as though the signatures were part of the MD, just as they were with the SD, but validated on the chain, not internal to the data.

I hope this helps, as usual time is our killer, the team wont get to involved in the convo I think as they are against the cosh with the current releases, but I hope this helps at least. I can try and explain more, but feel the team also need the discussions internally as well if you see what I mean. So shout if this misses your point chap, I will try and add more to this suggested route.


Datachain once again! Aren’t you afraid this concept is becoming too overloaded and is turning into a magic wand that does everything but will be too complex to implement?

I liked SD simplicity and its sharing of responsibilities: signatures gathering was done client side which reduced vault complexity. Transfer of ownership was a single step operation for vaults because the signatures were sent all at once and the vaults had just to check that a majority of previous owners signed the new version.

Another thing I want to mention about ownership is the features that were implemented with SDs that should not be forgotten in the new system:

  • proof of transfer should be simple to get (this was the case previously because signatures were stored locally in the SD)

  • the whole list of new owners should be signed by previous owners, meaning that they agree on the new list in its globality and not simply on each new owner individually

  • new owners should be able to optionally add their signatures to show their acceptance of ownership


Not at all, it will simplify both data and proof of network validated data, even without a network. So not more complex, but simpler in many ways.

I agree, there are internal debates, but the network can still prove transfer, but the internal sigs were nice from some perspectives. Not a huge tech issue to have them or not, so not too worried about that when we get to flesh out multisig, network or client side.

I think you mean signed by a majority of previous owners? I don’t think we had or would have change on single old owners signature. If the network did the xfer it would hold sigs until there was a quorum of old owners. If implemented then there would be a revocation (singed unique data element) for xfsers that cancelled I imagine.

I am not sure this would do much, but would be more complex. Do you have a particular case in mind for this one?


I don’t quite understand but my point was that a majority of previous owners must sign the same MD with the same set of new owners. Is this OK?

This is to avoid that a receiver later claims that he didn’t solicit the transfer. To mitigate such a risk the sender could ask the receivers to sign the new MD with the new owner list. This is optional meaning that a sender may or may not ask for such signatures before initiating a transfer.

I just wrote this, but now I am thinking that the sender can just store these signatures somewhere in case of a future claim, meaning finally that new owners signatures don’t need to be part of the transfer protocol.

So, this point doesn’t need to be taken into account.

1 Like

Ah yes, sorry chap, I think I was misreading your point :slight_smile: my bad I think.

Ah yes, no worries. I think when we flesh out multisig proper a lot of this has to be considered though. When alpha 4 is done multisig is gonna take part in the rollout as it will help safecoin security an awful lot. So makes sense. Good to keep these posts and use them as aid memoirs though :+1:


What I am a bit anxious about is that as far as I understand darachain won’t be really tested until alpha 3. We had vaults in Alpha 1. MD in alpha 2. But datachain will be tested in the wild to high scale only later, right ?

But it looks like a lot is dependant on datachains. Are you still conducting internal testing on your side ? Is it boding well ?

It’s a large part but will be tested in testnets. In terms of at scale, then we wont know if it works at billions of nodes until we actually have them. We do simulations etc. but you can never beat real world testing of anything. It’s usually silly errors that affect scale, I am not sure a design choice like data chains will, but you can never say, the perfect design and implementation just does not exist on this planet yet :slight_smile:

A lot depends on many aspects of the system really, group consensus, disjoint sections, data types etc. It’s why we do so many tests really. So test, test and then test some more, but in between simulate and during coding use unit tests, integration tests and acceptance tests in a continuous integration system.

In terms of big system parts to be tested, I feel we will have them well tested or at least best we can before actual launch.


So first testnet after alpha 2 will incorporate datachains :wink: ? I don’t expect an answer of course but I do keep my fingers cross…

Maybe not the first, but no worries man people continue to try and read between the lines :slight_smile: all good fun, but honestly we don’t know until a few days before each testnet on many occasions, but alpha 3 based testnets will be moving us towards data chains part1 (no data) and then alpha 4 (with data).

So imagine datachains part1 is XX Jira tasks, with each testnet we should be getting through those a bit at a time, until they are complete then datachains part1 is not complete :wink:


Lol my heart almost failed me when I read alpha 4. Please never mention an alpha 5 anywhere I am not sure I will be able to emotionally cope with this possibility.

1 Like