Support punchr experiment

[Jorropo]

Punchr is a libp2p experiment that tries to holepunch connection.

The goal is to record many holepunching attempts.

This is a binary that runs in the background.

It would be nice if users could optin and then ipfs desktop would run it in the background.

[Jorropo]

Cc @dennis-tra

[BigLep]

I completely agree with this. I was thinking during IPFS Camp on how we could leverage IPFS Desktop as a way for probelab (and others) to run experiments for making p2p networks better. Ideally one can see all the experiments running, click to learn more, and opt out of the ones they don't want to run.

[whizzzkid]

@SgtPooki I think adding this should be trivial, however that being said, having new "Labs" section to host such experiments in the future could be valuable.

[SgtPooki]

@BigLep @whizzzkid This is absolutely what I was thinking with a feature & service toggle and marketplace within IPFS Desktop. I would love to make this happen.

However, after the roadmap discussions and labweek over the last few weeks, I think the goal of ipfs-desktop is first to meet the "Any/All Kubo functionality Via UI" expectation, and then add the enhancements (like this one) beyond that foundational feature set. I think P2 is pretty relevant, but could potentially be P3.

I don't know if this would have as much value by the time this hits our task-list.

[SgtPooki]

We talked about this 2022-11-22 backlog grooming and we decided this should be prioritized immediately after StarMaps work. Initial Proposal:

1. Enable punchr by default for all users
2. Allow users to disable Punchr in settings screen (no additional screens for now)
3. Use release notes to indicate this new functionality instead of spending time working on in-app notification

cc @tinytb

[BigLep]

A couple of thoughts:

1. I think this can generalize into a broader narrative for "enable researchers to run p2p experiments". Punchr is an example.
2. Before we do any engineering work here, lets make sure we have holistic plan around:

• How we brand and communicate this.
• We get signal from #probelab on this being useful for them and other researchers
• We do the design work for how other binaries are distributed from a signing/notarizing regard
• We do the design for what the experience is for someone contributing an experiment. I assume some sort of json file with title, description, learn more URL, path to binary, etc.

[tinytb]

1. For this particular issue (Support punchr experiment #2310) the hope is to deliver the highest impact work and avoid scope creep; hence, we don't have a "grand plan" around branding/communication, but we will certainly describe what's happening in the release notes, and make it easy for users to opt-out if they wish. In the case of Punchr, we have seen that its impact on resource usage is relatively minimal, so it should be OK to enable by default; this is not necessarily the case for all experiments, and will be carefully considered on a case-by-case basis. There is no particular branding plan at the moment (we are open to suggestions if it's needed) but I think it would be fair to label it as "Punchr".
2. Although we are unlikely to have this in production in time for the December experiment, it will still be useful to include in 2023. From the thread in #probe-lab: "we definitely need users to monitor performance of NAT Hole Punching in the longer term. So adding it to IPFS Desktop is definitely a great idea! Not catching the December measurement campaign for Desktop is fine."
3. Agree with the need to design how to do signing/notarizing any distributed binaries.
4. Agree with the need to list out the information / (json) fields we need for each experiment.

Per #probe-lab, there are other tools which would benefit from running continuously through IPFS Desktop, although they would be more work to onboard (they need some extra instrumentation than what we currently have). But it's good to get the ball rolling on this capability, as there is an expectation for such continued value-add going forward.