intro
Hey everybody!
Lots has been happening in the nest.land community lately. We have a lot of exciting announcements to make in the next few days/weeks, so stay tuned!
The team wanted to write a short article addressing some concerns with the misuse of the word "immutable." This is an extremely common misconception by members of various development communities, and we feel that it must be appropriately addressed.
The recent release of a module registry and CDN is now using the term "immutable," while their data is in fact not immutable. That release is now blatantly and falsely demeaning the value of our service to others.
The dictionary definition presents this:
im·mu·ta·ble
/i(m)ˈmyo͞odəb(ə)l/
unchanging over time or unable to be changed.
immutable* vs immutable
We certainly agree with this definition, but it is quite vague for developers. In terms of data, there are two (very different) levels to this word.
- Immutability from a user standpoint (Immutable*)
- Immutability from a data standpoint (Immutable)
From a user standpoint, immutability refers to being unable to make edits to or take something down. In other words, once something is published or "pushed," a general user cannot make changes to that. An example of a general user is a module publisher.
From a data standpoint, immutability refers to never being able to modify or delete data after it is published somewhere. In other words, no entity (such as Amazon, GitHub, the registry, or module owner) has the ability to take data down after it becomes "immutable."
This second type of data immutability is something that only a blockchain can accomplish, as true decentralization must be in place.
examples
An example of an immutable* service lies with a registry and CDN whose data is served from a centralized source, such as Amazon or GitHub.
An example of a truly immutable service is nest.land, whose data is served straight from the blockweave.
comparison
Immutable*
- Data not editable or deletable by a general user once published
- General users are module publishers
- Data can be edited or taken down by the entity controlling the data
- In the case of an immutable* module registry, there are now two points of failure:
- The registry could choose to delete data
- Amazon could choose to delete data
- Data can be blocked in different regions or countries, as it is only accessible from a single source
Immutable
- Data not editable or removable by any entity, including nest.land and module owners/developers.
- Thanks to the blockweave, our data is securely distributed across 347 nodes run by different people and companies from around the world.
- For comparison, Amazon is "designed to sustain the concurrent loss of data in two facilities"
- Data can not be blocked in different regions or countries, as it is accessible from any Arweave gateway.
- Anybody can spin up an Arweave gateway.
Nest.land is also steadily making advancements towards registry immutability to match our CDN immutability. We're currently building Fossil, an automatic registry archiving service to publish the module gallery to Arweave.
Check it out here:
https://github.com/nestdotland/fossil
conclusion
There are two very different levels of the word "immutable." For something to be truly immutable, it must not be editable or deletable by any entity, ever.
Please share this post with others to raise awareness about nest.land and how we're here to help the Deno community with true module immutability.
Top comments (1)
I agree with the clarification of the concept of immutability since immutability is not absolute in all cases and this can create false security for those who use these services