Immutability: Be careful saving on-chain

One was working on a project, and someone gave me feedback; and one realizes something that one taken for granted on the blockchain: immutability. One thought of creating something immutable, but one still have some control over non-intrusive decisions. For example, a blog. The blog is published on IPFS, but one can choose to unlink it from the site if it contains offensive information. Thing is, the feedback strikes my thought: if it is mutable, and have control over it, why build it on the blockchain? But what strikes one most is: if everything becomes blockchain in the future, how do we decide what information to be mutable online, and what immutable? I.e. what information do you want to store on centralized cloud services, where you can control your information to be deleted anytime; and what information to store on the blockchain/IPFS? (Centralized doesn't need to be hosted by a corporation: even self-hosting is considered centralized if you use your own database, your own server, so you have full control over your data).

Centralized Entity

When speaking of centralization, here are some dangers that occur if you don't have full control of the databases and servers (i.e. not self-hosting).

An entity can choose to betray your trust and leak what you store on their cloud. However, that doesn't occur very often, unless their central server got hacked. What's more often happens is user request to delete their data but centralized entity isn't deleting their data. In fact, they may just mark them as "deleted" and archive the data, without the user's knowledge; after all, you never know whether they actually delete your data or not when you request them to. They might choose to keep the data for future use, like training a Machine Learning model, or perhaps for data analysis; whatever brings them more profit. That's a drawback of centralized entity.

Immutable vs Mutable

With decentralized entities, user started to have full control of what they have. Additionally, user also takes up more responsibility than they used to. More power, more responsibility. Hence, more responsibility means more education required to facilitate users' decision; at least to let them know the consequences of their actions if they aren't aware of. For example, if they lost their passphrase to their wallet, nobody can help them recover; unlike centralized entity where you have a password-recovery system to reset your password. What we will discuss today on the immutability and mutability of user's data stored online. That is, how do we educate users so they take responsibility on whether their data stored online to make it mutable or immutable?

Let's start off explaining what one means by mutable and immutable data, in case you got confused.

In computer programming, a mutable data is something that could be edited after first created, so you can Create, Read, Update (aka edit), and Delete (CRUD) the data. In contrast, an immutable data can only Create, Read, and Delete (so write once read many). It cannot be edited after first written; to edit, you copy/clone it, then edit it offline, then create a new one and update it. You can't edit the created object directly.

Here, we have a slightly different explanations on mutable and immutable data storage.

Mutable: An uploaded data that you can Create, Read, Update, and Delete (CRUD). You have full control of these 4 operations. (irregardless of what actually happens to centralized entity problem we discuss before).

Immutable: An uploaded data that you first Create offline, then after uploaded, you can only Read. You cannot edit the data, NOR DELETE THE DATA. The important thing lies in "unable to delete data". What's on there is on there forever; no regret!

Consider why blockchain is created in the first place -- to have a decentralized entity so nobody can have monopoly on controlling what is stored/hosted online. Voting is required, and to pull it down entirely, all parties need to agree to pull it down. Even if one party left disagreed, it'll still be on. This expands to storing real history online, such as WikiLeaks, ensuring no one can alter real history to what they want, either via blackmailing the wiki creator, or via other forces. If the creator themselves can't update the data nor delete the data, it's solid. Sue-ing, going to court, blackmailing, or other means of forcing the creator will hurt the creator's heart, but he/she can't do anything to what is published, it lays rock solid, (hopefully) forever.

What to save on-chain?

The choice of saving on-chain not only leaves to the users, but dApps developers too! For a dApp, developers are making the choice for users, hence taking partial responsibility from users to make the decisions for them. (The other partial responsibility lies in the users, after the developer warns the users where the dApp saves its data and the user agrees on the agreement.) Developers shall decide during development, what are to save on-chain and what nots.

Some considerations includes:

• Would you like the data to be permanent?

• Would you like the data to be editable and/or deletable?

• How sensitive are the data (privacy)?

• and others.

Remember, data saved on-chain cannot be overwrite. You can create a new copy and re-link to that new copy, but the old copy remains on-chain, and there's a permanent address to access that information if someone saves it (in IPFS, this is the CID; in NEAR, this is the NEAR Explorer; and Ethereum, BCH, etc have their own equivalent explorer to fetch information).

Some other good practices

It makes sense to first save a local copy of whatever you want to upload. Don't immediately upload to IPFS or on-chain. Go to sleep, make sure you have enough time to think through it. Sometimes, just forget about it temporarily and in a few days, if you keep coming back to it, your feelings tell you that you can upload it on-chain, and you don't regret at it (at least for now), then go ahead with it.

If you think you will regret it in the future, even the slightest, then don't upload it as immutable; keep it mutable. As long as it's mutable, you can always make a choice to make it immutable when you need it to.

Conclusion

In conclusion, it's vital for professionals to create teaching materials to raise awareness among users, be it end-users or developers, to be responsible for their decisions. As users have more power hence responsibility for their own data, their actions are of serious considerations, as there are no regret medicines to eat (a Chinese proverb, lol)! If the user makes the wrong choice, that's it, GG!

As for developers, they should announce clearly to end-users how their data will be stored and warn them multiple times, even if it's annoying, especially when actions are irreversible. If the developers are making the choice for end-users, they should be responsible for making it clear. Also, it makes sense to let the user choose whether or not to store their data immutably. Of course, for other users that just ignore developers' warning and later regret, developers are welcome to ignore their requests if most people have no problem seeing the warnings clearly; they're the ones that just want to find problems and refuse to take responsibility for their own acts and can be safely ignored.

Remember to Like and Subscribe if you like my posts.