Move to IPFS org?

[hannahhoward]

What

go-data-transfer does not have any references to filecoin specific concepts. It is intended to be largely protocol and payment scheme nuetral, and could be used over any libp2p protocol (maybe HTTP later).

While the libp2p protocol is currently unfortunately namespaced as /fil/data-transfer, we're gonna change it with v2 anyway.

Weighing Pros and Cons

Pros

• the reasons stated above
• go-data-transfer is intended to be a general purpose tool
• greater understanding this is a more generic tool
• nice to be in the same org as go-graphsync
• folded into ipfs CI + possibly release process
• could become part of the IPFS spec? Or maybe it should be a FIP for Filecoin

Cons

• not currently in go-ipfs, not on the shortlist to be incorporated
• lotta work
• does this complicate rather than clarify stewardship?

[aschmahmann]

No strong feelings either way, I don't think which org the repo is in really effects most of the things you've listed. Projects in the IPFS org have plenty of external dependencies so that's not really a problem here (note for CI most of it comes from https://github.com/protocol/.github and is used in various orgs like libp2p, ipfs, and ipld).

Whether changes should be FIPs or specs in the IPFS specs repo is 🤷‍♂️. IPFS specs are going to end up drawing from other specs (e.g. referencing various libp2p specs) and people building IPFS applications may very reasonably build IPFS components that leverage specs governed outside of the IPFS specs repo (e.g. the various IPLD related specs, specs for systems like BitTorrent, etc.).

If, from a messaging perspective, it seems like Filecoin's branding is "too strong" and so folks will assume anything under the filecoin-project org is specific to Filecoin and not consider its utility beyond Filecoin then moving it seems reasonable. If doing this it might be worth putting together an example that demonstrates using this for something not tied to Filecoin.

Perhaps an easy non-Filecoin example would be setting up a mock service that gives users a retrieval "account balance" and then charges their account as they download and expects some out-of-band refilling of their balance. This might be relatively straightforward since it mimics how go-data-transfer is currently used, but without any Filecoin specific tie-ins (some of the examples in this repo might already be pretty close to this).

[arajasek]

I think this generally makes sense, and would be supportive, if we think the work is worth it. I'm sure there'll be some grief / breakages that arise from the change.

Re: the third con:

does this complicate rather than clarify stewardship?

I think this clarifies stewardship in terms of the communities and technology (at least from my Filecoin-y perspective). For the most part, so-called "core devs" & users of the Filecoin ecosystem are not familiar with, or contributing to, go-data-transfer. It maybe makes the people involved a little less clear (@hannahhoward are you contributing to this repo as a Filecoin steward or an IPFS steward? Both?), but I think that's a less important thing to keep clear.

The question around FIPs is an interesting one, and is a broader discussion. For clarity of the Filecoin protocol and impls, it's great to have every change FIP-ped, and certainly Filecoin's strong gravity motivates people to write FIPs for such changes. As an example, upcoming changes to Drand are planning on being FIP-ped, even though Drand is certainly not only used by Filecoin.

We probably need to draw some demarcation around what deps-changes need a FIP and what doesn't -- an obvious suggestion could be anything consensus critical must be FIP-ped, and others are optional? I think this is an interesting topic to bring up with @kaitlin-beegle. It feels a little burdensome to demand all dependencies of Filecoin have their changes run through the FIP process, but at the same time it's pretty important to the Filecoin network that we have awareness of important changes, and some input into the rollout timeline.

[hannahhoward]

Based on commentary, I'd like to see where we end up with Data Transfer v2, which will be much closer to the original design goals of go-data-transfer than v1. (but don't worry -- it's backward compatible!)

[kaitlin-beegle]

Re: @arajasek's comment above, I do not believe dependency issues require FIPs, but they do require better governance per se.

This could come in the form of some type of change log, etc., or else revamped documentation that points to these dependencies and their associated repos/docs. I'm also inclined to think that this is a good use-case for the new FRC process.

[jennijuju]

do we have an update on what the scope of dt v2 ?