like, oops! imagine if IBM bought NPM and suddenly the javascript ecosystem's backbone became enterprise-only. that's critical infrastructure! the thoroughfare that connects us has VCs in the wings waiting to call in their favors.

if you're thinking of starting a business, like you've got some startup-worthy IP, start a cooperative instead! marshal resources directly from users, contributors, and supporters. it'll be slower going than pulling a million-dollar A round, but you won't have creepy vultures expecting you to flip everything you've made for a buck.

NPM learned from PyPI and Gem and ultimately produced a solid and relatively open system for aggregating and distributing packages. it's not hard to set up your own registry, for example, or to mirror subsets of the primary registry for offline access. these are important milestones! and someday they will outgrow NPM.

but even they're running into issues. a global namespace for packages has caused commons problems over and over, often with disastrous consequences.

we can learn from these issues -- the problems they've faced legally, in selecting and scaling infra, in moderating a commons -- to produce something better. there are a number of P2P-based package manager demos like `gx` for IPFS which show how to map an NPM-like experience to a distributed P2P architecture. we can iterate from this infra to something even more robust.

NPM has learned the hard way that namespacing packages to users avoids the commons problems AND typo attacks (where a malicious package is named similarly to a popular package). ultimately the very existence of a global namespace requires a central authority to moderate it. replacing the commons created by that authority with a commons of infrastructure (ex: the torrent trackers used by Dat) categorically eliminates these problems.

@inmysocks i have been thinking about it from an architectural perspective, and i'm familiar with most of NPM's infra stack, such that given enough time I could produce a Dat-backed NPM-like package manager and tooling to support such an ecosystem. by namespacing packages to keypair identities, we skip the commons problems that NPM has to moderate.

@garbados@inmysocks I’m thinking about this, and it seems like there’s still that other dimension of trust and governance. How do we minimize risk for users in a distributed system? I’m wondering if there are different needs when it comes to code infrastructure vs personal data. But I might be digging into the npm stuff a little more next week, would like to get a better sense of how this all works with the existing tooling.

@audrey@garbados I think that the trust and risk part is mostly a cultural thing and I have no idea how to solve the problem of trust. But from a tech standpoint git already has some distributed trust built in with the hashes. I think that something similar would work.

Trust in signing releases is one of the very few times when something like keybase.io makes sense to me.

@audrey@garbados I think that a web of trust type system may work here. You find people who you trust to audit code, they say that code is good or not and who they trust and you can get a distributed consensus about if a signing key is trustworthy or not.

@inmysocks@audrey observing public dependency trees can go a long way to generating implicit trust webs -- projects with many dependents can be considered trusted to some degree, in that the projects you trust apparently trust them. this skips any hassle of manually setting up the trust web.

@garbados@inmysocks And that loops us back to the initial topic, which is that it’s not just the size of the depended-on project, but also its financing and governance that sways us (not heckling, I think this is all really interesting)

@audrey@garbados unfortunately the social aspects of this are much more complex and harder to handle than the technical side.I don't know how to proceed with it other than to make the system and try it out.

@inmysocks@audrey@garbados yeah, it's one of its usecases, but there are other options to solve the same problem. Like organisations that own the servers and are backed by people... like NPM but not being a company. I don't really like to trust anyone but unlike bitcoin people I understand *sometimes you have to*, and that's not necessarily bad.

I and some comrades did this in Portland circa 2003. After reading the relevant parts of the Oregon Statutes we decided to incorporate as a non-profit. Non-profit because any surplus above expenses would go to higher wages/bonuses, reinvested in the coop, or savings. None went to an "owner" for being an owner. Our custom-written articles of incorporation we got legal opinion that they were compliant.

@aral@garbados@indie In my case I started ElenQ as an autonomous worker (i don't really know the term in english) so I'm the company itself. The real name of the company is Ekaitz Zarraga.That's cool because nobody can buy me (still)... and in the future I can change to be a coop and stay pure.But also even if I could be bought (which is not the case anyway) all the tech done until the moment is free so anyone can fork me as a company (and I'd love to see that happening tbh).

@aral@garbados@indie Also, I don't really care about the way a company is registered, that's not really important. First, we need companies to have ethics.

I know many coops here that are not ethical at all and they are slaving people and firing them before 2 years to avoid having to make them part of the company. So, the formal shape of the company is not really important.

If companies have some ethics, they'll probably choose to be a real coop, or whatever it fits better their ethics.

@krozruch Cork. Ask your accountant/company formation org for a company limited by guarantee (there’s also info online about the structure). @laura can tell you who we’re using (we’re still in the process).

@aral@laura Thank you! Hoping to take a look at Cork and Galway sometime this year. My folk are both from the West of Ireland (Mayo & Donegal). I was born in Britain, have lived in Prague for years, and we're thinking of relocating to Ireland.

@garbados it's a little annoying because corpers *need* these things, badly. I can get along just fine with a local, non-replicated mirror, it's the people for whom minutes of downtime mean millions in losses that need this stuff, not me.

I don't even know what a good explanation for this phenomenon is. I'm happy to attribute it to managers who lack the knowledge and competence to understand these subjects but that's too comfortable an explanation to be the whole story.

@x64k isn't it? i blame the profit motive: execs want to distinguish their demoware to scam other execs into using it, only for their platform is disappear when funding runs out while they move on to the next startup. we cannot treat infrastructure like this! roads abandoned, bridges vaporized -- this is not the way!!

i think general users like us have use for ddb infra at scale, but more as p2p than classic client-server approaches.

@x64k google needs a robust ddb to handle youtube, but we need a robust ddb with even more constraints to support a federated youtube in order to re-govern that commons. that's where i think of a lot of the cool architectural problems live: building and tooling reimagined infrastructure that supports distributed governance.