can you link to the repo?
btw, if you are looking for a tangle to test this on, may I suggest one of my sailing story threads, such as Auckland->Wellington
I wrote many posts while completely offline, meanwhile others were speculating as to where I was, then I regained connectivity, and responded to some of their questions, as well as my messages becoming available - but then I lost connectivity again! Also, I'd argue that the way manyverse currently sorts it is wrong. For example, it shows all my offline posts first, then the chronologically earlier concurrent posts.
I havn't had a chance to read everything yet but I noticed this:
Sorting elements that obey partial order can be done with a topological sort algorithm that assigns to each element a rank. We will make use of the rank, which is an integer value, to reflect logical time: elements that are concurrent are ranked identically while a happened-immediately-before relationship
results in a rank difference of exactly one. In Figure 3, arrows show this “happened-immediately-before” relationship. The result can be represented as a sequence of sets {D,E}{B,C}{A}{F} where each set contains concurrent events
Technically speaking, this is a perfectly valid topo sort, but I'm not sure it's really the best answer. Strictly speaking, any rank 0,1,2 is a valid topo sort for C.
A hash pointer isn't "happened immediately before" it means "happened sometime before"
But if this method is scalable and still eventually consistent then maybe that's more important.
@cft Topological sort is for sure desired, but to disambiguate situations like the one Dominic pointed out, when the topological sort doesn't see a rank difference between two nodes, you can use the message's timestamp. Of course timestamps aren't authoritative because each peer can choose whatever they want for the timestamp, but when the topo sort isn't enough, they provide valuable information for the sort. It's not interesting for the paper, but it's surely important in the library to improve user experience.