Architecture - representing multiple Fediversity systems #11

New issue

Open

opened 2024-06-20 17:08:53 +02:00 by taeer · 1 comment

taeer commented

2024-06-20 17:08:53 +02:00

Collaborator

The architecture diagram shows how a single institution's Fediversity setup would look. But how does this combine when multiple institutions set up on the same cloud provider? What parts are shared between cloud providers?

My initial thoughts, from top to bottom of the diagram:

NixPanel and NixConfigs is going to be separate for each institution.
NixDefinitions is shared at every level. The usual case is that everyone is using the same NixDefinitions. If it were to be customized, it would be at the level of the cloud provider.
NixOps as a system is the same for everyone, but the state database is per-institution
NixGuard/NixAuditor I'm not sure. Presumably they're per-institution
NixOS Instances and Services is the big question. How much is shared vs. siloed? Can we deduplicate stuff effectively? What are the security implications?
Physical infrastructure is per-cloud provider, shared between institutions.
(not shown) The Fediverse, connecting all of the different instances of the services, plus connecting to instances not running on Fediversity systems.

The [architecture diagram](https://git.fediversity.eu/Fediversity/meta/src/branch/main/architecture-docs/architecture.png) shows how a single institution's Fediversity setup would look. But how does this combine when multiple institutions set up on the same cloud provider? What parts are shared **between** cloud providers? My initial thoughts, from top to bottom of the diagram: - NixPanel and NixConfigs is going to be separate for each institution. - NixDefinitions is shared at every level. The usual case is that everyone is using the same NixDefinitions. If it were to be customized, it would be at the level of the cloud provider. - NixOps as a system is the same for everyone, but the state database is per-institution - NixGuard/NixAuditor I'm not sure. Presumably they're per-institution - NixOS Instances and Services is the big question. How much is shared vs. siloed? Can we deduplicate stuff effectively? What are the security implications? - Physical infrastructure is per-cloud provider, shared between institutions. - (not shown) The Fediverse, connecting all of the different instances of the services, plus connecting to instances not running on Fediversity systems.

roberth commented

2024-06-26 13:07:40 +02:00

Contributor

Minor suggestion:

"organization" instead of "institution"?

Perhaps a useful distinction is The Software vs The Data:

software
- only changed by
  - Fediversity developers
  - Other developers, through forking, or perhaps "power user" features that might even be feature gated
- includes
  - NixPanel
  - NixDefinitions
  - NixOps + relevant resource implementations
  - Guard/Auditor
data
- only changed by users through
  - NixPanel
  - automated processes
  - perhaps occasional tweaks by system operators.
- includes
  - NixConfigs: set of Nix modules generated by NixPanel
  - NixOps state: generated and maintained by NixOps, in part derived from NixConfigs, in other parts from Guard perhaps

That doesn't define (yet) how many instances we have of those data stores, but I think it's a useful framework that we could refine as we learn more about the design and/or its application in practice.

Minor suggestion: - "organization" instead of "institution"? Perhaps a useful distinction is The Software vs The Data: - **software** - only changed by - Fediversity developers - Other developers, through forking, or perhaps "power user" features that might even be feature gated - includes - NixPanel - NixDefinitions - NixOps + relevant resource implementations - Guard/Auditor - **data** - only changed by users through - NixPanel - automated processes - perhaps occasional tweaks by system operators. - includes - NixConfigs: set of Nix modules generated by NixPanel - NixOps state: generated and maintained by NixOps, in part derived from NixConfigs, in other parts from Guard perhaps That doesn't define (yet) how many instances we have of those data stores, but I think it's a useful framework that we could refine as we learn more about the design and/or its application in practice.

👍 1