C3RES architecture schetchup:

	+--------------+		    +--------------+
	| SHARD SERVER | <-- federation --> | SHARD SERVER |
	+--------------+		    +--------------+
		|
		.
		.
		.
		|		----+
	+---------------+	    |
	| CLIENT DAEMON |	    |
	+---------------+	    |
	  |	|   |		    |
+-------------+	| +------------+    `
| TERMINAL UI | | | HTTP QUERY |     }-- On a local machine
+-------------+ | +------------+    ,
		|		    |
	    +-------+		    |
	    |  GUI  |		    |
	    +-------+		    |
				----+

SHARD SERVER

Contains:

• all the data (shards)
• identity information
• global volatile data (e.g. services, config that should be shared among instances)

Requirements:

• accessible via a stable IP / DNS name
• the address should not change often, as all old identity entries use it as default

CLIENT DAEMON

Contains:

• host-specific volatile data
• cached shards
• private keys

Provides:

• different UIs to access shards / programs
  • terminal CLI / TUI modes?
  • possible GUI support?
  • local HTTP server for supporting browsers / external applications
    • a local access to shards from external web pages
    • (technical note: requires allowing all via CORS)

FEDERATION

Provides:

• quick distribution of shards between instances (via ActivityPub?)
  • e.g. public shards such as blog posts can be federated to a web gateway server
  • group chat messages could be sent to relevant servers proactively
    • though this might need some consideration: might be too much logic / knowledge of data for the server
• sync between two related servers for backup purposes
  • e.g. backing up my data on a friend's server