World Ledger Gossip Protocol

[michielbdejong]

A bilateral ledger on top of Solid would more or less work as follows:
Say Alice and Bob went to lunch, and Bob paid 20 USD for both of them. Alice then stores a record in her pod saying she owes Bob 10 USD for lunch. Next time, maybe Bob stores a record saying he owes Alice something. These amounts add up and even out in a bilateral ledger between Alice and Bob. But how can we implement it in such a way that Alice and Bob both have a complete copy of the data in their pods, but this data doesn't go out of sync?

So far, we did this with SNAP which I implemented last year and presented at Solid World.

Now, I'm thinking we should use a more generic messaging language, which would also support communicating about ledger entries without negotiating them at the same time.

[michielbdejong]

See also https://michielbdejong.com/blog/25.html

[michielbdejong]

And https://m-ld.org/

We don't need to have one single way to gossip, there can be multiple. For instance, download a csv from your bank and upload it through Solid UI. The point is our code needs to be good with data provenance, and I think with AccountHistoryChunk#mutations and AccountHistoryChunk#mixIn we have a good basis.

Still, this issue needs to stay open to track implementation of messaging protocols.

[michielbdejong]

A simple way would be to just send your peer arrays of AccountHistoryChunks, so they can directly mix those in with their existing data if they trust you as a data source.

[michielbdejong]

May need additional formats to express invoices, purchase orders, etcetera, but in general, if we just express those in RDF then they can be gossiped using simple Turtle documents.

[michielbdejong]

Maybe it gets interesting if you want to split up a data set into incremental messages that refer to a parent in the data tree. You need to uniquely identify world ledger accounts, then indicate if a list of mutations is exhaustive, and also a measure of how sure we are that these mutations took place - have they been reported by (both) the parties involved, or are they implied secondary / tertiary channels?

[michielbdejong]

When a legal entity uses multiple accounts in its bookkeeping, (e.g. writing off goods over time, budgeting between departments) then there may be some level of ambiguity about whether or not a transaction took place, or about the details of a transaction. For instance, maybe in one record a given purchase was paid for from the 'groceries' budget, and in another one it was paid for from the 'food' budget. If you then merge those two records, you get errors in the resulting ledger because the transaction would be entered twice. I guess there's not much we can do against that, apart from maybe adding machine-readable details that indicate e.g. "budgeting transaction X corresponds to payment-in-shop transaction Y"