From what I've understood, the idea behind Entropic is for packages to be distributed across many instances (each acting like a separate registry). To me, this sounds similar to how Mastodon tries to be a decentralized version of Twitter.
I think it's a very interesting idea. The "commons" of JavaScript should definitely be owned by the community, and having many instances sharing the load of running and serving packages sounds like a fairly sound idea.
But I also wonder:
Who will run Entropic instances? As an individual, I don't see any incentives to run an instance myself, unless this is made very easy and transparent (like a daemon running on my PC with low energy usage).
Is there any risk of an Entropic instance ended up as the "go-to", meaning going back to a centralized model?
I also think this is quite new, so it'd be a fair bit of experimentation and validation. Does anyone know of an existing (and successful) federated package registry model?
So I don't know if this counts as "federated", per se, but Perl's CPAN has had a bunch of mirrors for a very long time. Many companies who used Perl back in the day would mirror CPAN as a way of giving back to the community, and using a program called minicpan, it was (and still is) easy to set up a mirror locally on your own harddrive. I've found this useful in the past for speeding up installs, browsing documentation for modules I don't have installed on an airplane, etc.
Of course, that's only one part of it - publishing a module still needed to happen through a service called PAUSE. However, you can add whatever modules you want without PAUSE - private or otherwise - to a CPAN mirror you maintain; all you need to do is make sure your CPAN installer is pointed at the right mirror.
Who will run Entropic instances? As an individual, I don't see any incentives to run an instance myself, unless this is made very easy and transparent (like a daemon running on my PC with low energy usage).
Institutions, foundations, companies. The important thing is that one could switch on a moments notice.
Is there any risk of an Entropic instance ended up as the "go-to", meaning going back to a centralized model?
Yeah, there's always going to be a few "go to" servers, especially if they have a faster CDN. The trick is to make it transparent to the user. Even a public log where all the mirrors and modules are that a tool can parse and adjust at runtime it's a good start
It's pronounced Diane. I do data architecture, operations, and backend development. In my spare time I maintain Massive.js, a data mapper for Node.js and PostgreSQL.
I think Java's Maven offers an interesting model: the biggest public registry/repository is maintained by Sonatype, which afaik is also a private company, if an older and stabler one than npm. However, the Maven POM format makes including other and multiple registries extremely simple and there's no shortage of mirrors. Node package.json files don't allow for this: you're locked into one registry at a time. I got started with Node a year or two after npm became the dominant registry but I've often wondered how and why that turned out the way it did.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
From what I've understood, the idea behind Entropic is for packages to be distributed across many instances (each acting like a separate registry). To me, this sounds similar to how Mastodon tries to be a decentralized version of Twitter.
I think it's a very interesting idea. The "commons" of JavaScript should definitely be owned by the community, and having many instances sharing the load of running and serving packages sounds like a fairly sound idea.
But I also wonder:
I also think this is quite new, so it'd be a fair bit of experimentation and validation. Does anyone know of an existing (and successful) federated package registry model?
So I don't know if this counts as "federated", per se, but Perl's CPAN has had a bunch of mirrors for a very long time. Many companies who used Perl back in the day would mirror CPAN as a way of giving back to the community, and using a program called
minicpan, it was (and still is) easy to set up a mirror locally on your own harddrive. I've found this useful in the past for speeding up installs, browsing documentation for modules I don't have installed on an airplane, etc.Of course, that's only one part of it - publishing a module still needed to happen through a service called PAUSE. However, you can add whatever modules you want without PAUSE - private or otherwise - to a CPAN mirror you maintain; all you need to do is make sure your CPAN installer is pointed at the right mirror.
Institutions, foundations, companies. The important thing is that one could switch on a moments notice.
Yeah, there's always going to be a few "go to" servers, especially if they have a faster CDN. The trick is to make it transparent to the user. Even a public log where all the mirrors and modules are that a tool can parse and adjust at runtime it's a good start
I think Java's Maven offers an interesting model: the biggest public registry/repository is maintained by Sonatype, which afaik is also a private company, if an older and stabler one than npm. However, the Maven POM format makes including other and multiple registries extremely simple and there's no shortage of mirrors. Node package.json files don't allow for this: you're locked into one registry at a time. I got started with Node a year or two after npm became the dominant registry but I've often wondered how and why that turned out the way it did.