You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 12, 2024. It is now read-only.
Ever worked on an application where you've had to write a database migration? Yeah, us too. Up until now js-ipfs hasn't been able to migrate repo's to a new format. Well, that's not strictly true, you could have used the go-ipfs repo migration tool on a repo created when running js-ipfs in Node.js (yes, we have repo compatibility!), but in the browser you were stuck.
..and I mean really stuck, if we'd updated the format of a repo that ships with js-ipfs then your applications would just have to catch an error that the repo version was not compatible. You couldn't use it, and you couldn't upgrade. Bad news bears 🐻.
We had a cunning strategy to avoid this situation - do not change the repo 😂, but this is rapidly becoming unsustainable since we actually want to add a migration to achieve our dream of base32 encoded v1 (by default) CIDs.
Good news friends! The new version of js-ipfs now ships with a repo migration tool that'll automatically migrate repo's in the browser. So now all our ducks are in a line, stay tuned for a migration and a switch to v1 CIDs ✨!
🎻 base32 encoded CIDs in IPNS paths
My violin strings gently weep for being able to use Peer IDs in a domain, and let me tell you why.
Peer IDs currently cannot be used in a domain name because their string format is base58 - a case SENSITIVE encoding. In domain names the following are equivalent:
...but wait, Peer IDs ARE CIDs! I know, weird, but also rad because in theory we should be able to re-encode them as base32. Right now though, everything expects a base58 encoded string (a v0 CID) because they're actually just a multihash.
In this js-ipfs release we've made a small change to allow you to take your Peer ID (a v0 CID), convert it to a base32 encoded v1 CID and use it in an IPNS path like /ipns/bafybeidta3hkxk3ihxfsk765oswgsjhmvcnkeestyuov6r2t5tyts4xuoe. Here's how you might do the conversion:
jsipfs id | json id | jsipfs cid base32
bafybeidta3hkxk3ihxfsk765oswgsjhmvcnkeestyuov6r2t5tyts4xuoe
This is really, seriously cool, because now Peer IDs can be used in domain names and so an IPFS gateway operating at bafybeidta3hkxk3ihxfsk765oswgsjhmvcnkeestyuov6r2t5tyts4xuoe.ipns.dweb.link for example, will have origin isolation (hooray for security 🔒) AND IPNS enabled mutable data 🚀⚡️
In the future, new Peer IDs will be v1 CIDs with a libp2p-key codec that is base32 encoded by default...but that's a change for another day.
🌲 Implemented dag put and dag resolve CLI commands
These have been available in core for a while now and we finally got round to surfacing them in the CLI. e.g.
$ jsipfs dag put '""IPLD RULEZ""'bafyreia5coklfzblgd3reqwaieafmpasdceqmcnjrowre3623mtb4nxlhm
$ jsipfs dag put '{"to": {"/": "bafyreia5coklfzblgd3reqwaieafmpasdceqmcnjrowre3623mtb4nxlhm"}}'bafyreiequnkfflujkwhxk6wud5w64hmijdqdmx7p55fgrbiizw32kdrb7e
$ jsipfs dag put '{"path": {"/": "bafyreiequnkfflujkwhxk6wud5w64hmijdqdmx7p55fgrbiizw32kdrb7e"}}'bafyreidgfdsoupe747qnjzkjk2yirgv76wr4drev3i7kv6dht4dkypusze
$ jsipfs dag resolve bafyreidgfdsoupe747qnjzkjk2yirgv76wr4drev3i7kv6dht4dkypusze/path/tobafyreia5coklfzblgd3reqwaieafmpasdceqmcnjrowre3623mtb4nxlhm
$ jsipfs dag get bafyreia5coklfzblgd3reqwaieafmpasdceqmcnjrowre3623mtb4nxlhmIPLD RULEZ
🏗 API Changes
dag.put got a pin option to save you from calling the pin API separately (and potentially losing your node if GC runs inbetween!)
✅ Release Checklist
Stage 0 - Automated Testing
Feature freeze. If any "non-trivial" changes (see the footnotes of docs/releases.md for a definition) get added to the release, uncheck all the checkboxes and return to this stage.
Automated Testing (already tested in CI) - Ensure that all tests are passing, this includes:
unit/functional/integration/e2e
interop
sharness (Does not run js-ipfs)
all the examples run without problems
IPFS application testing
webui (Does not depend on js-ipfs or js-ipfs-http-client)
ipfs-desktop (Does not depend on js-ipfs or js-ipfs-http-client)
# All succesful builds of master update the `build/last-successful branch which# contains a npm-shrinkwrap.json.# This command checks that branch out, installs it's dependencies using `npm ci`,# creates a release branch (e.g. release/v0.40.x), updates the minor prerelease# version (e.g. 0.39.1 -> 0.40.0-rc.0) and publishes it to npm
npx aegir publish-rc
# Later we may wish to update the rc. First cherry-picked/otherwise merged the# new commits into the release branch on github (e.g. not locally) and wait# for CI to pass. First update the lockfiles used by ci (n.b. one day this# will be done by our ci tools):
npx aegir update-release-branch-lockfiles release/v0.40.x
# Then update the rc publisehd on npm. This command pulls the specified release# branch, installs it's dependencies `npm ci`, increments the prerelease version# (e.g. 0.40.0-rc.0 -> 0.40.0-rc.1) and publishes it to npm
npx aegir update-rc release/v0.40.x
Network Testing:
test lab things - TBD
Infrastructure Testing:
TBD
Stage 2 - Community Dev Testing
Reach out to the IPFS early testers listed in docs/EARLY_TESTERS.md for testing this release (check when no more problems have been reported). If you'd like to be added to this list, please file a PR.
Take a snapshot of everyone that has contributed to this release (including its direct dependencies in IPFS, libp2p, IPLD and multiformats) using the js-ipfs-contributors module.
Publish to npm:
git checkout release/v0.34.x
# Re-install dependencies using lockfile (will automatically remove your# node_modules folder) (Ensures the versions used for the browser build are the# same that have been verified by CI)
npm ci
# lint, build, test, tag, publish
npm run release-minor
# reintegrate release branch into master
git rm npm-shrinkwrap.json yarn.lock
git commit -m 'chore: removed lock files'
git checkout master
git merge release/v0.34.x
git push
Publish a blog post to github.com/ipfs/blog (at minimum, a c&p of this release issue with all the highlights, API changes and thank yous)
The best place to ask your questions about IPFS, how it works and what you can do with it is at discuss.ipfs.io. We are also available at the #ipfs channel on Freenode.
The text was updated successfully, but these errors were encountered:
⚡️ 0.40.0-rc.1 is out now with fixes to the CID tool to allow piping newline delimited data to it (like in the example in the release notes) multiformats/js-cid-tool#8 and fixes to the new DAG CLI commands allowing them to support {"/": "<CID>"} style links (like in the example in the release notes) #2631.
🗺 What's left for release
dag put
anddag resolve
cli commandsfeat: Migration of Blockstore to use multihash instead of CID as key🚢 Estimated shipping date
2nd December
🔦 Highlights
🦆 New repo migrations tool
Ever worked on an application where you've had to write a database migration? Yeah, us too. Up until now js-ipfs hasn't been able to migrate repo's to a new format. Well, that's not strictly true, you could have used the go-ipfs repo migration tool on a repo created when running js-ipfs in Node.js (yes, we have repo compatibility!), but in the browser you were stuck.
..and I mean really stuck, if we'd updated the format of a repo that ships with js-ipfs then your applications would just have to catch an error that the repo version was not compatible. You couldn't use it, and you couldn't upgrade. Bad news bears 🐻.
We had a cunning strategy to avoid this situation - do not change the repo 😂, but this is rapidly becoming unsustainable since we actually want to add a migration to achieve our dream of base32 encoded v1 (by default) CIDs.
Good news friends! The new version of js-ipfs now ships with a repo migration tool that'll automatically migrate repo's in the browser. So now all our ducks are in a line, stay tuned for a migration and a switch to v1 CIDs ✨!
🎻 base32 encoded CIDs in IPNS paths
My violin strings gently weep for being able to use Peer IDs in a domain, and let me tell you why.
Peer IDs currently cannot be used in a domain name because their string format is
base58
- a case SENSITIVE encoding. In domain names the following are equivalent:So, bad times.
...but wait, Peer IDs ARE CIDs! I know, weird, but also rad because in theory we should be able to re-encode them as
base32
. Right now though, everything expects abase58
encoded string (a v0 CID) because they're actually just a multihash.In this js-ipfs release we've made a small change to allow you to take your Peer ID (a v0 CID), convert it to a base32 encoded v1 CID and use it in an IPNS path like
/ipns/bafybeidta3hkxk3ihxfsk765oswgsjhmvcnkeestyuov6r2t5tyts4xuoe
. Here's how you might do the conversion:This is really, seriously cool, because now Peer IDs can be used in domain names and so an IPFS gateway operating at
bafybeidta3hkxk3ihxfsk765oswgsjhmvcnkeestyuov6r2t5tyts4xuoe.ipns.dweb.link
for example, will have origin isolation (hooray for security 🔒) AND IPNS enabled mutable data 🚀⚡️In the future, new Peer IDs will be v1 CIDs with a
libp2p-key
codec that isbase32
encoded by default...but that's a change for another day.🌲 Implemented
dag put
anddag resolve
CLI commandsThese have been available in core for a while now and we finally got round to surfacing them in the CLI. e.g.
🏗 API Changes
dag.put
got apin
option to save you from calling the pin API separately (and potentially losing your node if GC runs inbetween!)✅ Release Checklist
sharness(Does not runjs-ipfs
)webui(Does not depend onjs-ipfs
orjs-ipfs-http-client
)ipfs-desktop(Does not depend onjs-ipfs
orjs-ipfs-http-client
)❤️ Huge thank you to everyone that made this release possible
🙌🏽 Want to contribute?
Would you like to contribute to the IPFS project and don't know how? Well, there are a few places you can get started:
help wanted
label in the js-ipfs repoThe best place to ask your questions about IPFS, how it works and what you can do with it is at discuss.ipfs.io. We are also available at the
#ipfs
channel on Freenode.The text was updated successfully, but these errors were encountered: