Create 2018-11-19--go-core-dev-team-weekly.md #768
Conversation
ghost
assigned 
| - jfs is broken | ||
| - using the default driver (ntfs doesn't have great performance over time) | ||
| - interested to see graphs with different data sets (expect to see this behave differently on different configurations of data - many small files, large files, etc) | ||
| - plan: expand to run more benchmarks on more computers to integrate with AWS to auto-run more stuff there. |
There was a problem hiding this comment.
@magik6k where can people follow all of this great work?
There was a problem hiding this comment.
Made ipfs/go-ds-bench#1 for that
| - Done: | ||
| * a lot of review of PRs for the QUIC spec | ||
| * more work on draft-17 | ||
| * started working on a benchmarking suite for quic-go |
There was a problem hiding this comment.
It's still pretty basic: https://github.com/marten-seemann/quic-go-benchmarks
I will have to work on better tooling to get a better picture of what's going on. Developing this tooling and identifying bottlenecks will probably be one of my projects for Q1 2019.
| @schomatis (not attending) | ||
| - Done/In Progress: | ||
| - Improving content for a concept document about files in IPFS (https://github.com/ipfs/docs/issues/133). | ||
| - Write mid-level document on the `ipfs files` API (https://github.com/ipfs/go-ipfs/pull/5052). |
There was a problem hiding this comment.
@schomatis you can leverage a ton of work done by the JS Team on documenting this https://github.com/ipfs/interface-ipfs-core/blob/master/SPEC/FILES.md#the-files-api-aka-mfs-the-mutable-file-system, the calls are the same :)
There was a problem hiding this comment.
Great thanks! That document is really nice and I can try filling in the blanks for some of the Go WIP parts.
There was a problem hiding this comment.
:D You bet! Sharing the thanks with @alanshaw @achingbrain and @hugomrdias :)
| @aschmahmann | ||
| - Done/In Progress: | ||
| - Decided to push off more sophisticated synchronization of version graphs for now | ||
| - Will revisit after a chat demo is working |
There was a problem hiding this comment.
@aschmahmann Shouldn't the chat app always work (given that bitswap exists) and then with your graphsync version get faster?
There was a problem hiding this comment.
Unfortunately, there's a bit of a nomenclature issue with GraphSync (there are currently 3 proposals all called GraphSync). My understanding is that GraphSync is about asking for DAGs of files instead of one by one asking for files corresponding to CIDs.
The synchronization of version graphs I'm referring to is that if Alice has a DAG A indicating the versions and branches of a data structure (e.g. a Git repo) and Bob has a DAG B indicating the versions and branches of that same data structure, there should be a protocol in place for Alice and Bob to communicate and each end up with the resulting DAG C which is the union of A and B . This may use some of the same techniques we end up using in one of the GraphSync proposals, but so far neither solution seems to fully contain the other. In order to try and be efficient I'm planning on pushing off more complex implementations of version graph synchronization (and just using a simple graph merge that sends the whole graph over the network) until I see more of how GraphSync develops and if there are any techniques I can borrow from there.
It is currently fairly straightforward to have a chat application work over pubsub. However, having this structure happens to make it very easy to implement at causal chat application (i.e. a user will not be able to see a message without first having seen the messages that proceeded it).
I'll try and document this more thoroughly, but please let me know if you have any questions.
| - Happy Thanksgiving! | ||
|
|
||
| @warpfork (you can skip me, not interesting and no blockers :)) | ||
| - Done: worked on package management / merklebuilds topics most of this week |
There was a problem hiding this comment.
@warpfork what work on package management ? Any progress on the unixv2 spec (//cc @achingbrain) and IPLD APIs revisit (//cc @vmx)?
It would be really great to get you involved in:
There was a problem hiding this comment.
one more ipfs-inactive/interface-js-ipfs-core#121 :)
There was a problem hiding this comment.
Thanks @daviddias I've opened an issue and linked them all: ipld/js-ipld#182 (comment)
|
|
||
| @raulk: | ||
| - Done: | ||
| - [devcon4 field notes finished!](https://docs.google.com/document/d/1nTa5xL9-Cs8FaHITCAKG2dmlPuU4ps-plC_54lx4EVc/edit?usp=sharing) |
| - Done: | ||
| - fix for Bitswap rejecting unwanted blocks | ||
| - improved benchmarks for bitswap | ||
| - final work on streaming LS -- ready to merge? |
There was a problem hiding this comment.
And notify everyone that was excited about it (imageNet people)
No description provided.