Pedro Teixeira

Although this is a generic aspect of IPFS / libp2p, I think I can clarify a bit: You can use whichever transport you configure your IPFS node with. Currently, for...

In the IPFS constructor you can specify which addresses and transports you want in `options.libp2p`: https://github.com/ipfs/js-ipfs#optionslibp2p In node it default to this libp2p config: https://github.com/ipfs/js-ipfs/blob/master/src/core/runtime/libp2p-nodejs.js And these addresses: https://github.com/ipfs/js-ipfs/blob/master/src/core/runtime/config-nodejs.js The...

@haadcode that's a great point, it really forbids us from using a non-local node with this package, but I think this is a limitation of `ipfs-api` and the HTTP API,...

Nope. This depend on ipfs-api, which would have to be standardised and implemented in go-ipfs and js-ipfs.

Correct, but not in the remote API mode. On 8 Apr 2018, 13:05 +0100, nezzard , wrote: > For now, we can use it only with js-ipfs? > — >...

@haadcode that's super, I think they may be very useful in some of upcoming work: I think I'm going to need direct communication, presence, but not broadcast. I'd be super...

It seams like I don't have enough permissions for that. @diasdavid an you help on this?

@victorb I was referring to the metrics we could export from the pinner itself, not the metrics we need from replicas.

I think that the underlying issue here is the following: Even though the deltas are all mergeable now (you don't need to maintain causality in order to merge any of...

I've been thinking more about this, and I think that the last example in the illustration I did **is** mergeable because there's some overlap. Two deltas are only mergeable if...