Decentralized-Internet: an npm umbrella package for peer to peer builds

An umbrella package rather than a single library

Decentralized-Internet does not implement a peer to peer protocol by itself. It packages together a set of existing projects under one npm name, and the README is explicit about the composition: the npm library is a collection of repos made for the purpose of building decentralized web projects, namely lotion, bitcoin-peg, clusterpost, gridbee-framework and Reinvent-the-Internet.

That distinction decides what a reader is actually looking at. The top level repository carries directories for those pieces (clusterpost, Reinvent-the-Internet, LNRChain, packages, app, ui-dashboard) alongside config and deployment descriptors for a startling range of platforms: Pulumi.yaml, app.json, azuredeploy.json, deploy.json, snapcraft.yaml, mason.json, bower.json, pubspec.yaml, Project.toml, Cargo.toml and dub.sdl. The repository is a monorepo of packaging formats rather than a single code path, and the npm artifact is the part the README points at as the main distribution method.

The purpose behind it is stated in plain terms: to support a new internet that is more open, free and censorship-resistant, one that would not rely on telecom towers or an outdated grid, with peer to peer compatibility and grid computing as the two load bearing ideas. The intended user is a developer building a dapp or a distributed service who wants the plumbing assembled rather than assembled by hand.

A Rust core with a JavaScript face and several other language surfaces

The package on npm is named decentralized-internet and its manifest version is 5.4.3, while the Rust crate in the same repository carries version 0.2.2 and a different description, a library to create decentralized and grid computing applications via Rust. Two published packages, two version lines, one repository. Anyone tracking releases by version number will get confused, and it is worth knowing before you install anything.

The Rust side leans on parallelism and async work. Its dependency list includes rayon for parallel processing, tokio and futures for asynchronous execution, num_cpus, chrono and time for scheduling, rand, env_logger, process_lock and streaming-harness for run control, and a set of fs, io, env and thread crates. The npm side leans on the same ideas expressed as services: pm2 is a runtime dependency, so the package is designed to keep processes running alongside websocket-stream for live connections, async for control flow, and bitcoin-protocol and bitcoin-util for peer to peer work.

The other language surfaces are visible in the file list. Project.toml and a .julia-configs directory point at a Julia component, pubspec.yaml at a Dart or Flutter component, mason.json at the Mason package format, plugin.xml at a Cordova plugin, and .meteor-configs and .theia directories at further toolchains. The repository also carries Gruntfile.js, a .travis.yml file, a .gitpod.yml and a .gitpod.Dockerfile, so the project was set up to be opened in a browser based workspace. All of that is scaffolding for many distribution targets rather than one library with one API.

What installing the package actually pulls in

There is no install command in the README, and the documentation for installation lives on a separate readthedocs site, with the README linking to the Critical Components and Main Installation Methods pages under the Decentralized Internet Docs. What the repository does give you is the dependency set the npm package declares, which is the part worth reading before you install anything into a product:

  "dependencies": {
    "pm2": "7.0.4",
    "async": "3.2.6",
    "coins": "^4.5.0",
    "lotion": "^0.4.26",
    "tendermint": "^5.0.2",
    "bitcoin-util": "^2.0.0",
    "websocket-stream": "^5.5.2",
    "ember-cli-babel": "8.3.2",
    "bitcoin-protocol": "^4.0.1",
    "ember-cli-htmlbars": "7.0.1",
    "@jupyterlab/notebook": "4.6.4",
    "snyk": "1.1302.1"
  },

That list is the single most important fact in this project for an engineer. A package whose runtime dependencies include ember-cli-babel, ember-cli-htmlbars, @jupyterlab/notebook and snyk is not a lean client library: it drags an Ember build toolchain and a notebook environment into your dependency tree, along with a security scanning tool, every time it installs. If your application is a small dapp, this is a large footprint to carry for what the README calls an SDK.

Other distribution paths exist for people who do not want the npm route. The README links a Mac disk image release for Mac users, a Sketch plugin, a Gitpod ready to code workspace, and a Bitbucket mirror of the repository. The package is funded through opencollective and the homepage field points to a bit.ly link for the Lonero operating system project.

The stated capabilities and the stated ambition

The features list says the library can currently be used to build an offline centered network, set up your own blockchain infrastructure, set up services and micro-applications running on parallel processing instances, and create a cryptocurrency sidechain utilizing Lotion or Tendermint consensus protocols.

Set against that, the What section of the README describes the current goal in progress terms: the team is trying to make a pipeline for a peer to peer data transfer and syndication protocol. That is a candid sentence, and it is the one to keep in mind. The capability list describes what the assembled components can do once you have wired them, while the pipeline the project wants to exist does not yet exist as a finished protocol. A team building on this is building on a toolbox, not on a finished stack.

The whitepapers referenced from the README point the same way. The Lonero Whitepaper and the CrowdCoin Scientific Whitepaper are listed as papers worth checking out, and the repository contains paper.md and paper.bib alongside LNRChain, which suggests a research and whitepaper driven project with a chain implementation in progress. The stated ambition is an internet that eventually would not rely on telecom towers, an outdated grid or old school forms of technology. Whether a specific dapp needs that ambition or just needs a working client is the question to answer first.

Release dates and version drift are the practical risk

The repository is not archived and the last push was on 2026-10-20, so work is still landing in the tree. The tagged releases tell a different story. The most recent release entries are v1.0_mac on 2020-03-03, v1.0_skpm on 2020-03-02 and 4.2.3 on 2020-02-20, while the npm manifest reports version 5.4.3 and the README points to a Git release package tagged v3.6.9. Four different version identifiers for the same project is not a small inconsistency; it means there is no single answer to what the current version is.

The npm manifest lists the licence as zlib or MIT, while the Cargo manifest says MIT and the repository carries both LICENSE and LICENSE-MIT files. For a library you intend to embed in a product, the dual licence expression needs to be resolved against the files you actually receive, and that is a question for the maintainers rather than something the repository answers.

The README itself carries a maintenance note, admitting that seed migration may need updates in some of the organisation repos. Seed migration matters for a peer to peer network because it decides how peers bootstrap their view of the data, so an admission that this layer needs work is a statement about the weakest part of the stack. The documentation is hosted on readthedocs under the lonero project, and the repository also carries a SECURITY.md, which indicates a process exists but not what its guarantees are.

Depending on Lotion or Tendermint directly is the honest alternative

Because the npm package is a wrapper, the obvious alternative is to skip the wrapper. The dependencies list shows that lotion is pinned at ^0.4.26 and tendermint at ^5.0.2, so those two libraries are reachable directly, and using them directly gives a materially different setup. You would depend on a consensus client without the umbrella's process management, without pm2 as a runtime requirement, and without the Ember and JupyterLab dependencies arriving in your tree. The trade-off runs the other way too: the umbrella exists precisely to assemble the parts, so going direct means you write the wiring between the consensus client, the parallel processing pieces and the peer to peer transport yourself.

A second alternative is to skip the blockchain framing entirely and use the grid computing component, clusterpost, for distributed processing on its own. The README lists clusterpost and gridbee-framework as members of the collection, and the features list mentions services and micro-applications running on parallel processing instances, which is a distributed compute problem rather than a consensus problem. If the real requirement is running work across machines and the chain is incidental, the smaller dependency is the right one.

Either way, the decision comes down to whether you want the assembly or the components. This package is a convenience layer over a set of repos, so its value is in the wiring, and its cost is that you inherit all of the wiring's dependencies and version ambiguity.

Editorial conclusion

Adopt Decentralized-Internet if you want a single JavaScript entry point that already wires a Lotion or Tendermint client, a process manager and the clusterpost style parallel processing pieces, and if you are comfortable with a package whose npm version and crate version have drifted apart and whose last tagged release predates its most recent push. Do not adopt it for a production blockchain, for a protocol you need to reason about precisely, or if you need a library with a tracked release cadence, because the npm package pulls in Ember CLI build tooling, JupyterLab and pm2 as runtime dependencies. Verify first what your own project actually needs from lotion and tendermint by reading their entry points directly, then run the readthedocs installation page for this project against a throwaway workspace before copying any of it into a product.

Frequently asked questions

Official sources

1. License: MIT
2. Lonero-Team/Decentralized-Internet on GitHub
3. Project website
4. README
5. Releases