IPLD-based Version History
This is just a sketch of a possibility. If we just want a git-style toolchain with git version graph, it might be better to just put an ipfs storage adapter behind go-git -- basically putting IPFS unixfs trees where git usually creates git tree objects. In that case you would have regular git commit objects, not IPLD objects. That would be less reusable beyond the git context but it would fit better with existing git-based tooling.
Keep in mind: it will be really useful to be able to use IPFS files api to manipulate these trees, allowing you to do things like modify part of a large dataset and commit the changes without ever pulling the whole dataset -- you can just pull the parts that you're changing.
- Cryptographically-tracked version History
- Metadata (both required and optional) for commits in the version history (author, timestamp, log message, gpg signature)
- Named Branches and "refs": mutable names that point to commits
- View log history
Some commands we need in the version-control toolchain
ASIDE: What is an MVP here? We don't want to recreate all of git. Just want to provide clear, reliable tools for creating version history layer in IPFS.
ipvc repo init <repository-name> / initialize a new ipvc repo in ipfs & generate an ipns name for it
ipvc repo list / list all local ipvc repositories
ipvc clone <repository-hash> / pull the repo corresponding to <repository-hash> onto the local machine
ipvc commit <ipfs-hash> / add as the new head
ipvc rebase -r <repository-hash>
ipvc log
ipvc repo add
Version entry (modeled on git commit objects):
Example of git commit object: TODO: get a real, complete example with gpg info
commit QmUmg7BZC1YP1ca66rRtWKxpXp77WgVHrnv263JtDuvs2k
Author: Ada Lovelace <ada@lovela.ce>
Date: Fri June 22 18:15:24 1833 -0000
Expressing this information as IPLD:
{
"commit": {"/":"/ipfs/QmUmg7BZC1YP1ca66rRtWKxpXp77WgVHrnv263JtDuvs2k"},
"message": "this is a commit message",
"parent": {"/":"/ipfs/d1c37bcb9f75ac4fba968b47db9dcbd697bd453a"},
"Author": "Ada Lovelace <ada@lovela.ce>",
"Date": "Fri June 22 18:15:24 1833 -0000",
// optional gpg signatuure info
"signature": { // gpg signature info }
}imagine that the hash of this is
Version History:
{
"head": {"/": "../versions/0"}
"versions": [
{"/":<hash-of-v3>},
{"/":<hash-of-v2>},
{"/":<hash-of-v1>}
]
}
}imagine that the hash of this is
Make the ipns entry point to
Example IPLD paths:
/ipns/<ipns-hash/head
/ipns/<ipns-hash/head/commit
Equivalent of git cat head^2
/ipns/<ipns-hash/2/commit
which resolves to the same thing as
/ipns/<ipns-hash/1/parent/commit
I was curious if there's any reason this couldn't include the sorts of versioning we find in, say, undo history or something like the sort of version management you commonly find in cloud services (typically triggered by file modification, I suppose). While certainly I agree git should remain git, only to be enhanced as such through harnessing its capabilities to those of IPFS by way of IPLD, I feel like there's some opportunity to broaden what's meant by version control--something that I imagine would not be precluded in IPVC.
It might be that IPFS just isn't suited to the sort of dynamic fine-grained versioning I have in mind, but I have some idea of how such a thing might be accomplished: I imagine some interplay of private nodes and clusters, where at some local or application level you have your undo history (a file being broken down by each edit in some live and dynamic fashion, perhaps dictated to some degree by the application); then you have a cluster of private nodes at perhaps a network or cloud level where each file modification is tracked (imagine something like Peergos having version history built-in); and while generally your undo history might only be needed at the local or application level, this sort of standardization could make it completely portable and appropriate to extend into your personal network or cloud (in some cases, like live collaborative editing, this undo history might even have to be shared).
Furthermore regarding undo history, this could easily allow for nonlinear undo in text editors, vector design, and photo editing. Perhaps it would even enable better LFS-like versioning for vector and raster images, maybe by sort of squashing the undo history with each save and squashing those saves for any commit which includes them (meaning that the same way in which the edits might be tracked with an application could be applied to broader sweeping changes at the commit level, though perhaps one could optionally just track the entire history down to the undo level with each commit, perhaps even allowing rebase-like squashing of any portion of that undo history at any time).
As an aside, I was thinking about how it might be possible using pubsub and CRDT to handle forking and pull-requests. I'm not quite sure how something like that would work, but I think that it can be made functional at the level of IPVC and then amended to allow for more GitHub-like social functionality by whatever application might choose to implement IPVC (ideally also using pubsub and CRDT, and Issue tracking could be done in the same manner, obviously remaining separate from the actual version-control system but tied to it in some standardized fashion, perhaps by way of providing a specification).
These are all ideas I've been rolling around for a decentralized wiki CMS concept (aside from LFS-like versioning, which kind of just came to me as I was writing this), but I think there might a case for deeper and more standardized integration with the core IPFS ecosystem and was interested to hear your take on the matter.