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…
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.