Skip to content
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

Collection for IPFS Newsletter #11: May 1 - May 16 #41

Closed
RichardLitt opened this issue May 16, 2016 · 9 comments
Closed

Collection for IPFS Newsletter #11: May 1 - May 16 #41

RichardLitt opened this issue May 16, 2016 · 9 comments

Comments

@RichardLitt
Copy link
Member

Newsletter going out the week of May 16.

@RichardLitt
Copy link
Member Author

  • standard-readme: @RichardLitt made a spec for what a standard readme should look like, and plans to ensure that all IPFS repos are up to that spec. He has also made a generator to help people create compliant readmes faster. This will help lessen the cognitive load involved with creating and maintaining READMEs. There are plans, in the works, to make a linter, too.

@RichardLitt
Copy link
Member Author

  • go-ipfs: The logic surrounding defaults in go-ipfs has been clarified somewhat by the inclusion of a standard way to mark defaults, and greater enforcement of making them overtly declared. @RichardLitt went through the codebase making a lot of small PRs to make sure this worked: thanks @whyrusleeping and @Kubuxu for helping out so much. To see all changes, refer to this issue.

@RichardLitt
Copy link
Member Author

RichardLitt commented May 16, 2016

js-ipfs

Bitswap has been merged into js-ipfs, as of this pr. This means that js-ipfs nodes now can exchange (data) blocks. This is compatible with go-ipfs bitswap, but due to the multistream protocols not being a 100% compatible right now we can't connect to go-ipfs nodes yet. As soon as multistream connects, the bitswap implementations should have no problem exchanging blocks. To help out with this or follow along, look at this issue.

interface-ipfs-core

@dignifiedquire and @diasdavid are creating interface-ipfs-core, and "object" is the first part of it as of this week. This will be a test suite and interface you can use to implement a IPFS core interface. Their work involved writing the Object API spec (plus the foundations to write the remaining api specs), creating a batch of tests, and upgrading js-ipfs-api (now 4.x.x release) with the new interface. This unblocks the possibility of swapping js-ipfs-api with js-ipfs for Orbit.

There are more methods to tackle in the core. @nginnever will be tackling files this week, in this PR. Feel free to jump in and help out.

The primary goal of this module is to define and ensure that both IPFS core implementations and their respective HTTP client libraries offer the same interface, so that developers can quickly change between a local and a remote node without having to change their applications. In addition to the definition of the expected interface, this module offers a suite of tests that can be run in order to check if the interface is used as described.

The API is presented with both Node.js and Go primitives, however, there is not actual limitations for it to be extended for any other language, pushing forward the cross compatibility and interop through diferent stacks.

@RichardLitt
Copy link
Member Author

js-multihash

js-multihash now has a more extensive set of tools to convert hashes, thanks to @dignifiedquire. You can look at the new API methods in the README section for them. Mostly, these are conversion methods; overall, they help provide a more extensive interface for dealing with multihashes in js.

@RichardLitt
Copy link
Member Author

RichardLitt commented May 16, 2016

js-multistream

@diasdavid updated js-multistream to the latest revision of the multistream spec. He also started working on refreshing the API of the module to make it less wonky: this means writing down the entire interface, upgrading js-ipfs-api, leveraging what js-ipfs-api already had previously built, and then running the same batch of tests in both js-ipfs and js-ipfs-api and making sure they all pass. In the future, this means that we have the foundation to build up the rest of the core-api spec.

require('lx')

@diasdavid gave a talk at require('lx'), a Node and JavaScript meetup in Lisbon. Tweet: https://twitter.com/Sericaia/status/730838055121235968

Also, look at Nuno's talk on Ethereum: https://twitter.com/daviddias/status/730848871329480704

@RichardLitt
Copy link
Member Author

RichardLitt commented May 16, 2016

orbit-db

@haadcode spent the last few days optimizing orbit-db: the write throughput performance is now at ~100ops/s (~33% improvement) and the code base has been fully modularized. orbit-db now uses the following modules as datastores: orbit-db-eventstore, orbit-db-feedstore, orbit-db-kvstore, orbit-db-counterstore.

Orbit

Orbit also got some love, and @haadcode has been integrating the new orbit-db version into it. As well, there are now new contributors: thanks @masadeus for username auto-complete on 'tab', and thanks @shamb0t for emoji auto-complete and preview. (Emoji auto-complete is not merged yet but will be in the next couple of days).

@RichardLitt
Copy link
Member Author

go-ipfs

This last week, @whyrusleeping spent a lot of time debugging and fixing the hanging issue with yamux. This is the issue that causes (in at least 90% of observed cases) the gateways and other nodes to hang when simple requests are made on them. He has a patch in place and is waiting on upstream code review to get it pushed in officially.

During that process he also did a bunch of gx work, refactored the dependency tree of go-stream-muxer to be more flat, making updating that area of the code easier, and also made gx deps --tree much more visually pleasing.

Finally, @whyrusleeping fixed and pushed up a perf improvement on go-multiaddr. Previously to create a multiaddr from some bytes, we converted it into a string, and called NewMultiaddr on it which converted it back into bytes. This was eating up an unnecessary amount of CPU time on the gateways. Now we just create it directly.

@RichardLitt
Copy link
Member Author

common-readme

@noffle has been working on common-readme. This is more node-specific than @RichardLitt's standard-readme, and is aimed at making a standard way of presenting information for NPM modules. @noffle and @RichardLitt are going to spend more time working together and trying to make the best readmes they can.

@RichardLitt
Copy link
Member Author

ipfs-twitter-resolver

@noffle made an IPFS Twitter resolver: basically, a tiny CLI server for resolving /twitter/user/key to an IPFS address. It uses npm and ... (expect a blog post soon).

@RichardLitt RichardLitt mentioned this issue May 16, 2016
4 tasks
jennwrites added a commit that referenced this issue May 7, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant