Actually, a general reference as to the options for the “permissions” parameter of mutable objects would be nice.
I’m still in the conceptual stage of a lot of app ideas I have. I want to have a better idea of what is and isn’t possible. A lot of them rely on the ability to create a mutable data object such that:
-Anyone can create a new key-value pair.
-No one, including myself, can delete or change the key-value pair.
-I can’t change the permissions so that I can allow myself or anyone to delete or change the key-pair.
-I can prove to the users that I’ve locked myself out in this way.
Such a structure is central to a lot of the ideas I have in order to make it a truly decentralized, authority-less app. Can I create such a structure, and would it be as durable as immutable data?
This is possible by granting User::Anyone the permission Action::Insert.
This is possible by having only the permission I mentioned above and nothing else.
The ownership of the MutableData structure concerns the power to change permissions. The ownership can be changed to a void public key, I assume. (This has been discussed a few times in the past, should become possible soon enough.) When no one can prove ownership, no one can mutate the permissions.
The ownership and permissions can be looked up by anybody, thus anybody can verify this independently.
The MaidSafe RFCs offer a lot of insight in the technicalities of the network. Just use the search on GitHub and you can find most of what you’re looking for:
Perfect. Thanks. Thanks for pointing me to those API docs. I was looking at these docs, which didn’t go into detail about what valid permissions are.
I suppose creating a “void key” would just be a matter of generating something that looks like a valid public key but has no known private key. And if you used a published algorithm with a meaningful seed, like a relevant famous quote, it would constitute proof that you don’t have the private key…
If that works, sure. I’m wondering if there’s a risk to everyone using the same void key, though? I can’t think of one off the top of my head, admittedly.
If everyone used the same (public) void key then the incentive to find the private key increases as the number of people who use the same key. Yes I know the sun will go dark before then, but.
The but is that if by some quirk of statistical remoteness that the private key is found then all those supposedly secured MDs are no longer secured.
Whereas if everyone used a different (void) key then the incentive to look for a private key is very much diminished and even if one is found then its only one MD that is compromised.
What I was thinking was that “locked-out” Objects would gain a reputation for unsavory content that can’t be deleted, and the powers that be would pressure the community to update the software so it doesn’t recognize them. If everyone’s using the same one, it’ll be a simple matter to tell the client to ignore those Objects.
But, come to think of it, I’m not sure why they would wage war against void keys specifically when you can do the same things with an active key, especially if the keyholder is unknown or deceased. Probably just thinking too hard.
Why would I trust anyone telling me it doesn’t have a priv key if it’s a valid public key? unless I missunderstand what you meant by “it looks like a valid pub key”.
It seems that what @happybeing suggests is better so you can be sure it doesn’t have a priv key