Risks of using GitHub to run Filecoin Plus processes & operations

[AlexxNica]

We need to explore and review the risks of using GitHub as the platform in which we run Filecoin Plus processes and operations.

Reasoning: There have been cases of accounts and organizations being suspended from GitHub for apparently participating in Filecoin Plus through GitHub.

Today, we have repositories with lots of interaction from either new accounts or accounts without proper verification and identification. In the eyes of GitHub, this certainly doesn't look so good, and it's not clear this is within their terms of service.

Risks

We risk having our repositories shut down as soon as GitHub deems that the program's activities are not covered by their terms of service. If this happens, we also risk losing the whole filecoin-project organization. Exploring this further and finding mitigations should be taken seriously and handled appropriately.

I suggest we explore this and get further guidance from legal.

Some possible solutions (prior to legal and community feedback) that I can think of at the moment are:

Short-term

1. Move our repositories and processes to another GitHub organization focused on the Filecoin Plus program.
2. Talk with GitHub staff to get their feedback and take on this.

Medium to long-term

1. Develop or use a platform to handle our core processes and use GitHub as the public forum for program and governance discussions, feedback, etc.

Please share your thoughts and feedback, and let's find the best solution and mitigation plan together.

---

Current, planned, and proposed mitigations

• Modification: Store LDN application in JSON files #839 from @panges2
  • The proposal partially mitigates some risks if implemented.
  • The proposal is to store applications as files, similar to what @dkkapur suggested below (Risks of using GitHub to run Filecoin Plus processes & operations #793 (comment)).
  • The proposal makes it easier to do backups without the overhead of parsing every issue and comment (partially–see note below).
    • Note: We'd still need to save data from issues and PRs for complete history backups. Also, for now, the proposal only targets LDN applications.

[flyworker]

Web3 Path

• Use DID
• submission move to IPFS and backup to filecoin

Advantage

• more web3 native
• history will be stored for long term
• a good use case for ipfs/filecoin

Constrain

Hard for web2 users submit the application

[flyworker]

Web2 compatible solution:

Using GitHub as an OAuth2 for account sign-in.

Advantage

Compatible with web 2 user experience

Constrain

We still have an issue if GitHub bans the OAuth2 function, but it will be very unlikely to happen.

[AlexxNica]

It can be one way, but I don't know how much that helps mitigate risks specific to the platform (GitHub in this case). That might help if using OAuth is considered a good thing from GitHub's perspective, but even then we'd still be relying on GitHub for all operations.

[dkkapur]

Alt: switch to using GitHub more natively as a db of Fil+ data, i.e., switch from using Issues to instead tracking application-data-as-code, where applications come in as PRs and get committed.

This way, application data is persisted, even if accounts are banned.

We can then take this and back it up to Filecoin/IPFS as well, as a long-standing backup.

[AlexxNica]

Useful links about GitHub policies:

• https://docs.github.com/en/site-policy
• https://docs.github.com/en/site-policy/github-terms
• https://docs.github.com/en/site-policy/acceptable-use-policies

[orvn]

I've made some notes in #891 that proposes a more effective system design for the interoperability of Github and Fil+. These have arisen out of necessity, as we worked on enhancements to filplus.storage.

Of note are some additional points around the idea of using Pull Requests instead of Issues on Github, as @dkkapur mentioned above.