If i've uploaded a version of a video, is it possible to submit a revision in which only the pieces that are changed need to be uploaded?

For example, I have a 10 minute video that encodes to 10GB in size. I upload it. A client wants me to replace their logo at the start of the video with a different one. I've made one small change to the first 10seconds, but it's still a 10 minute, 10 GB video. Can it only upload the changed sections, saving me large amounts of data transfer?

The same would apply to a large .tiff file. If I only change a few pixels, is there a way to only upload the change?

@jacobheun

Currently, one's peer ID is a permanent identity on the network. This is really unfortunate for privacy. We'd like to be able to expose a single ephemeral device ID to the network and then have multiple permanent IDs behind this ephemeral ID.

Assuming we have private, encrypted PeerInfo records (see ipfs/notes#291 (comment)), we can implement this as follows:

1. Every node will have a single ephemeral ID (regenerated daily or, possibly, at boot). All connections go through this peer.
2. Nodes may have zero or more permanent IDs.

To connect to a permanent ID, one:

1. Looks up the permanent ID in the DHT (assuming encrypted peer info records). The peer info record will point to an ephemeral ID.
2. Looks up the ephemeral ID in the DHT to get the location-based multiaddr of the peer. Note, we may short-circuit and include the ephemeral addresses in the permanent peer info record.
3. Connects to the ephemeral peer.
4. Opens a stream to the identity service.
5. Runs a protocol with the identity service first proving the identity it wishes to use and then asking the identity service to prove the identity to which it wants to connect. For efficiency, these identities may be assigned short, stable numbers (could be tricky, may not be worth it).
6. The first node can now open new streams to the permanent identity on the second node by:
7. Connecting to the identity service.
8. Specifying the identity from which it wants to connect (already proven) and the identity to which it wants to connect).
9. Finally, it can negotiate the appropriate service over this connection.

Yesterday, @raulk gave an impromptu overview of Libp2p at Devcon 4. He explained the relationships between the different layers of Libp2p (transport, routers,multiplexers,etc). It would be great to have a flow diagram showing how these concepts interconnect and what their relationship to one another is.

Hi!

Just to notify you, the link pointing to golang implementation in README is wrong. It points to https://github.com/libp2p/go-libp2p where I think the correct is https://github.com/ipfs/go-libp2p

I have successfully routed GRPC over a libp2p stream in Go, and it was actually pretty trivial. I'm working on bundling together a go-libp2p-grpc package at the moment, although that shouldn't take more than 10 minutes.

I'm thinking more now on the browser side. There is a project called grpc-web, that is probably still private, that Google invites contributors to. https://github.com/grpc/grpc-web

It is designed to allow the browser to directly connect to a GRPC server, which makes sense. What if we re-purposed the GRPC node code to run in the browser with GRPC-over-libp2p? This should be pretty trivial - just replace the Buffer implementation with ByteBuffer.js or so, and tweak a few things.

Some context on libp2p/interop#1

This issue is here as placeholder for discussion around the libp2p service

Explore supporting http://www.discocrypto.com/

Today, at the ETH2.0 Working Groups session, @mgoelzer suggested that diagrams be made in order to easily convey how various pubsub protocols work. This could also help clarify some understanding issues that more experience developers might have had after reading the specifications for the above protocols.

Hi Everyone!

The libp2p core team will be meeting next week to go over all matter of topics, as well as to flush out work for the next year and beyond!

If you have not already reviewed the Libp2p Roadmap doc, please do that. We'd love to hear from you. If there are things you'd like to see Libp2p address, please feel free to comment directly in the doc, or here, once you've given it a read through.

We're all really excited for what's coming in 2019, and want to ensure we're also addressing the needs of the community. We're looking forward to hearing from everyone!

If you can't get your feedback in by next week, don't worry, we'd love to hear from you anytime.

Your website lists a Java implementation as "in progress." Is the repo on a different site? Do you need any help with it?

I think libp2p may implement dtls transport. I'm author of pure js dtls transport - https://github.com/nodertc/dtls. Right now it's only client side version with modern secure ciphers (AEAD, ECDHE).

Go and rust implementations may use GnuTLS or OpenSSL.

Similar to the one for ipfs: https://github.com/ipfs/specs/blob/master/overviews/modules.go

Meta-issue to track the progress of getting the QUIC transport published for go-libp2p. Some notes per Marten and my conversation this evening:

Testing Concerns

• Is there an IPFS test network we could test the transport on at scale?
  • Ideally with telemetry collection so we'd not want actual users onboard
  • Infra team?
• What's the current state of telemetry in IPFS/libp2p?
  • Tracing ETA?
  • Data collection & processing

TODOS

• Get as many crypto-savvy reviewers to go over the latest refactor of the QUIC transport
• Bring libp2p-quic-transport into the libp2p org as go-libp2p-quic-transport
• Determine a set of metrics to evaluate the success of QUIC
  • Dial speed
  • Total round trips in negotiating upgrades

Most of the heavy lifting is done and it would be great to have a demo-able version ready by the July meetings in Berlin.

You mention orbit.libp2p.io as an example of libp2p in action. Unfortunately that example is offline. It would be fantastic to see it in action or replace it with a link to another example or remove the note of it.

As @whyrusleeping brought up in the last Sprint call, we need to revisit libp2p milestone 2.

@whyrusleeping can you captain this? Ideas discussed:

• break MS2 into 3 separate milestones
• defer them to Q4

Let's not forget to update the waffle board.

@carospiegly - Upgrade path to Coral

DHT goal for September: PoC with successful node communication, ability to put and retrieve values

Four parts to finishing Coral:

• Adding the protos ← doable by end of September
• Implementing splitting ← progress by September but won't be done
• Implementing merging ← progress by September but not done
• Testing ← targeting end of 2018

Ref: https://docs.google.com/document/d/1XOmU-9V6yx0tMcW9iVeL9nNSgrPDt5X7aBmRzD2ZO34/edit

On https://github.com/libp2p there is a link to http://libp2p.io/ but this link doesn't work right now.

The error in firefox is: Unable to determine IP address from host name "libp2p.io"

How to get the libp2p source code?
How to compile C++version？

libp2p organization has any project pairs (js and go) for transport implementation.

• js-libp2p-tcp and go-tcp-transport
• js-libp2p-udp and go-udp-transport
• js-libp2p-utp and go-utp-transport
• js-libp2p-secio and go-libp2p-secio

I think we should unify names to (js|go)-libp2p-(tcp|udp|utp|secio) for consistency.

The doc below has proposed OKRs and a features roadmap (second tab) for the libp2p in 2018 through mid-2019. It is a WIP.

https://docs.google.com/spreadsheets/d/1HTXfgR5FyPTFhsTkFPRThkeMvHvCgJOaAs7BSl_vQ_0/edit#gid=0

To get to completion, we'll need to:

• Have some discussion in this issue to agree about goals and dates
• Make all the KRs quantifiable (eg, add a ship date for binary or event KRs)
• Break off a subset of KRs for Q3 beginning Jul 2018
• Distinguish between committed vs aspirational OKRs?
• Add dates to roadmap

@whyrusleeping @diasdavid @bigs @Stebalien

With the increasing interest in libp2p, with the website coming up and with other implementations and uses popping, we need more than ever to start nailing down and matching our building blocks, by this I mean: names, modules scope, behavior, etc.

@whyrusleeping I feel me and you can tag along for a week and get a lot of this done, how do you feel about last week of March?

We would:

• Create a diagram of all the pieces tied together
• Create interface definitions for Go
• Build the DHT in JS
• Create examples with a language that applies to both programming languages

@bigs DHT goal for September

• libp2p daemon with the bare functionality required to do basic DHT ops (like put and read back keys)
• Just running on one machine
• Leave out IPTB for now

Ref: https://docs.google.com/document/d/1XOmU-9V6yx0tMcW9iVeL9nNSgrPDt5X7aBmRzD2ZO34/edit

Ethereum projects on libp2p

Starting a thread so we can keep track of questions regarding what it might take to get Ethereum (present and future) operating over libp2p.

General Interests

Ethereum 1's codebase already features a lot of libp2p's functionality, but they'd like to remove some of that burden and expand the capabilities. Furthermore, with Ethereum 2 research beginning as a relatively green-field project, they would like to identify the most stable/performant pieces of libp2p to maximize ease of development vs future pain.

• Swappable transports
• Zero round-trip handshakes (a la DTLS/QUIC)
• Stronger encrypted transports
• Attack mitigation (DDOS, timing attacks, etc. Obviously a big one!)
  • Security audits planned/executed?
  • Node identity and authentication (perhaps verifiable from sources outside of peer network)
  • Peer selection strategies (is random-walk appropriate)
  • In degree vs out degree measurement for connection rebalancing
• Connection management (likely relevant to ongoing peer swarm refactoring)
  • Pluggable ConnManager?
• Gossipsub
  • Performance characteristics
  • What are its IPFS/PL use cases? Will this implementation stick around and get the love it needs to become a core part of either Ethereum or PL infrastructure.
• Potential IPFS/Ethereum interactions
• Python/other language support
  • libp2p daemon is likely highest priority

Sharding-specific Interests

• DHT persistence, speed of bootstrapping
  • When rejoining the network, are your peers good/connected?
  • DHT routing table persistence not yet landed
• How might we map shards to libp2p?
  • Separate peer network per shard
  • Single channel that dispatches clients to separate peer networks
  • Multiple channels overlayed over a single shared peer network
• How can we optimize balance of flood/gossipsub propagation vs active connections?
• Support for authentication in flood/gossipsub?
• Fast shard jumping
  • Can we (perhaps at a slower interval) keep a small cache of DHT routing table for other shards?
  • Can we keep an open connection to some small number of peers in shards we're not actively participating in to speed this switch
  • QUIC transport clearly a huge boon here

I'll edit this initial post as I get more clarity on requirements and requests!

Attn: @mgoelzer, @JustinDrake

It would be really really useful to be able to run ipfs with --disable-transport-encryption, and then meaningfully dissect the incoming and outgoing packets.

• multistream-select
• multistream
• mplex muxer
• mounted protocols like bitswap, dht, identify
• etc.

The same applies to the dev consoles of browsers.

We've been running into an issue in go-ipfs where we have way too many peer addresses. We've partially fixed this by addressing the bug where we were storing and gossiping ephemeral peer addresses indefinitely however, that's not a complete solution.

I'd like to make three proposals:

1. Sign and timestamp peer records.
2. Set a maximum size and maximum number of peer addresses allowed per record.
3. Allow peers to specify a priority for dialing each address.

While we'll have to wait a while to start validating these fields/restrictions, they'll help a lot.

https://github.com/libp2p/libp2p/blob/master/ROADMAP.md#milestones-to-be-added

Hi, I've started on a C# implementation of the library. Would you be interested in having it in the organization?

So far I've got a working impl. of the libp2p-crypto module here, but more in the workings. The plan is to implement/port it to modules so it will map to the go impl.

many of the sub-repos are using the old logo, we should update these

I would like to use the same asymetric keypair both for Ethereum and IPFS in order to build a publication service. I.e. the user making an ETH transaction to the wallet of a service, the dApp scans the blockchain to find the transactions on its address and extracts the public key ... Then it has to convert that key to the address in IPNS. This is where I stuck so far.

In the original IPFS whitepaper it was pointed out that NodeId is a hash of piblic key. The problem is that crypto algos in Ethereum and IPFS are different. I started to research the issue and found out about CIDv1 that should support multicodecs. But was it ever implemented?

As related to the current thread - am I correctly undetstanding that NodeId is not even CIDv0, bit just a hash of RSA public key?

I mean, w/o tight coupling between cryptocurrency blockchains and IPFS ... the situation looks really grim.

Originally posted by @reardenlife in multiformats/cid#26 (comment)

@jhiesey DHT goal for September

Implement secure disjoint path lookups:

• No breaking changes, should be easy upgrade
• An RFC-style spec for the Rust team in libp2p/specs/feature-specs
• Implement Go and JS

Ref: https://docs.google.com/document/d/1XOmU-9V6yx0tMcW9iVeL9nNSgrPDt5X7aBmRzD2ZO34/edit

It would be interesting to see if we could fit libp2p messaging/streaming related modules to fit the OpenMessaging specification. I saw recently someone was looking to build MQTT on top of IPFS, not sure if that is how it should be done but the point is that people have an interest in building IoT and related messaging tech on top of libp2p/IPFS.

Even if we don't go with the spec, I think it would be useful to be able to support the models outlined in this doc.

@bigs / @raulk / @Stebalien - Peer routing records (September stretch goal)

There is a quick fix and a long-term fix. Consensus was to do the quick fix now (Sept stretch goal), then focus on long term next quarter.

QUICK FIX: track nodes with too many addresses

• REFACTOR: factor out all records into its own module with clear interfaces
• QUICK FIX: Track nodes that have too many addresses (“address abusers”)
  • If a node sees that it has too many addresses, start trimming them down.
  • If I connect to a node and the identify service gives back too many addresses, I should trim the list down.
  • If I connect to a node and it gives me a set of addresses, I should replace the set of addresses for that node with the ones it recommended, not the current behavior which is to take the union of my addresses and the other node’s.
  • Reasoning: anti-DOS feature, also there are older nodes floating around with very long lists of addresses.

LONG-TERM FIX: Signed peer routing records (with expiration times)

• Need to store these somewhere; may require changes to the peer store.
• Peers may need to keep refreshing these (heartbeat identify?)
• Need to add support before turning on validation by default.

Ref: https://docs.google.com/document/d/1XOmU-9V6yx0tMcW9iVeL9nNSgrPDt5X7aBmRzD2ZO34/edit

• Brief talk: https://www.bamsoftware.com/talks/30c3-pt/index.html
• Wiki: https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports
• Spec: https://gitweb.torproject.org/torspec.git/plain/pt-spec.txt

• Investigate for technical feasability
• How exactly to do it
• Who could help with implementation and testing
• Who in the Tor team can guide us

Starting a meta thread to address our plan for DHT query performance. First step is micro and macro analysis of DHT query performance.

Near term:

• Improve quality and quantity of logs in DHT module (golang) (@lgierth, @gpestana)
• Enable opentracing backend for logging in libp2p (@lgierth, @gpestana)
• Execute query_test on IPFS network to:
  • Discover network topology
    • NAT coverage
    • Locality / geo distribution
  • Get detailed traces of dialing/DHT protocol
• Visualize traces
• Machine-readable debug logging (could dump serialized protobufs in a comprehensible structure to enable "time travel" debugging
• libp2p daemon
• IPTB/go-netdef to support virtual "NAT" undialable nodes (@bigs)
  • IPTB support for virtual networks that span multiple physical computers (if IPTB remains unixy in its philosophy, we could theoretically make a tool that leverages IPTB to make clustered networks)

This is a meta issue. It describes a set of issues that need to be created.

All of the posters from Berlin are here:
https://drive.google.com/drive/u/0/folders/1te63vJYCmm7jito2c8-N4PYKWUYDf9Bq

For each one that is relevant to libp2p, we should create an issue linking to it and requesting that someone create a docs PR covering the topic in writing.

(Per discussion with @Mr0grog in Berlin.)

Code below

  <a href="http://libp2p.io/"><img src="https://img.shields.io/badge/project-libp2p-yellow.svg?style=flat-square" /></a>
  <a href="http://webchat.freenode.net/?channels=%23libp2p"><img src="https://img.shields.io/badge/freenode-%23libp2p-yellow.svg?style=flat-square" /></a>
  <a href="https://waffle.io/libp2p/libp2p"><img src="https://img.shields.io/badge/pm-waffle-yellow.svg?style=flat-square" /></a>

After spending way too much time trying to figure out how to follow the semantics mDNS spec, I've come to the conclusion that, in light of our multiaddr system, it's probably not worth it. So, my proposal is to ignore the port/ip addresses and duplicate this information in the TXT field (flagrantly violating the spec).

Requirements

• Needs to work with multiple transports (multiaddrs). Nether of the current implementations (js or go) supports this.
• Needs to be compatible with all reasonably functional mDNS libraries.

Current State

js-ipfs

• Uses ipfs.local while the spec requires _$service._$proto.local where $service can be anything (but the _ prefix is strongly suggested) and $proto must be tcp or udp (where udp is just a catch-all for everything else). This is a requirement of the SRV spec and we probably shouldn't be violating it.
• Doesn't announce full multiaddrs (won't work with, e.g., QUIC).

go-ipfs

• Uses _ipfs-discovery._udp.local. We're not announcing the discovery service, we're announcing the ipfs service.
• Also doesn't announce full multiaddrs.
• May hijack the hostname? Need to look into this more.

Proposal

First, we need to specify the Instance, ServiceName, Proto, and TLD fields (for mDNS).

The constraints are:

• The TLD must be .local (for link-local mDNS, at least).
• The proto should be either _udp or _tcp for legacy reasons. As _udp is treated as the "catch all" we should use that.
• The service name (third to last) must begin with an underscore.
• The instance name can be anything.

I propose:

• Instance: Peer ID. Like js, go doesn't specify one.
• ServiceName: _ipfs. This is inconsistent with both js and go but obeys the spec (starts with an underscore, names the actual service we care about). Also, using a different service name will provide us a clean break between new and old nodes.
• Proto: _udp. We need something and _udp appears to be the catch all.

Second, we will need to at least specify a set of IPs and ports.

• I'd just let the library pick whatever IPs it wants. We won't read them.
• For the port, could we just put 0? We really don't care.

Third, we need to specify the multiaddrs somewhere. I'd like to reuse dnsaddr for this. That is, for each multiaddr, attach a TXT record of the form dnsaddr=/full/multiaddr.

Finally, we need to put a reasonable hostname in the A/AAAA and SRV records. We could continue putting in the local hostname but I'd kind of like to use QmId.ipfs.local (it's not the job of ipfs to broadcast the hostname to the network). Will that cause any problem)?

@whyrusleeping, @diasdavid, @richardschneider thoughts?

Hey All!

We're (Protocol Labs) planning to refresh the libp2p website, and with that it makes a lot of sense that we have a logo to go along with it!

Would love any & all feedback on this process.

We're trying to find a logo that symbolizes the core of libp2p: peers forging connections with each other over a variety of protocols; finding content & transferring it.

So far we've come up with these rough ideas, the lines here could be interpreted as separate peers. This is all still preliminary so nothing set in stone (though we are moving fast to quickly settle on something).

Any thoughts or ideas throw them out there!

@raulk and I, along with the help of many others, are beginning the process of devising a multi-year roadmap for libp2p. The ongoing working document is here: libp2p Roadmap Document.

As a first iteration, this document is a long enumeration of all the possible goals for the project. We aren't necessarily going to pursue all of these goals, but having them all in one place is a useful starting point.

We're now entering a phase where we will define a set of high level objectives for the project, unpack them into specific goals, and decide what is in/out of scope, what is urgent vs. back-burner, etc. That process will also happen in the same working document.

Anyone with an interest in the project is welcome to participate in this discussion. Right now, the best way is to make suggestions in the document or in this issue. As we get closer to something final, we'll convert it to markdown, open a PR here, and maintain the document in this repo. In the meantime, come join us in the document and help shape the future of the libp2p project.

Interviewed Lucas at centrifuge.io about shortcomings in current docs. Ideas that came out of the conversation:

• Rock Paper Scissors demo (https://github.com/mikiquantum/rock-paper-scissors-demo) is good and includes slides. Maybe do a recorded video around this (original talk was not recorded).
• Tutorial that walks through the concepts like peer id, peerinfo, etc.
• Regarding JS/Go tutorials: more comments? Rust examples include many lines of comments that explain what is going at each step. Adding this to Go and JS examples might be fastest way to help new users get started.
• JS’s echo example has empty README; Go’s equivalent example is slightly better but still doesn’t explain what a multiaddr is, what basic host is, why it’s done in steps (there’s a reason, so explain it!)
• Why can’t you just connect based on a multiaddr string? Explain this.
• Maybe walk through each of the Go and JS examples with an expert, explaining what each thing is (peer info)
• “Kauri” - bounties for docs
• Docs writers slack group (Lucas can add us if interested)

Child of https://github.com/libp2p/libp2p/issues/55

@jhiesey (stretch goal for end of Sept)

• Create js-libp2p daemon if one does not already exist
• IPTB plugin to connect IPTB tests to js-libp2p and go-libp2p daemons

/ cc @jacobheun - John should probably sync with you so he doesn't reinvent any wheels here

Ref: https://docs.google.com/document/d/1XOmU-9V6yx0tMcW9iVeL9nNSgrPDt5X7aBmRzD2ZO34/edit

Hello friends,

It's that time of the quarter... the middle! And that means big fun: mid-point scoring of OKRs.

Background on what we do at mid-quarter: ipfs/team-mgmt#668

For libp2p, I want to follow the same process as David's issue above. I'd like each KR owner to assign a mid-quarter score to your KRs this week. On next week's call, we'll do a check-in as @diasdavid describes in ipfs/team-mgmt#668.

Updating the OKR sheet is a great opportunity to communicate how things are going, where you might need help, thoughts on whether we should change plans, concerns or frustrations, etc.

Remember that we're mostly focused on the P0s for this quarter. But let's score everything.

@bigs: You have P0 OKRs on the Rust tab, Go tab and PL tab.

@diasdavid: You have P0s on the JS tab, overall project tab.

@marten-seemann: You have P0's on Go tab, overall project tab

@Stebalien: You have P0s on Go tab, PL tab

@jacobheun & @vasco-santos: You both have P0's on the JS tab

@whyrusleeping: You have P0s on the Go tab, PL tab

@mgoelzer: I've scored all my P0's. I'll make another pass to get the others scored. Oh, and I'll fix those broken formulae at the top.

/ cc @lgierth (you have some P1 KRs)

/ cc @raulk (for general interest)

A good way to get a broad view of what is out there in the P2P space is by checking the awesome lists about P2P. The ones I found so far are:

• https://github.com/kgryte/awesome-peer-to-peer
• https://github.com/mafintosh/awesome-p2p
• https://github.com/retrohacker/awesome-p2p
• https://github.com/steve-vincent/awesome-decentralized
• https://github.com/hackerkid/Awesome-P2P

Keeping track of these here as well for discoverability purposes.

• PubSub notes from the IPFS Workshop - recursion and corecursion, PubSub API and Self Certified Streams
• On "DialMe", NAT traversal, Relay, line switching, packet switching (libp2p protocols)
• Description language for libp2p services
• Tahoe-LAFS Networking Layer (named 'foolscap') and libp2p
• A consensus interface for libp2p
• IPFS & libp2p <3 Ethereum - Roadmap of things to get everything working together nicely
• Shared Secret constructions for Private Networks
• Thoughts on the next level of content routing for ipfs
• The packet switching endeavour
• PubSub API

Statement of Problem

libp2p today does not have a clear public API. We don't define in one place the interface a downstream user of the library should program against. We don't make clear which abstractions (like peerstore or swarm) are internal to the library (implementation details from a user perspective) versus which are public and intended to be instantiated and operated on in user code.

Imagine trying to write a Linux program without a clear set of documented syscalls, and without a clean separation between kernel concepts (like spin_lock) vs the corresponding userland concepts (sleep call). That's kind of the situation we are in today.

Part of this problem arises because we are in the process of improving some interfaces. For example, in the Go implementation, the host object is becoming more robust and abstracting away more implementation details than it did in the past. Another problem is that the different language implementations are using different terms for similar concepts, e.g., host in Go vs node in JS.

Status

We have solutions to bits and pieces of this. The examples in go-libp2p/examples and js-libp2p/examples are awesome in showing use of the libraries. We also have some efforts underway to try to provide broad, cross-language documentation and example code.

Proposed Solution

Let's define a single public interface to libp2p that meets these requirements:

• Documented: clearly define the function calls and objects a programmer should interact with
  • Some intro documentation should explain cross-language concepts (like what is a DHT, etc)
  • Pointers to language specific API reference and examples should branch out from there
• Versioned: any real world API needs to be versioned
• Backwards compatibility: programmers need confidence that they can rebase their code onto the next version of a library without breaking anything
• Cross language: our API concepts should be broadly similar across languages (exact function names can differ but concepts must map one-to-one)

Draft interface

• https://gist.github.com/jbenet/8e4f894021fcd23fc04086baee5889ad

(edit: added @jbenet's draft gist as a strawman for debate)

Is there any technical reason libp2p couldn't support multiaddrs and transports such as Go/Rust channels, shared memory, threads, etc? I think being able to write code and have it run the same between threads as it does between nodes could open up some interesting use cases.

This is my first draft notes. I want to expand on these more

Following libp2p/interop#1, we need an RPC library that:

• Has documentation generation support
• Has tests generation support
• Has client generation support
• Can be mounted over any Duplex Stream so that it fits right on top libp2p stream (e.g https://www.npmjs.com/package/znode)

Ideally, it would also:

• Use IPLD nodes as the transfer objects so that we don't have to stick to one serialization format (i.e dag-cbor, raw, etc)
• Have support for streaming files and directories (like tar-stream) built-in

Lot's of learn from:

• json-rpc http://www.jsonrpc.org, spec, learnings, tooling and more

Domain fronting is a technique that incentivizes actors to not block an individual website/service. It's used by Signal, Lantern, Tor, Psiphon, and others.

I can see this being useful to:

• protect bootstrapping -- we can make the go-ws-transport capable of domain fronting, and then deploy websockets bootstrappers with major cloud providers
• protect individual IPNS/dnslink pages -- with TLS/SNI inspection, it's possible to allow 99% of traffic to the ipfs.io gateway, but block e.g. example.com CNAME'd to the ipfs.io gateway.

Dumping a little reading list:

• https://www.bamsoftware.com/papers/fronting/
• https://whispersystems.org/blog/doodles-stickers-censorship/
• http://devblog.getlantern.org/Beating_GFW_With_Go
• https://trac.torproject.org/projects/tor/wiki/doc/meek

During devcon4, some contributors like @Mikerah asked for academic reading material for different areas of P2P networking (and networking in general): gossip/pubsub, discovery, DHT, protocols, algorithms, standards, etc.

Instead of sending her my library, why not build a collaborative library for the libp2p community? If there's interest, we could turn it into a distributed journal club on a bi-weekly/monthly basis! ;-) 🤓

If you'd like to share your library, please create a Gist with containing a BibTeX export of the references you'd like to share, and post the link in a comment below.

⏬⏬⏬

This issue is to track Q4 libp2p OKR planning. Please see the current work-in-progress sheet.

Here's the status:

• I have simplified the structure based team feedback: 4 tabs (Project, JS, Go, Rust), fewer cross-sheet dependencies and roll up cells
• I have defined and filled in a high level Project goals tab
• Following discussions with many of you yesterday, I have added some opportunistic new O's around things like Ethereum community adoption, etc.
• I removed all the Q3 KRs. If there were important and left unfinished, the language teams should resurrect them.

Here is what I'm asking:

• I would appreciate everyone's feedback on the Project goals tab. I don't seek to be dictator for this tab; just putting forward a first draft.
• JS team + David - can you define your specific technical OKRs such as features and fixes for js-libp2p on the JS tab?
• Go team + David - ditto for Go tab
• Rust team + Pierre - ditto for Rust tab

Ideally, these should align with the overall project goals we agree to in the Project tab. My hope is that we'll converge through a bottom-up and top-down combination, like last quarter.

Comments welcome in the doc or this issue.