Create 2018-10-29--go-core-dev-team-weekly.md #734
Conversation
ghost
assigned 
|
|
||
| - Done: completed the switch to tls-tris for QUIC (still a bunch of issues to fix though) | ||
| - Blocked: nothing | ||
| - Next: preparing for the IETF meeting next week |
There was a problem hiding this comment.
Anything that the group can do in order to prepare for the meeting? Does the IETF QUIC group know about libp2p? Are they excited about it?
There was a problem hiding this comment.
I'm preparing for the meeting by following the discussions of multiple WGs and reading drafts that might be interesting for us at some point in the future.
Of course, I'm bringing up p2p in general, and libp2p and IPFS from time to time.
There was a problem hiding this comment.
Might be valuable to point out that there is a draft spec for HTTP2-P2P ipfs/specs#21
|
|
||
| @schomatis (not attending) | ||
| - Done: | ||
| - Solved some issues and reviewed PRs on UnixFS and related components. |
There was a problem hiding this comment.
Which ones exactly? Any new development?
| - Done: | ||
| - Solved some issues and reviewed PRs on UnixFS and related components. | ||
| - Reviewed more UnixFS/MFS code. | ||
| - Next: Coordinate with Rob to start producing some IPFS Files documentation. |
There was a problem hiding this comment.
@schomatis, Rob is no longer available. Check in with the merged Community/Docs group (context here ipfs/ipfs#349) for IPFS Docs.
Ping @mikeal, @pkafei and @terichadbourne
|
|
||
| @travisperson | ||
| - Done: | ||
| - first pass at updating iptb |
There was a problem hiding this comment.
@travisperson Updating what part of iptb? Could you record a demo showing how to create a simple testbed for go-ipfs, go-libp2p, js-ipfs and js-libp2p?
There was a problem hiding this comment.
Travis updated the version of iptb that was being used in the go-ipfs project.
There was a problem hiding this comment.
understood. Thanks for the clarification :)
| @aschmahmann | ||
| - Done: | ||
| - Basic ID-based message passing/protocol structure | ||
| - Research on GraphSync and planning next steps for graph synchronization related to multi-writer files |
There was a problem hiding this comment.
@aschmahmann Are you aware of the new GraphSync specs? Read through https://github.com/ipld/specs/pulls
There was a problem hiding this comment.
I read about GraphSync a week or so ago, but I'll check out the latest.
There was a problem hiding this comment.
@diasdavid It's hard for me to tell how similar my "graph synchronization" issue is to GraphSync. My understanding of GraphSync is that it's designed to answer questions (or give the data corresponding to) the nodes descending from a Merkle root. The question I'm trying to answer is that if user A has a graph of changes (i.e. file versions where branching is allowed) and user B as another graph of changes, how can they best communicate so that they both get the graph Union(A,B).
These problems are certainly close together, but I'm not sure the same implementation will address both issues. Any thoughts you or anyone else has are welcome though. Who working on GraphSync should I be speaking with?
There was a problem hiding this comment.
It seems that what you are looking for is something very close to the coSelectors thinking -- ipfs/notes#154 (if Selectors are recursive, merkle root to leafs, coSelectors are merkleRoot coRecursive, pointing at future notes that point to our node).
Today, the way you do that is by having an append-only log that projects any other data structure that is the list of changes.
There was a problem hiding this comment.
This definitely shares similarities with the coSelectors you linked to. Just like you would have to do with synchronizing two append-only logs v1 of graph synchronization sends the entire graph between the two parties. The hope is that a later version of this type of graph synchronization requires less bandwidth per sync.
Should I try and leave this area mostly alone and focus on the interfaces and tooling that utilizes the simpler v1 implementation?
| - Research on GraphSync and planning next steps for graph synchronization related to multi-writer files | ||
| - Blocked: | ||
| - Next: | ||
| - Implement basic graph synchronization |
There was a problem hiding this comment.
@aschmahmann in what level? Over IPFS or by implementing a GraphSync prototype?
There was a problem hiding this comment.
A graph synchronization prototype over libp2p where the graph nodes correspond to version changes (where the versions are stored in IPFS).
| - Blocked: | ||
| - Next: | ||
| - Implement basic graph synchronization | ||
| - Work towards testing framework |
There was a problem hiding this comment.
@aschmahmann do you plan on using IPTB?
There was a problem hiding this comment.
I would love to, need to learn more about it
There was a problem hiding this comment.
@aschmahmann the sharness tests in go-ipfs are good examples of how to use iptb in a straight forward way - at least I found them to be so. https://github.com/ipfs/go-ipfs/blob/master/test/sharness/t0130-multinode.sh is one that is pretty clear.
There was a problem hiding this comment.
thx for the link, it seems like IPTB should be helpful.
| @stebalien | ||
| - Done: | ||
| - Fixed race in query events. | ||
| - Cut 0.4.18-rc1 |
There was a problem hiding this comment.
Congrats on then releasing 0.4.18 :D 👏🏽
|
|
||
| @stebalien | ||
| - Done: | ||
| - Fixed race in query events. |
There was a problem hiding this comment.
libp2p/go-libp2p-routing#31 and in go-ipfs: ipfs/kubo@e41ac96
There was a problem hiding this comment.
Wanna add it to the notes too?
There was a problem hiding this comment.
Feels a bit overkill but I've added it anyways.
No description provided.