Git alternatives - propagating changes

[MeanMangosteen]

We are currently going to use git to propagate changes and version control our secret bundles. The main reasons for this is that it more or less suits our needs and it is well understood system. It will also aid building a prototype quicker. Below is a discussion of possible version control/ propagation styles and some reasoning why Git appears to be the most appropriate solution for Polykey. In the future it is possible that a custom/hybrid solution will be used.

Some background on the qualities/properties of secretes:

Changes to secrets are atomic. There is partial change to a secret. Like in source code. You would never change part of a private key, you would completely replace it, nor would you make rapid incremental changes to something like a password or passport information. That is to say secrets' state have low coupling with their previous state. In this case the usefulness of delta dimishes as the benefit they provide is that is saves storage overhead by sequentially applying the detlas in the order that they happend until the desired state is reached. But since for Polykey when there is a change for a secret, it will most likely be completely new content, the delta will almost be a snapshot.

Snapshots make sense when you have small data size, and if there is low coupling with previous state. Polykey hits both.

Also to consider that previous states of a secret are less likely to be of value to the end user. Unlike source code where you might want to revert to a source that provided a stable stable, a previous state of a secret generally would mean that it is state.

There is also no use for multiple branches with dealing with secret bundles, as there is no apparent benefit.

Git uses a tree data structure for version control. It stores snapshots which are complete states of an entity every time an it is committed. Once pushed to a repository, key nodes can the pull the changes when they desire and reach eventual consistency.

As we can see we are not really using the version-control features of git, more as a way to bring some consistency to the distributed system.

Another possible solution is event sourcing. Event sourcing is a pattern that allows us to persist and entity from a series of events. That is it uses neither delta nor snapshots, but events result in state change. Traditionally to persist an object you would save it's state, but with ES you store sequence of state chaning events. It guarantees that any changes to an entity's state is initiated by an event. This allows us to do a complete rebuild of the state by rerunning the events from an empty application. It also provides an audit trail of how the current state came to be. This isn't really beneficial wrt to Polykey since we generally only care about the current state of the secret. Previous states are not that useful to us.

If the events store temporal information then we can do temporal queries, i.e. determine the state of the application at any point in time. Again not that beneficial for Polykey.

The event store can then expose an API for retrieve an entity's events. The store can also allow services to subscribe to events. When an event is persisted in the event store, it can deliver the event to all interested services.

This can be useful in Polykey as Keynodes can subscribe to events that relate to the secret bundle it contains. We would also then have to think about what exactly defines an event in Polykey. We also are currently explored a pull based model. Perhaps it can be extended to a pull-push based model in the future.

Since it appears that we are utilising more of the propagation functionality of the git more than the version control, perhaps exploring avenues such as implementing the raft algo or a variation of dat which is currently used for dynamic large binary blobs, as git currently seems best as only an interim solution.

[CMCDragonkai]

I may not have mentioned this before, but Irmin is potential alternative to using Git directly: https://www.infoq.com/presentations/irmin

Irmin is written in OCaml, but it is possible to compile it to JS. It's also Git compatible.

• NPM talex5/irmin-js#2
• Compile to javascript and use it as local storage mirage/irmin#117

[CMCDragonkai]

So we are definitely using git and not changing to anything else for now. However I think irmin is worthwhile to explore, it seems really fascinating but so difficult to make use of. In Polykey such a database would have to be compiled to JS and sufficient usage documentation would have to make sense. And I'm still trying to figure out in what sense it is distributed. Seems like the distribution is your own choice and you have to figure out how to merge things.