New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
⚡️ v0.34.0 RELEASE 🚀
#1721
Comments
|
@alanshaw with this release, can js-ipfs move to base32 by default? |
|
@alanshaw Possibly want to make this release even bigger than it is? I'm currently working on stardust, a replacement for ws-star that actually works. I could ship it behind a flag with some help on this pr #1812 which requires this one to be finished libp2p/js-libp2p-crypto#125 |
|
@mkg20001 additional transports can be added through adding a custom libp2p bundle -- https://github.com/ipfs/js-ipfs#optionslibp2p. No need for special flags :) |
|
@daviddias I'm talking about replacing ws-star with stardust upstream in js-ipfs. So that |
I'd love it to but there's no PRs implementing it yet. Possibly in 0.35 or more likely in 0.36. 0.34 will bring js-ipfs up to speed with go-ipfs in terms of CID version agnostic get and be ahead of it with the Essentially the rough plan now is:
Absolutely not! This release needs to leave the building asap. |
|
Great work everybody! Exciting stuff. |
|
I am using ipfs for image uploading it was working fine but now I am getting the above error. how should I change my code to make it work again. i am new to Ethereum please help. |
Hello Please anyone expert here I am waiting for help. |

alanshaw commentedNov 19, 2018
•
edited
--cid-baseoptionDHTbumped to next releaseaddFromURL,addFromStreamaddFromFsReading Protobuf DAG nodes just got a serious speed boost as well as a memory reduction. Previously Protobuf DAG nodes (dag-pb nodes for short) carried a multihash property (a CIDv0) with them. This used up loads of CPU time calculating the hash for a given node as it was retrieved from storage and with the advent of CIDv1 there was no guarantee the hashing algorithm and length were correct.
So, we removed it!🦖
Ok so that had the unfortunate consequence of making the object API a whole lot less useful when writing data - the DAG nodes you got back were basically the data you put in. Hence the object API was refactored to return CIDs instead of DAG nodes for write operations...and we all lived happily ever after.
We found a big bottleneck (or should I say small bottleneck?) that meant the bigger the file you added to IPFS, the longer it would take - oh no😭 ! Good news folks, we've seen the speed of adding large files increase by 50% or more in some cases! 💥
Read all about it in the pull request notes.
We're putting the whole of npm on IPFS! These days npm is like 5.3 terabytes of data and it's all going in MFS. This is super rad, but we needed a good sharding strategy because 5TB is a lorra lorra files.
If you're curious about npm on IPFS, check out the project here.
Get informed of IPNS record updates and read and publish your IPNS records to the DHT. It's all there and it's all awesome. For those of you new to IPNS, let me give you the lowdown - IPNS puts the mutable in immutable🤣 It's an age old problem, content addressing is rad and all that, but if I change something the hash changes - 👎 boo...but wait, IPNS solves this, you get a permenant address for changeable content - hooray \o/.
IPNS over pubsub gets the word out quicker to peers that are interested when an IPNS record changes. IPNS over DHT allows peers to find and resolve your IPNS address to some content in the first place! In the next JS IPFS release (0.35) the DHT will be enabled by default and it's going to be epic.
Smoosh your CIDs into whatever version you like - you can now add data under a version 0 CID and get it back using a version 1 CID and vice versa. Now that you have this freedom you can encode them with whatever multibase encoding you like. Version 0 CIDs are all base58btc but if you convert to a version 1 CID you can encode it with base2, base32, base64url or whatever:
This is all work to smooth out the eventual transition to base32 CIDv1 by default - a move to allow CIDs to be used as valid URL origins. Have a read of this for more.
To help you craft your artisanal CIDs we've introduced a
--cid-baseoption to a bunch of CLI commands (and?cid-baseoption to a bunch of HTTP API endpoints). Check it out:We got you covered with WebUI 2.3 (quic support, responsive navbar, and a language selector), libp2p 0.24 and many other upgrades giving you a faster and smaller JS IPFS.
🏓 DHTbumped to next releaseThe Distributed Hash Table(tennis) is finally here! This is the biggest leap forwards for JS IPFS since sliced bread. It allows your IPFS node to find peers and content way more easily and it has full interop with Go IPFS nodes so y'all have the full IPFS network at your fingertips💥 I know, you're welcome - send flowers to @vasco-santos.ipfs.object.newipfs.object.patch.addLinkipfs.object.patch.appendDataipfs.object.patch.rmLinkipfs.object.patch.setDataipfs.object.putDAGNodeinstances, which are part of the IPLD dag-pb format have been refactored. These instances no longer havemultihash,cidorserializedproperties. This effects the following API methods that return these types of objects:ipfs.object.getipfs.dag.getadd*,cat*,get*have moved fromfilesto the root namespace. Specifically, the following changes have been made:ipfs.files.add=>ipfs.addipfs.files.addPullStream=>ipfs.addPullStreamipfs.files.addReadableStream=>ipfs.addReadableStreamipfs.files.cat=>ipfs.catipfs.files.catPullStream=>ipfs.catPullStreamipfs.files.catReadableStream=>ipfs.catReadableStreamipfs.files.get=>ipfs.getipfs.files.getPullStream=>ipfs.getPullStreamipfs.files.getReadableStream=>ipfs.getReadableStreamipfs.addFromStreamipfs.addFromUrlipfs.addFromFsDHT API methods renamed and return types changedipfs.dht.findprovsrenamed toipfs.dht.findProvsand returns an array of PeerInfoipfs.dht.findpeerrenamed toipfs.dht.findPeerand returns a PeerInfoipfs.dht.querynow returns an array of PeerInfoMore info--cid-baseoption has been added to the following CLI commands:jsipfs bitswap statjsipfs bitswap unwantjsipfs bitswap wantlistjsipfs block putjsipfs block statjsipfs addjsipfs lsjsipfs object getjsipfs object linksjsipfs object newjsipfs object patch add-linkjsipfs object patch append-datajsipfs object patch rm-linkjsipfs object patch set-datajsipfs object putjsipfs object statjsipfs pin addjsipfs pin lsjsipfs pin rmjsipfs resolve--cid-baseoption:jsipfs files lsjsipfs files stat?cid-base=query option has been added to the following HTTP endpoints:/api/v0/bitswap/wantlist/api/v0/bitswap/stat/api/v0/bitswap/unwant/api/v0/block/put/api/v0/block/stat/api/v0/add/api/v0/ls/api/v0/object/new/api/v0/object/get/api/v0/object/put/api/v0/object/stat/api/v0/object/links/api/v0/object/patch/append-data/api/v0/object/patch/set-data/api/v0/object/patch/add-link/api/v0/object/patch/rm-link/api/v0/pin/ls/api/v0/pin/add/api/v0/pin/rm/api/v0/resolvecidBaseoption has been added to the following core functions:resolvebitswap,dagandobjectAPIs WILL NOT auto upgrade your CID to v1 if it is a v0 CID and WILL NOT apply the encoding you specified. This is because these APIs return IPLD objects with links and changing the version of the links would result in a different hash for the node if you were to re-add it. Also, the CID you used to retrieve the node wouldn't actually refer to the node you got back any longer. Read this for further context.big.jsinstances now returnbignumber.jsinstances.By alphabetical order, here are all the humans that contributed to the release:
🙌🏽 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 wantedlabel at the Ready column in our waffle board - https://waffle.io/ipfs/js-ipfs?label=help%20wantedThe 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: