Bringing Git to the distributed Web

[Arlodotexe]

Background

• Original (outdated) proposal: https://github.com/Arlodotexe/strix-music/issues/201.

The original thread spawned some interesting ideas, and I'd like to clearly separate them so it can be refined and discussed as needed.

What if we went all in?

If I had unlimited time and resources, what would I build?

Decentralized Git remotes

• We can bridge between existing git repos and IPFS.
• A custom git command could use IPNS as a remote branch.
• Converts Git objects to native IPLD behind the scenes.
• If you've got the IPNS key, you've got repo push permissions.
• Forks have no permissions but could make a pull request to the author (manually, unless an IPFS-based github alternative exists)
• IPNS needs to be more resilient first.

See also:

• https://github.com/ipfs/go-ipld-git
• https://github.com/ipfs-shipyard/git-remote-ipld

Decentralized GitHub alternative

• Using all of the above, we could build a decentralized website that can replace GitHub
• All data would be 100% IPLD, IPFS and IPNS.
• The website would start on a dedicated gateway and be re-hosted by user's local nodes when possible.
• Your own content is pinned on your local node
  • Repos
  • Profile
  • Open PRs / issues
  • etc
• Other people who view your data, temporarily re-host it (e.g. opening a PR page caches the PR data locally)
• Paid service where we host your data for you?
• Works completely offline
• Encryption + Private IPNS networks = private, secure, self hosting, self distributing
• Repos / user profiles are based on an IPNS url
• Anyone with a repo's IPNS key
  • Has full repo permissions
  • Can change platform settings
  • PRs must be merged by "code owner".
  • Can give others selective permissions by
  • Supplying an IPNS/permission of the user
  • Emitting pubsub the user's permissions changed on a repo
  • User sees this and accepts.
  • If not online during pubsub, manually check repo settings for yourself on startup, and accept..
  • Admin can now point people to a value defined by a different user, usable for settings
• Any identifiable user with the IPNS URL can
  • Clone the repo
  • Open issues / PRs
  • Needs abuse prevention
• IPNS needs to be more resilient first.

Native Git support

This one is a bit more "out there" and should have probably been binned, but let's write it down anyway.

• Uses a fork of Git that integrates with IPFS directly and natively
• The bridge between traditional git repos and IPFS no longer needed.
• Instead of .git folder, use a single .git file with the current IPLD CID.
  • This CID will change as you change the repo
  • This CID is analogous to the entire .git folder
  • Points to IPLD data containing all git info needed to operate.
• Points to native IPLD data, not raw files on disk.
• Local changes will change the CID of your repo
• Git no longer needs to do GC. IPFS does this for us.
• Remotes can now be IPNS addresses
  • Pull commands will fetch the newest CID from IPNS, update the files for that branch, then stop executing.
  • Push commands publish the current local CID of the repo to IPNS
• If we went 100%, all out, we could use the same hashing algorithm as IPFS for git blobs
  • Blob pointers in the IPLD repo data could match the full files uploaded to IPFS.
  • A minor optimization that could make a big difference in the long run

[Arlodotexe]

Adding this from a discussion on Discord.

Well-designed distributed systems can operate in a centralized or non-centralized context, and (again, when well-designed), that's better because it can operate distributed or like a traditional client-server, where operators/devs host beefy hardware to speed things up for users and the application establishes a direct connection to them out of the box. Making use of dev-operated nodes can be made required by the application, but it's optional under the hood when the application is designed to work distributed.

Gaming is a great example, because you need a powerful server or set of servers everyone connects to, but the way you discover other players and establish the 1:1 connection each one has to a host server node (whether it's beefy and hosted by the dev or hosted by an end user) can be established via distributed or traditional client-server methods. The ability to mix and match distributed and non-distributed design patterns depending on your use case-- that flexibility is powerful, and the integrations between git and GitHub really highlight that.

Ultimately, I think the rest of our dev tooling from GitHub (CI, Pull Requests, Issues) should be just as flexible and local-first as git is.