Decentralised EBIAC¶

The chat with Tupaia yesterday got me thinking. They highlighted the importance of mobile apps with a heavy focus on Android, which is not all the unexpected. The way they talked about data integrity was interesting though. The emphasised that whatever is collecting the data needs to be super robust. Admittedly their focus and methodology is perhaps a little different to ours, but the note that it could be several days between getting internet access was a good reminder.

It also got me thinking. What if the app was the whole thing? The server side component being little more than an aggregator, with some smarts around who get to see what data.

How much data are we actually talking about? Estimates for the population of the Solomon Islands is well under a million, somewhere in the region of 700,000. I also think it is fair to say that this system will not need to store data for more buildings than people. I still suspect it is more than is reasonable for a small, cheap android to store. However, I think with a small amount of smarts I wonder if each device is capable of storing the subset of data that is needed for their current operating environment? A province perhaps, with those who are bless with capacious devices to opt-in to additional data.

Architecture wise, the description that Tupaia gave of how they collect the data with multiple questionnaires got me thinking Event Sourcing 🎉. Especially as they describe the processing of merging them as most recent wins. Perhaps each device could hold a snapshot of the current buildings state, then as they complete questionnaires they are effectively added to a local event log and applied over those snapshots in the classic style. Then when an internet connections becomes available all events are pushed to the backend where they are applied and updated snapshots pulled locally, emptying the local event store in the process. By this method the backend acts as an event aggregator, with the local apps actually storing all of the data they need.

I'm not sure this is really a distributed app as the core, the single source of truth is still in the backend but it does move towards the idea.

I guess if the backend is re-framed as an integrity node or similar then it can be thought of as a decentralised system with one (or more) nodes which can be used to onboard edge nodes.

So there are perhaps 3 nodes types involved:

Edge nodes (e.g. mobile apps) (E-Node)
Integrity or data nodes (I-Node) (or S Nodes for Sovereignty?)
Coordinating or Control node (C-Node)

C-Nodes¶

The singular C-Node is the source on truth on users, permission and building attribute schemas.

Questions:

Would these also act as a global data store?

I-Nodes¶

Integrity nodes provide synchronisation services for E-Nodes and pull config data from the C-Node. They could have regions - e.g. the one deployed for the Solomon Islands only holds data for the Solomon Islands.

The fact that these can be co-located, and distributed means you can achieve some degree of data sovereignty. Even if the node itself it not located in the Solomon Islands the data itself would be for them and them alone.

Questions:

Should it reject events for other regions?
Can there be more than one INode for a region, and if so how do the share data?
In addition to regions, could the data also be restricted by profile type (e.g. to a particular user group)?

E-Nodes¶

Edge nodes pull aggregrate root snapshots from I-Nodes and push their own event stream to the them. Edge nodes only contain data for relevent buildings to the person using the device. It could be those within X distance from their designated home. Or a manually selected list of defined regions.

Questions

Should the web-based interface be considered a E-Node, a service of the I-Node or it's own thing entirely?
Can the E-node concept only be realised through the building of a native app or could a web/pwa option also work?
Should I-Nodes be able to talk to one another to share data and how would the inter-service permissions system look to support this?