kiara/fedi-goals
1
0
Fork 1
Code Issues Pull requests 1 Projects Releases Packages Wiki Activity Actions

tweak project proposal #1

Open
kiara wants to merge 95 commits from rewrite into main
pull from: rewrite
merge into: kiara:main
Conversation 0 Commits 95 Files changed 6 +144 -143
1 changed files with 144 additions and 143 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files
Showing only changes of commit 124473fc78 - Show all commits

287
fediversity.md
View file

@ -84,90 +84,6 @@ The use of open-source software, along with the focus on portability, will enabl
The project plans to offer portability of services, allowing users to easily export their data from the platform and import it to another platform.
This is a unique feature beyond what is currently available on the market.
## Technologies used
### [NixOS](https://nixos.org/)
NixOS is a Linux distribution with a [vibrant](https://repology.org/repositories/graphs), [reproducible](https://reproducible.nixos.org/) and [security-conscious](https://tracker.security.nixos.org/) ecosystem.
As such, we see NixOS as the only viable way to reliably create a reproducible outcome for all the work we create.
Considered alternatives include:
- containers: do not by themselves offer the needed reproducibility
### [OpenTofu](https://opentofu.org/)
OpenTofu is the leading open-source framework for infrastructure-as-code.
This has led it to offer a vibrant ecosystem of 'provider' plugins integrating various programs and services.
As such, it can facilitate automated deployment pipelines, including with — relevant to our project — hypervisors and DNS programs.
Considered alternatives include:
- Terraform: not open-source
### [Proxmox](https://proxmox.com/)
Proxmox is a hypervisor, allowing us to create VMs for our applications while adhering to our goal of preventing lock-in.
In addition, it has been [packaged for Nix](https://github.com/SaumonNet/proxmox-nixos) as well, simplifying our requirements to users setting up our software.
Considered alternatives include:
- OpenNebula: seemed less mature
### [Garage](https://garagehq.deuxfleurs.fr/)
Garage is a distributed object storage service.
For compatibility with existing clients, it reuses the protocol of Amazon S3.
Considered alternatives include:
- file storage: less centralized for backups
### [PostgreSQL](https://www.postgresql.org/)
PostgreSQL is a relational database.
It is used by most of our applications.
Considered alternatives include:
- Sqlite: default option for development in many applications, but less optimized for performance, and less centralized for backups
### [Valkey](https://valkey.io/)
Valkey is a key-value store.
It is an open-source fork of Redis.
Considered alternatives include:
- Redis: not open-source
### [OpenSearch](https://opensearch.org/)
OpenSearch offers full-text search, and is used for this in many applications.
It is an open-source fork of ElasticSearch.
Considered alternatives include:
- ElasticSearch: not open-source
### [PowerDNS](https://github.com/PowerDNS/pdns)
PowerDNS is a mature DNS server. It further offers an admin front-end.
Considered alternatives include:
- hickory-dns: no front-end
- core-dns: no front-end
### [Authelia](https://github.com/authelia/authelia)
Authelia is a single sign-on provider that integrates with LDAP.
Considered alternatives include:
- KaniDM: does not do proper LDAP
- Authentik: larger package with focus on many things we do not need
- Keycloak: larger package with focus on many things we do not need
### [lldap](https://github.com/lldap/lldap)
Lldap is a light LDAP server, allowing to centralize user roles across applications.
Considered alternatives include:
- 389 DS: older larger package
- FreeIPA: wrapper around 389 DS
## Identified applications
We have identified a number of applications as potentially relevant targets to offer as part of our project, emphasising the value to users' digital autonomy, particularly to make users less dependent online on services by 'Big Tech'.
@ -429,66 +345,8 @@ We will integrate that aspect into the high level process on a best effort basis
| **Enterprises and public sector**: Organisations can replace proprietary, possibly unethical business software with open source, user-respecting solutions. | **Integration of project output into major open source solutions**: Superior solutions tend to gradually replace legacy technologies and improving standards has a strong effect on the overall marketplace. | **Economic**: ISPs, hosters, network operators, companies and civil society (re)use project output to deliver services that grant users more autonomy and privacy. |
| **Academia and research**: Unlike proprietary ("black box") tools and services, open source solutions are well-suited for academics and private and public sector research as a subject and to experiment with new ideas. | **Usage and (paid) services for enterprises and organisations**: On top of state of the art FOSS solutions everyone can build competitive business and services. | **Economic**: We expect a new economy will start to evolve based on value added support and services for e.g. end-to-end communication, private data storage, federated and decentralised identity management. |
# Quality and efficiency of the implementation
# Implementation and planning
## Architecture
At the core of Fediversity lies a NixOS configuration template containing selected applications.
We use this to deploy to selected run-time environments, so far targeting hypervisor ProxmoX.
We further provide a reference front-end to configure our template.
To ensure reproducibility, we also offer Nix packaging for our software.
To reach our goals, we aim to implement the following interactions between [actors](#actors) (depicted with rounded corners) and system components (see the [glossary](#glossary), depicted with rectangles).
```mermaid
flowchart
user(user) --> |use| deployment
configuration -->|deploy| deployed
devs(developers) --> |maintain| fediversity
fediversity --> |update| provider1
subgraph provider1["fediversity setup A"]
subgraph panel1[panel]
configuration[staged configuration]
configuration --> |update| configuration
deployed[deployed configuration]
end
deployed --> |describe| deployment
provider-config[runtime config] --> |describe| host
provider-config --> |implement runtime interfaces| panel1
subgraph host[runtime environment]
deployment[applications]
state
end
end
deployment --> |store| state
operator(operator) --> |change| configuration
subgraph provider2["fediversity setup B"]
subgraph panel2[panel]
configuration2[staged configuration]
deployed2[deployed configuration]
end
subgraph host2[runtime environment]
deployment2[applications]
state2[state]
end
end
operator --> |trigger| migration
configuration & deployed & state --> migration
migration --> configuration2 & deployed2 & state2
provider(hosting provider) --> |maintain| provider1
subgraph fediversity[fediversity source code]
applications[application modules]
backends[runtime backends]
config[runtime options]
end
```
## Actors
@ -569,6 +427,65 @@ flowchart
Configuration logic specific to a runtime backend, e.g. how to deploy, how to access object storage.
## Architecture
At the core of Fediversity lies a NixOS configuration template containing selected applications.
We use this to deploy to selected run-time environments, so far targeting hypervisor ProxmoX.
We further provide a reference front-end to configure our template.
To ensure reproducibility, we also offer Nix packaging for our software.
To reach our goals, we aim to implement the following interactions between [actors](#actors) (depicted with rounded corners) and system components (see the [glossary](#glossary), depicted with rectangles).
```mermaid
flowchart
user(user) --> |use| deployment
configuration -->|deploy| deployed
devs(developers) --> |maintain| fediversity
fediversity --> |update| provider1
subgraph provider1["fediversity setup A"]
subgraph panel1[panel]
configuration[staged configuration]
configuration --> |update| configuration
deployed[deployed configuration]
end
deployed --> |describe| deployment
provider-config[runtime config] --> |describe| host
provider-config --> |implement runtime interfaces| panel1
subgraph host[runtime environment]
deployment[applications]
state
end
end
deployment --> |store| state
operator(operator) --> |change| configuration
subgraph provider2["fediversity setup B"]
subgraph panel2[panel]
configuration2[staged configuration]
deployed2[deployed configuration]
end
subgraph host2[runtime environment]
deployment2[applications]
state2[state]
end
end
operator --> |trigger| migration
configuration & deployed & state --> migration
migration --> configuration2 & deployed2 & state2
provider(hosting provider) --> |maintain| provider1
subgraph fediversity[fediversity source code]
applications[application modules]
backends[runtime backends]
config[runtime options]
end
```
## Break-down of project milestones
Whereas details of the implementation may need to be decided as the technical challenges involved become clear, we can already give a higher-level planning of relevant milestones and some of their salient features:
@ -615,6 +532,90 @@ Whereas details of the implementation may need to be decided as the technical ch
- [get documentation ready](https://git.fediversity.eu/Fediversity/Fediversity/issues/288)
- [upstream to NixOS](https://git.fediversity.eu/Fediversity/Fediversity/issues/333)
## Technologies used
### [NixOS](https://nixos.org/)
NixOS is a Linux distribution with a [vibrant](https://repology.org/repositories/graphs), [reproducible](https://reproducible.nixos.org/) and [security-conscious](https://tracker.security.nixos.org/) ecosystem.
As such, we see NixOS as the only viable way to reliably create a reproducible outcome for all the work we create.
Considered alternatives include:
- containers: do not by themselves offer the needed reproducibility
### [OpenTofu](https://opentofu.org/)
OpenTofu is the leading open-source framework for infrastructure-as-code.
This has led it to offer a vibrant ecosystem of 'provider' plugins integrating various programs and services.
As such, it can facilitate automated deployment pipelines, including with — relevant to our project — hypervisors and DNS programs.
Considered alternatives include:
- Terraform: not open-source
### [Proxmox](https://proxmox.com/)
Proxmox is a hypervisor, allowing us to create VMs for our applications while adhering to our goal of preventing lock-in.
In addition, it has been [packaged for Nix](https://github.com/SaumonNet/proxmox-nixos) as well, simplifying our requirements to users setting up our software.
Considered alternatives include:
- OpenNebula: seemed less mature
### [Garage](https://garagehq.deuxfleurs.fr/)
Garage is a distributed object storage service.
For compatibility with existing clients, it reuses the protocol of Amazon S3.
Considered alternatives include:
- file storage: less centralized for backups
### [PostgreSQL](https://www.postgresql.org/)
PostgreSQL is a relational database.
It is used by most of our applications.
Considered alternatives include:
- Sqlite: default option for development in many applications, but less optimized for performance, and less centralized for backups
### [Valkey](https://valkey.io/)
Valkey is a key-value store.
It is an open-source fork of Redis.
Considered alternatives include:
- Redis: not open-source
### [OpenSearch](https://opensearch.org/)
OpenSearch offers full-text search, and is used for this in many applications.
It is an open-source fork of ElasticSearch.
Considered alternatives include:
- ElasticSearch: not open-source
### [PowerDNS](https://github.com/PowerDNS/pdns)
PowerDNS is a mature DNS server. It further offers an admin front-end.
Considered alternatives include:
- hickory-dns: no front-end
- core-dns: no front-end
### [Authelia](https://github.com/authelia/authelia)
Authelia is a single sign-on provider that integrates with LDAP.
Considered alternatives include:
- KaniDM: does not do proper LDAP
- Authentik: larger package with focus on many things we do not need
- Keycloak: larger package with focus on many things we do not need
### [lldap](https://github.com/lldap/lldap)
Lldap is a light LDAP server, allowing to centralize user roles across applications.
Considered alternatives include:
- 389 DS: older larger package
- FreeIPA: wrapper around 389 DS
## Work plan and resources
Table 3.1g: Subcontracting costs