search

federatedbookkeeping / federatedbookkeeping.org

A website about Federated Bookkeeping
0 stars 1 forks source link

List our Axioms #7

Open michielbdejong opened 2 years ago

michielbdejong commented 2 years ago

The current definition of "it basically builds credit networks on top of e-invoicing" is maybe a bit weak and generic. Maybe we can be more specific about what we try to build and how it's different from blockchain / RDF / DHTs / CRDTs.

The two sovereignty requirements from https://gitter.im/federatedbookkeeping/community?at=6294d8c5f8daa71e07a597fe kept coming up a few more times this week. And also how it links to requirements for data virtualization, and possible also Event Sourcing as we discussed today.

So maybe our axioms would be something like:

Axiom 1: Connected

Live data through machine-readable messaging channels

Axiom 2: Sovereign

Only trust your own computer

Corollary 1: Event Sourced

Caching is hard, and using a straightforward database in each connected node would quickly lead to potential race conditions. There are different ways of describing the architecture of a software system, but the most applicable one given the two axioms might just be Event Sourcing, i.e. keep track of the local events and of the messages coming in from other nodes, and from those, build the view of the world.

Corrollary 2: Data Virtualization

As different connected nodes in the network each only trust their own computers, they are going to have different internal data formats and different machine-readable interfaces. So there is no way or need to agree on a single data format.

michielbdejong commented 2 years ago

Not sure if "event sourced" is really a corollary, but I do feel there is at least a little bit of a causal connection there.

michielbdejong commented 2 years ago

Similar to 'event sourced', 'shard by authority' might be more of a best practice than a corollary, actually.

michielbdejong commented 2 years ago

Maybe we should keep the term Federated Bookkeeping technology-agnostic, describing the goal functionality, and then formulate things like connectedness, sovereignty, polyglot as USPs of our various implementations. So will move these thoughts elsewhere, for instance to https://prejournal.org/ or https://github.com/federatedbookkeeping/research/issues/29

michielbdejong commented 2 years ago

Still left with a feeling we need to improve our definition. What came up in Thursday's call re "integrity" and "consistency" may provide a good basis.

setting

In general, "a network of connected but sovereign computer systems" is just a description of "the internet". :) But it's good we describe it to create the setting, defining one or more settings with systems, channels, users, events, and desired qualities like integrity, eventual consistency, etc.

task

e.g. EDI or federated timesheets

desired properties

eventual convergence, etc

solution ideas

e.g. two-way sync with identifier mapping, CRDT, linked data, SSI, CLOGS, etc.