Renaming ipfs implementations 2021/2022 edition about ipfs

[momack2]

Any update on the plans to rename the js-ipfs project @BigLep @achingbrain?

[BigLep]

Polls were created:
#471
#473

[BigLep]

For additional naming discussion we have:

1. https://airtable.com/app5roantDlNn9qeE/tblAac2zr6ouqv2lp/viwaNB3PirIVPorWH/reca3AijHgnclwB2K?blocks=hide
2. https://protocollabs.notion.site/IPFS-Naming-2222fd426482499187ede56fcadc11bf

[BigLep]

2022-01-05: this didn't get off the ground beyond setup during lab week 2021. Minor, but when it gets picked back up, it may worth moving this to discuss.ipfs.io rather than introducing GitHub Discussions. It's possible to get who liked a given post via the API: https://meta.discourse.org/t/getting-who-liked-a-post-from-the-api/103618/2

[BigLep]

For anyone watching, the "What is the scope here? Are we renaming binaries, repos, etc.?" section was updated to reflect the latest thoughts / proposal of the go-ipfs renaming effort. This is an attempt to be pragmatic about getting a name that we can start to refer to without committing to all the renaming work right now. We'd rather put the effort in to making it easier for other go IPFS implementations to spring up. A good example of such a project is ipfs/kubo#8543

[BigLep]

Renamed from "Renaming ipfs implementations 2021Q4 edition" to account for this work happening in 2022Q1.

[lidel]

go-ipfs renaming plan in ipfs/kubo#8959 (comment), will happen between v0.13 and v0.14

[BigLep]

Any update on the plans to rename the js-ipfs project @BigLep @achingbrain?

Plans for js-ipfs are covered here: https://blog.ipfs.tech/state-of-ipfs-in-js/

Per that blog entry, we are inviting the community to help name a to-be-created JS implementation. This will go live by EOD 2022-10-28 and is being tracked in ipfs/helia#3

[tinytb]

The name poll for the new implementation of IPFS in JavaScript is now live here:

• #495

[BigLep]

Also, to be clear, we are not collecting names for the current js-ipfs. We're only collecting names for the new IPFS-in-JS implementation with placeholder name "Pomegranate". As stated here, we’re currently not planning to rename the js-ipfs implementation like we did with Kubo given js-ipfs' limited lifespan. We'll pause js-ipfs maintenance once pomegrate is released. The community will be welcome to fork it, but the forking will be under a new name. js-ipfs in Github and npm will have clear deprecation notices pointing to Pomegranate (and other IPFS-in-JS implementations that emerge).

[lemanschik]

your allowed to call it web-modules
i will also integrate it.

eg web-module-fs as the web-modules standard gives the standard for everything that is not part of the old ipfs implementations

web-modules is like Inter Planetary Modules that includes a FS and has not your blockers as i have implementer support from the browser side and all Runtimes as also compilers backends and build systems.

[momack2]

@tinytb - is there an ETA on when we're going to "call it" in terms of a new name?

[tinytb]

@momack2 - ETA is next week! We decided we want an available npm package name, so we've reserved a few finalists (all of which were suggested in the Discussion); there are also a couple (abandoned but taken) names that we're interested in; we've sent emails to the current owners to ask if they'd be willing to give us the name. If we don't hear back from them soon, we'll go with one of the ones we've already reserved.

cc @achingbrain for visibility.

[momack2]

@lemanschik npm modules help a large slice of the community, so are a valid thing to take into account and definitely don't mean js modules won't be built with other tools. When making suggestions - please remember to frame your request in a positive and collaborative way (combative language hurts collaboration and finding common ground, and makes it harder to work together). Thank you!

[lemanschik]

@momack2 sorry when you feel attacked but you need consider that packaging with NPM is a aggressiv violation of the whole ECMAScript Ecosystem which is the browser.
browser i do not know if you know it and that has good reasons its not that no engineer in the chrome or google world could add it technical.

• browser do not support package.json loading via import
• browsers do not even support the same import map format exported by them via exports.
• overall browser do simply have nothing to do with NPM and so has ECMAScript ECMAScript has zero relations to the person who runs NPM which is isacss
• npm did block evolution of the web and every one since it exists
• npm made the creator of NodeJS leave and create deno

do you need more offensiv points about NPM vs ESM?

[lemanschik]

but its ok i my self have chosen to go closed source anyway all over now i understand why people like Torvalds say github is toxic.

[2color]

@BigLep Can we close this?