IPFS immutable file version control for multi user collaboration (without using Blockchain/Smart Contracts)


I’m desperately looking for a solution for document sharing and version control to facilitate multiuser collaboration and track changes in a trusted, secure, and decentralized manner, with no involvement of a centralized trusted entity or third party.

I found this proposal, however I’m trying to avoid Blockchain involvement due to scalability reasons.

My use case is the following:

  • I’m working on an interoperable reputation system based on SSI, applicable for an open platform economy like the Economy of Things.
  • I would like to have the reputation information (regarding their performance and behavior within the network) for each entity taking part in the Economy of Things stored on IPFS.
  • The reputation document could be a document in IPFS, where each time an entity has had a transaction with another entity, they can evaluate their behavior, modify the reputation document and sign it.
  • It needs to be avoided that the entity that has been evaluated modifies its reputation document in a favorable way without being discovered.
  • That’s why I need a version control mechanism that makes the history of a file (which can be modified by any user) transparent and immutable.

I found something about VersionControl with the aid of Git, which “provides a powerful Merkle DAG 2 object model that captures changes to a filesystem tree in a distributed-friendly way”. but I’m not sure if this matches my requirements.

Add-On: I’m still looking for a mechanism to create some kind of “Proof of Criticism” - to ensure that an entity has the right to modify a certain reputation document because it interacted with the entity that is subject to this reputation document. You’re welcome in case you have any ideas to solve this problem.

Thank you so much in advance!!


1 Like

Bonjour Cécile,

Do you need ordering of events? That is, do you need an entity to know in which order the remote node had interactions with third-party nodes to decide if you will have an interaction with them or to evaluate them properly? I suspect transactions are independant so this shouldn’t be a problem?

Also, do you need “perfect” consistency, where A is guaranteed to have the last update about B’s past behavior before deciding to interact with it? Or can you tolerate to have the records of B’s behavior “up to a recent past” (eventual consistency)? I suspect each interaction is independant and A doesn’t need to know the full history of B as A just have to evaluate the interaction of itself with B. I guess A needs the reputation to decide if it will interact with B in the first place. The only risk is to interact with a peer you wouldn’t if you had the full record. (The risk is not an attack on the whole network where B could hide their reputation to the network.) You can either tolerate to not have the very last record of B before making your decision from time to time, or wait a little for gossips about B to be received.

If you don’t need total ordering of events, and are fine with eventual consistency only, maybe IOTA + IPFS can do the trick.
Granted, IOTA is a distributed ledger, but bear with me: it is not a blockchain but rather a custom protocol they call the Tangle.
You sacrifice total ordering of events for partial ordering, strong consistency for eventual consistency, but you get infinite scalability (the trick is to not ask every node to remember all the transactions in the whole world but only the transactions they care about), zero fees for transactions (the trick is to entice nodes to maintain the ledger not because they will be paid for that, but because their own transactions will be confirmed faster), and very low consumption to be a node (you don’t have a Proof-of-X, you don’t need to verify millions of transactions, you verify a handful from time to time).

Full disclosure: nothing to disclose. I’m not related to IOTA.

The project looks solid and have been around for years, but I never worked with IOTA, so I don’t know how it feels to use it.

There is a POC of IOTA + IPFS, but it seems very basic, so you will still need to code most of your thing.

Hope it helps.

I’m desperately looking for a solution for document sharing and version control to facilitate multiuser collaboration and track changes in a trusted, secure, and decentralized manner, with no involvement of a centralized trusted entity or third party.

@cecilele, this sounds alot like what I am currently trying to create. I want a distributed document distribution and proofreading system that is resistant to censorship even by an actor with the law on their side (i.e. copyright enforcement).

The design as it stands starts with a git remote that pushes/pulls from IPFS. On top of that is another remote that uses IOTA to publicize the current repository state. A React app will then read from the tangle, allow viewing all the forks of a repository, and permit creating and reviewing pull requests.

Statuswise, I’m currently working on some performance issues with the base IPFS remote, but it is pretty much working. The IOTA remote is writing basic signed JSON-LD documents to the tangle, but the content and addresses need to change. The React app is little more than a vision. So, all told, I’m a couple months from usable end-to-end software.

In looking at your requirements, I’m not sure if you need to track all the versions of the reputation document to verify that someone hasn’t improved their own reputation. You might be able to use something akin to peer Distributed Ids which are incrementally generated through signed change messages. This would let you know the origin of all changes.

My test corpus is the Hugo and Nebula Award nominees (the Science Fiction Writers’ and Readers’ awards). I want to publish a collection with slots for the various books. Collaborators then should be able to clone the repo for a book, make changes, and upload those back to the collection. I need some mechanism for determining which of these commits are useful contributions and which are spam or attacks without requiring every user to review every change.

I’ve honestly not figured out how to provide that trusted update feature yet. Sourcecred is using a modified PageRank combined with crypto-tokens for a mechanism that’s in the neighborhood. Distributed databases like OrbitDB or ThreadDB are also a potentially useful tools.

(After all this is done, I also want to add a structure to allow authors to “claim” their books. While this won’t give them the ability to remove content, I want them to have a channel to receive recompense.)

I’ve been reading about iota in the past. Using a tangle makes it pretty scalable but it has the coordinator node problem that makes it not fully decentralized. This link explain the problem very well.

When I was read about iota there was no coordicide, maybe I’ll take a look at the whitepaper

Yeah, IOTA is in the midst of some massive churn. There are four different network servers in three languages currently under development:

  1. IRI (IOTA Reference Implementation) is the a java program that runs the bulk of the mainnet.
  2. HORNET is a go program that is the successor to IRI, which adds autopeering and performance enhanchements.
  3. GoShimmer is the prototype Coordinatorless network (in go).
  4. Bee is a rust program that aims to be the major implementation post Coordicide. It includes reusable addresses, an unspent transaction (UTXO) model that will enable colored coins, and

I really like the energy efficiency of the tangle relative to a mined blockchain. Bitcoin has a carbon footprint comparable to Syria. IOTA transactions confirm two others to validate themselves. Though there is a proof-of-work to mitigate spamming, it is relatively small and constant in complexity.

That combined with the lack of fees makes it a strong contender for applications that want to transmit data P2P.

The biggest drawbacks are the lack of maturity. Best practices are frequently in flux. I was unable to post to the tangle for several hours the night before last because the public node I was using started complaining it was overloaded, and the HORNET node I’m running locally wouldn’t synchronize.

It was a minor issue for me at the time, but I’m working on utility software and those sort of outages are a relatively big problem.

Also, in the long term, messages will not be persisted. You need to arrange some way to persist your data in the tangle over the course of years. AION makes IRI a “selective permanode”, and similar functionality is planned for other network implementations.

I don’t think I need the exact ordering of events, however I guess I might need the “perfect” consistency. I’ll have a look into the tangle data storage using IOTA and see if this could be the solution. It sounds interesting.

Thanks a lot.

nice, it seems like we are looking for similar requirements. I need to take a closer look at the components you suggested and see if it fits my use case.
You’re right, maybe I could use signed change messages to track changes in the reputation document.
I am a bit skeptical about IOTA, but I don’t know too much about it.

I would like to be kept up to date on your work

thanks a lot

This can probably be accomplished using the metadata capabilities of IPVFS.

GitHub - anywhichway/ipvfs: Creates and manages diff versioned files in an IPFS store.