Sven Slootweg (soft-deprecated) @joepie91@pixie.town

@evelyn@misskey.bubbletea.dev Yeah, the mismanagement of npm was definitely a big factor in it all. Not everybody at npm were twitter liberals, but many of the vocal policy-deciding folks definitely seemed to be, and had no real understanding of the implications of their decisions.

@emilis I think that's only half the problem, though - it wasn't *just* an Eternal September-style overrun. There also just genuinely wasn't much documentation on the culture, nor structure to it! The only reason I learned about this at all, was because I literally met one of the early adopters (substack) at a tiny "revolutionary tech" conference.

So I feel like this *could* maybe have been prevented, if there was enough of an established and *documented* culture, instead of relying on word-of-mouth via two dozen early adopters - that probably would also have prevented the hype cycle, though, but that'd probably be a good thing really.

@IceWolf I'm not optimistic, unfortunately. The thing is that the problem extends beyond just npm - the collaborative, consensus-based culture has rotted away at every level (despite attempts for several years to change that), including the language core team itself. It's incredibly difficult to wrest away that control from a now-established hierarchical power structure, especially one this big and influential.

I still tried to work on changing it for many years because of the large existing ecosystem, the large public commons to save - but that public commons has been rapidly falling apart over the past several years, and I now feel like it's gotten so bad that it's genuinely easier to start from scratch with a new language + community that establishes the right culture upfront :/

On Twitter, the bias seems to be slightly different! An *even stronger* bias towards the third option, but the first option is no longer the least popular.

At least in the 'a' poll, they have hidden nbsp's; Mastodon wouldn't let me toot identical options :)

@welshpixie Yep!

@welshpixie

Room IDs are purely a (permanent) identifier, they have the original server's domain added to it to avoid naming conflicts, but because rooms are decentralized and don't exist on a specific server, a client can't just take that domain and run with it - the server might not exist anymore even if the room still does.

Room aliases *can* be used because you can have multiple of them (on different domains!) pointing at the same room ID, and while a room alias will stop working when the server in question goes down, that won't affect the room *itself*, which will work fine. It's only relevant for being able to join.

matrix.to links include both the room ID and *multiple* servers that are in that room, making it more likely that after a long time, the link will still work to join the room, because at least one of the servers in the link will still be alive.

Ultimately all this is just about *joining* a room; once you've joined, your homeserver is federating with the room, and it will continue working forever, no matter what happens to any other server.

@welshpixie That won't work, unfortunately - it's just a room ID, which (despite appearances) doesn't tell you what server to talk to to join it.

There are roughly two ways to share a Matrix room:
1. Sharing a room alias, which can be created in the room settings, and starts with #
2. Share a matrix.to link, usually your client will have a 'share' button to get one

Can't help but feel like there's some positional bias in the polls...

@riley@toot.site I imagine that that might be why :p

What it used to be:
- many early adopters were anarchists/communists/etc.
- a huge public commons of highly reusable, high-quality, collaboratively developed libraries on npm, built for the benefit of the public, not for profit
- high degree of interoperability between different people's work, no need for pointless busywork to redo the same work over and over again
- successful(!) 'community specs' designed through community consensus (Promises/A+, CommonJS, etc.), gaining near-universal adoption
- fundamentally different structures from other language ecosystems, both technical and social, to make this work

What went wrong:
- large influx of users from other ecosystems due to hype in startup circles, unfamiliar with the established practices and reasons why
- early adopters failed to effectively convey and explain the ideological basis
- corporate adoption and subsequent capture; increasing "business value", leading to corporate steering of many essential pieces of the ecosystem (language spec, Node.js, etc.)
- npm became npm inc., a for-profit corporation, eventually being acquired by Github due to its large userbase, placing control over the public commons and its namespace in private hands
- ideological basis was forgotten, early adopters eventually left for greener pastures, now an almost purely parasitic environment of people leeching off the commons without guarding its integrity or health
- community-consensus specs started being replaced by "official", by-decree-from-up-high language specs (CommonJS -> ESM, Promises/A+ -> ES Promises)
- widespread adoption of these "official" specs, even though they were in many ways worse, due to their "official" label and many people assuming that what a central authority says must be correct or better
- rapid increase in shiny, well-marketed new tooling that is not interoperable with the existing ecosystem at all, and frequently works less well
- more and more commercial/proprietary 'sidecar' services (eg. Snyk) that you are expected to use, sometimes replacing open initiatives
- now an ecosystem and public commons that is rotting in every aspect with no real hope for recovery

... we should probably learn from this?

@bram_dingelstad Probably worth trying that first, would probably be simpler to implement :) Though I wonder whether it'd survive any transcoding process

@bram_dingelstad I don't recall any of the specific algorithms unfortunately, but a quick search turned up this one which seems promising at a glance: https://www.iasj.net/iasj/download/cac16130d9ed9c32

@bram_dingelstad AFAIK there are watermarking systems which survive encoding and compression! Precisely to prevent stripping out the watermark. And it'd be kind of poetic to straight-up use a sharing-prevention mechanism for sharing stuff :)

@bram_dingelstad How about encoding it into the video data itself, like how 'invisible watermarks' work?