I started to reply, then went and read the protocol, then removed my reply and started rewriting.
So, if I understand correctly the Index contains every files, and every file contains a Version index which contains in turn all the versions which all of the nodes see of a given file, but these versions are independently sequenced, so there is no way to tell which was before any other one.
(If there’s a new connection does it result a new Index to be received? Does it simply override the previous one in case of different values? I mean cases like having two clusters with no connection to one another, and I connect them together.)
I see no sign in the protocol to try to syncronise time and no requirement of ntp sync, so I guess nodes may use any wild time settings they like. (It’s weird that not even ClusterConfig tries to get info about that.) The only time I see is modified_s (and there is a possibly typo in the document about it, it’s mistyped as “modified_ns”, I have sent a PR) but that seems to be whatever local time the node believes in.
Is there any assurement that all nodes see the same Version list? How do they decide which is last? When I Request block1 of the file which do I expect to get from the Versions list? (Or maybe the Version Value is a globally enforced sequence? If not, how to tell which happened last? If yes, then we have a global enforced order?)
So, basically, audit log contains the last action on the file as one of any of those modifications which were not yet received by the given node for the given file (so it’s quite possible that there were plenty of actions on the file which are lost because they were not received either but only [random] one of those can be received), but on the record it is the real originator of the last change (where “last” means the one we received labeled as “last”, independent of the real sequence of time of the actions), and not any of the relays.
And if I understand correctly there is no sign of conflicts and conflict resolution throughout the protocol, apart from the filenames created by failed resolutions, so there’s no way to el whether a file was really updated or just a result of a conflict resolution. It is important when a file gets screwed up and you look for the one to blame - it is quite possible then that the one on the audit trail was simply doing automatic conflict resolution.