
Nest.land – An immutable, blockchain powered module registry for Deno - undefined_void
https://nest.land
======
buttercubz
Having a package registry has its advantages and disadvantages (npm) but
nest.land is trying to make the best of both sides, a very common complaint
with deno is that it does not have a package manager or official registry. The
nest.land team took as a axis to use blockchain as a central technology, which
in my opinion is a serious decision, since problems such as left-pad would no
longer occur since the packages are immutable, in the case of packages they
have a system package reporting which mitigates malicious packages very well.

regarding whether or not deno should handle packages with url is a dividing
issue, first of all deno does not try to be a direct successor of nodejs, it
tries to be compatible with the browser, in the browser it is imported using
directly url, some solutions are, use a deps.ts file and have all the import
there, use import maps and maybe manage them using Trex, in order to change
the paradigm is crucial to move forward, many when nodejs was presented did
not like the idea of server-side javascript, Today the nodejs ecosystem is one
of the most important in the industry

------
verdverm
Because we definitely don't want to remove malicious packages as the software
supply chain finds itself under increasing attacks

~~~
undefined_void
You might want to take a look at this before commenting randomly on someone
else's hardwork. [https://docs.nest.land/#what-are-the-benefits-of-nest-
land](https://docs.nest.land/#what-are-the-benefits-of-nest-land)

What find themselves under increasing attack are developers and their
projects.

~~~
verdverm
Hmm, none of these things are what I look for in a dependency management
system. Blockchain is not the solution to much of anything

~~~
tatef
We aren't a package manager. We're a registry and CDN (of sorts). Blockchain
is actually a huge solution to this problem for three very notable reasons.
The first is that Deno module imports are url based, and we don't want code
going off the internet, as this would break the code dependent on it.
Blockchain solves this because transactions (module code) are unable to be
modified or deleted. This means that import links will never break, thanks to
blockchain! In addition, it's unbelievably cheap to permanently store data.
For reference, we've stored 17,297 files on the blockchain. For proof, you can
see our wallet address and transaction history here:
[https://viewblock.io/arweave/address/tySYSW93nDky1sbCO56PmyE...](https://viewblock.io/arweave/address/tySYSW93nDky1sbCO56PmyEyspbyYx7x9ZXMNueKOOg)
This permanent and decentralized data storage has cost us right around 5 cents
USD. Thirdly, thanks to the blockchain, the module data is completely
decentralized across over 340 nodes and counting around the world. You can see
the exact statistic here:
[https://viewblock.io/arweave](https://viewblock.io/arweave) Again, thanks for
bringing these things up. These are great points for us to address publicly.

~~~
verdverm
You might take a look at how Go implemented their module system and solves the
above without blockchain or a lockfile. Simple algo, excellent engineering,
built in security and integrity checking.

In the end, you will want to mirror all external dependencies (repos, git,
pkg) into your own cloud.

So Demo has us specify versions at the point of import, in how many files? Is
this lunacy?

I store more files on GitHub for free, how can blockchain be cheaper than
that?

