Compare commits
1 commit
main
...
project-no
| Author | SHA1 | Date | |
|---|---|---|---|
|
9408d0c15e |
41 changed files with 555 additions and 992 deletions
BIN
.DS_Store
vendored
Normal file
BIN
.DS_Store
vendored
Normal file
Binary file not shown.
88
Fediverse-investments-an-estimation.md
Normal file
88
Fediverse-investments-an-estimation.md
Normal file
|
|
@ -0,0 +1,88 @@
|
|||
Outline
|
||||
> Release a report on the estimated collective current investment on fediverse technology:
|
||||
>
|
||||
> Look at qualifiers like:
|
||||
>- Used system resources (CPU, storage, networking)
|
||||
>- Amount of software developers actively working on Fediverse software >products
|
||||
>- Amount of system administration engineers actively working on Fediverse software products
|
||||
>- Amount of moderation and governance people
|
||||
|
||||
* * *
|
||||
|
||||
# An estimate of investments in the Fediverse
|
||||
|
||||
## Introduction
|
||||
To provide an estimate of the investments made into the Fediverse, is a very daunting task due to decentralised nature of the Fediverse, the amount of volunteers contributing freely and - in our experience - a lack of research on this topic thus far. Nonetheless, we have taken upon ourselves the task to provide a first glimpse on this subject.
|
||||
|
||||
[TODO: describe 'the why' better]
|
||||
|
||||
We hope our work will contribute and ignite more serious research into this topic.
|
||||
|
||||
In this document we describe our assessment of the investments made in the Fediverse. We start with how we define the Fediverse, describe our methodology for gathering data on the defined Fediverse and share information on the services, platforms and software applications we have deemed relevant to include.
|
||||
|
||||
[TODO: need to add more info here ]
|
||||
|
||||
|
||||
* * *
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Define the Fediverse
|
||||
We need to define what the Fediverse is.
|
||||
|
||||
Wikipedia defines Fediverse as "a collection of social networking services that can communicate with each other (formally known as federation) using a common protocol. Users of different websites can send and receive status updates, multimedia files and other data across the network. The term Fediverse is a portmanteau of "federation" and "universe". (Wikipedia contributors, 2024)[^1]".
|
||||
|
||||
Erin Kissane & Darius Kazemi in 'Findings Report: Governance on Fediverse Microblogging Servers' define the Fediverse as "a decentralized interoperable network of social media sites, apps, and services built on the ActivityPub protocol.[^2]".
|
||||
|
||||
[ TODO: add the other definitions ]
|
||||
|
||||
|
||||
It seems there has not yet formed consensus on what exactly are the attributes which could define a platform, service or software application part of the Fediverse.
|
||||
|
||||
|
||||
|
||||
## Methodology
|
||||
* Numbers used & why these numbers and not other numbers
|
||||
* Services / platforms investigated
|
||||
* Why these services & platforms?
|
||||
* Software applications
|
||||
* Topic opened: https://socialhub.activitypub.rocks/t/any-info-on-the-estimated-collective-investments-time-money-on-fediverse-tech/4844?u=bjornw
|
||||
|
||||
## A closer look at the Fediverse platforms
|
||||
* Name of service/platform
|
||||
* Description of service/platform
|
||||
* estimated nr of installations
|
||||
* estimated nr of users (Monthly Active Users)
|
||||
* estimated nr of developers working on the service
|
||||
* estimated nr of moderators
|
||||
* estimated costs for the service
|
||||
|
||||
## Estimating investments in the Fediverse
|
||||
* Conclusion
|
||||
|
||||
|
||||
## Notes
|
||||
[^1]: Wikipedia contributors. (2024, December 29). Fediverse. Wikipedia. https://en.wikipedia.org/wiki/Fediverse
|
||||
[^2]: Kissane, E., & Kazemi, D. (2024, September 4). Findings Report: Governance on Fediverse Microblogging Servers. https://fediverse-governance.github.io/#brief-glossary
|
||||
|
||||
|
||||
## References
|
||||
* https://en.wikipedia.org/wiki/Fediverse
|
||||
* https://fedidb.org/
|
||||
* https://mastodon-analytics.com/
|
||||
* https://www.thinkimpact.com/mastodon-statistics/
|
||||
* https://fediverse.observer/
|
||||
* https://the-federation.info/
|
||||
* https://fediverse.party
|
||||
* https://socialhub.activitypub.rocks/t/fep-f1d5-nodeinfo-in-fediverse-software/1190
|
||||
* https://codeberg.org/fediverse
|
||||
|
||||
https://hachyderm.io/@esk/113793277371908181
|
||||
|
||||
|
||||
|
||||
|
||||
3
architecture-docs/.gitignore
vendored
3
architecture-docs/.gitignore
vendored
|
|
@ -1,3 +0,0 @@
|
|||
*.err
|
||||
*.odt
|
||||
.~lock*
|
||||
Binary file not shown.
|
|
@ -1,49 +0,0 @@
|
|||
# fediversity product specification
|
||||
|
||||
## stack
|
||||
|
||||
### user-facing
|
||||
|
||||
- [fediverse](https://www.figma.com/proto/AZbFAac2Xjxs3q1H3orXzO/Fedi-Design-system?page-id=97%3A1682&node-id=97-2257)
|
||||
- ...
|
||||
- prioritize efforts taking in mind
|
||||
- added value to operator autonomy
|
||||
- strategic relevance to counter-balance big tech
|
||||
- demand
|
||||
- nix package/service maturity
|
||||
- may involve relation with application devs to:
|
||||
- [upstream](https://git.fediversity.eu/Fediversity/Fediversity/issues/127#issuecomment-5669) nix package
|
||||
- ensure architecture takes immutable build/storage in mind
|
||||
|
||||
### under the hood
|
||||
|
||||
- nixos
|
||||
- [opentofu](https://opentofu.org/)
|
||||
- passes relevant info on to nixos config wrapper
|
||||
- VM hypervisor: [proxmox](https://proxmox.com/)
|
||||
- storage: [garage](https://garagehq.deuxfleurs.fr/)
|
||||
- backups / data portability: [borgmatic](https://github.com/borgmatic-collective/borgmatic)?
|
||||
- data interoperability: [json-schema](https://json-schema.org/)
|
||||
|
||||
## component architecture
|
||||
|
||||
- orchestration module
|
||||
- application service modules (nixos): templates providing sane defaults and [unified interface](https://nlnet.nl/project/SelfHostBlocks/)
|
||||
- deployment module (opentofu)
|
||||
- deployment UIs
|
||||
- [reference imlementation](https://git.fediversity.eu/Fediversity/Fediversity)
|
||||
- hosting panel: [fediversity integration](https://www.figma.com/proto/AZbFAac2Xjxs3q1H3orXzO/Fedi-Design-system?page-id=97%3A1682&node-id=97-2284) TODO
|
||||
- [front](https://git.fediversity.eu/Fediversity/protagio.nl-frontend)
|
||||
- back
|
||||
- [existing](https://git.fediversity.eu/Fediversity/myprotagio-api)
|
||||
- rewrite?
|
||||
- allow for alternate setups
|
||||
- e.g. client doing orchestration
|
||||
- [infra](https://git.fediversity.eu/Fediversity/meta/media/branch/main/architecture-docs/architecture.png)
|
||||
|
||||
### feature-specific architectural notes
|
||||
|
||||
- [decouple version](https://git.fediversity.eu/Fediversity/Fediversity/issues/304)
|
||||
- [validate component input](https://git.fediversity.eu/Fediversity/Fediversity/issues/195)
|
||||
- [migrate to different host](https://git.fediversity.eu/Fediversity/Fediversity/issues/100) (+ sub-tickets)
|
||||
- [breaking changes](https://git.fediversity.eu/Fediversity/Fediversity/issues/214)
|
||||
|
|
@ -1,34 +0,0 @@
|
|||
// usage: nix-shell -p graphviz --command 'dot -T png -o architecture.png architecture.dot'
|
||||
|
||||
digraph FediversityArchitecture {
|
||||
graph[fontname="Liberation Sans"];
|
||||
node[shape=box, style="rounded", fontname="Liberation Sans"];
|
||||
|
||||
subgraph cluster_frontends {
|
||||
label="front-ends";
|
||||
|
||||
nix[label="NixOS module"];
|
||||
tofu[label="OpenTofu CLI"];
|
||||
panel[label="FediPanel"];
|
||||
protagio[label="NixPanel"];
|
||||
}
|
||||
|
||||
nix -> core;
|
||||
tofu -> core;
|
||||
panel -> core;
|
||||
protagio -> core;
|
||||
|
||||
core[label="fediversity-core"];
|
||||
|
||||
subgraph cluster_hypervisor {
|
||||
label="proxmox";
|
||||
|
||||
nextcloud;
|
||||
vaultwarden;
|
||||
dots[label="..."];
|
||||
}
|
||||
|
||||
core -> nextcloud;
|
||||
core -> vaultwarden;
|
||||
core -> dots;
|
||||
}
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 27 KiB |
|
|
@ -1,176 +0,0 @@
|
|||
# Fediversity Implementation and planning
|
||||
|
||||
## Actors
|
||||
|
||||
- Maintainers
|
||||
|
||||
The group developing and maintaining this project.
|
||||
We are creating the deployment workflows and service configurations, and curate changes proposed by contributors.
|
||||
|
||||
- Developers
|
||||
|
||||
People with the technical background to engage with our work, and may contribute back, build on top of, remix, or feel inspired by our work to create something better.
|
||||
|
||||
- Hosting provider
|
||||
|
||||
They provide and maintain the physical infrastructure, and run the software in this repository, through which operators interact with their deployments.
|
||||
Hosting providers are technical administrators for these deployments, ensuring availability and appropriate performance.
|
||||
|
||||
We target small- to medium-scale hosting providers with 20+ physical machines.
|
||||
|
||||
- Operator
|
||||
|
||||
They select the applications they want to run.
|
||||
They don't need to own hardware or deal with operations.
|
||||
Operators administer their applications in a non-technical fashion, e.g. as moderators.
|
||||
They pay the hosting provider for registering a domain name, maintaining physical resources, and monitoring deployments.
|
||||
|
||||
- User
|
||||
|
||||
They are individuals using applications run by the operators, and e.g. post content.
|
||||
|
||||
## Glossary
|
||||
|
||||
- [Fediverse](https://en.wikipedia.org/wiki/Fediverse)
|
||||
|
||||
A collection of social networking applications that can communicate with each other using a common protocol.
|
||||
|
||||
- Application
|
||||
|
||||
User-facing software (e.g. from Fediverse) configured by operators and used by users.
|
||||
|
||||
- Configuration
|
||||
|
||||
A collection of settings for a piece of software.
|
||||
|
||||
> Example: Configurations are deployed to VMs.
|
||||
|
||||
- Provision
|
||||
|
||||
Make a resource, such as a virtual machine, available for use.
|
||||
|
||||
- Deploy
|
||||
|
||||
Put software onto computers.
|
||||
The software includes technical configuration that links software components.
|
||||
|
||||
- Migrate
|
||||
|
||||
Move service configurations and deployments (including user data) from one hosting provider to another.
|
||||
|
||||
- Run-time backend
|
||||
|
||||
A type of digital environment one can run operating systems such as NixOS on, e.g. bare-metal, a hypervisor, or a container run-time.
|
||||
|
||||
- Provider
|
||||
|
||||
An interface against which we deploy to a run-time backend.
|
||||
|
||||
- Provider configuration
|
||||
|
||||
A configuration that specifies resources made available to deploy to and how to access these.
|
||||
|
||||
- Resource
|
||||
|
||||
A resource is any external entity that we need for our set-up
|
||||
This may include e.g. hypervisors, file systems, DNS entries, VMs or object storage instances.
|
||||
|
||||
## Technologies used
|
||||
|
||||
This is an incomplete and evolving list of core components planned to be used in this project.
|
||||
It will grow to support more advanced use cases as the framework matures.
|
||||
|
||||
### Nix and [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
|
||||
|
||||
### [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
|
||||
|
||||
## Architecture
|
||||
|
||||
At the core of Fediversity lies a NixOS configuration module for a set of selected applications.
|
||||
|
||||
- We will enable using it with **different run-time environments**, such as a single NixOS machine or a ProxmoX hypervisor.
|
||||
- Depending on the targeted run-time environment, deployment may involve [NixOps4](https://nixops.dev) or [OpenTofu](https://opentofu.org/) as an **orchestrator**.
|
||||
- We further provide demo front-end for **configuring applications** and configuring **run-time backends**.
|
||||
|
||||
To ensure reproducibility, all software will be packaged with Nix.
|
||||
|
||||
To reach our goals, we aim to implement the following interactions.
|
||||
|
||||
The used legend is as follows:
|
||||
|
||||
- Circle: [actor](#actors)
|
||||
- Angled box: type
|
||||
- Rectangle: value
|
||||
- Rounded box: function
|
||||
- Diamond: state
|
||||
- Arrow: points towards dependant
|
||||
|
||||
For further info on components see the [glossary](#glossary).
|
||||
|
||||
<!--  -->
|
||||
|
||||
|
||||
### Configuration data flow
|
||||
|
||||
This data flow diagram refines how a deployment is obtained from an operator's application configuration and a hosting provider's runtime setup.
|
||||
|
||||
An **application module** specifies operator-facing **application options**, and a **configuration mapping** which determines the application's underlying implementation. Application modules can be supplied by external developers, which would curate application modules against that interface.
|
||||
|
||||
For its runtime setup, a hosting provider has to supply a **resource mapping** that would take their self-declared **provider configuration** (which determines the *available* resources) and the output of an application's resource mapping (which determine resource *requirements*) and produce a **configuration**. This configuration ships with a mechanism to be *deployed* to the infrastructure (which is described by the environment, and features the required resources), where it will accumulate **application state**.
|
||||
|
||||
Applications and runtime environments thus interface through **resources**, the properties of which are curated by Fediversity maintainers.
|
||||
|
||||
<!--  -->
|
||||
|
||||
|
||||
|
||||
### Service portability
|
||||
|
||||
The process of migrating one's applications to a different host encompasses:
|
||||
|
||||
1. Domain registration: involves a (manual) update of DNS records at the registrar
|
||||
1. Deploy applications: using the reproducible configuration module
|
||||
1. Copy application data:
|
||||
- Run back-up/restore scripts
|
||||
- Run application-specific migration scripts, to e.g. reconfigure connections/URLs
|
||||
|
||||
### Data model
|
||||
|
||||
Whereas the bulk of our configuration logic is covered in the configuration schema, [implemented here](https://git.fediversity.eu/Fediversity/Fediversity/src/branch/main/deployment/data-model.nix) and [tested here](https://git.fediversity.eu/Fediversity/Fediversity/src/branch/main/deployment/data-model-test.nix), our reference front-end applications will store data.
|
||||
The data model design for the configuration front-end needed support the desired functionality is as follows, using the crow's foot notation to denote cardinality:
|
||||
|
||||
<img src="./panel-data-model.svg" alt="" style="max-width:600px;"/>
|
||||
|
||||
### Host architecture
|
||||
|
||||
Whereas the core abstraction in Fediversity is a NixOS configuration module, a more full-fledged example architecture of the web host use-case we aim to support as part of our exploitation would be as follows, where virtual machines in question run Fediversity to offer our selected applications:
|
||||
|
||||
|
||||
|
||||
### CI / CD
|
||||
|
||||
In our simplest set-up, continuous integration and continuous deployment pipelines are handled using Forgejo's [built-in runner](https://code.forgejo.org/forgejo/runner), with relevant secrets handled using [Forgejo secrets](https://forgejo.org/docs/latest/developer/secrets/). Jobs we handle using CI include linting, formatting, testing, and a periodic life-cycle management job to keep our dependencies up-to-date.
|
||||
In a future iteration, we may make use of [Gerrit](https://gerrit.googlesource.com/) to better manage our review process for incoming merge requests.
|
||||
BIN
architecture-docs/architecture.png
Normal file
BIN
architecture-docs/architecture.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 74 KiB |
|
|
@ -1,5 +1,4 @@
|
|||
@startuml
|
||||
skinparam backgroundcolor transparent
|
||||
|
||||
package Management {
|
||||
object "Nix-Panel" as A {
|
||||
|
|
@ -13,7 +12,7 @@ package Management {
|
|||
Secrets
|
||||
}
|
||||
object "**Orchestrator**" as Orch {
|
||||
Terraform
|
||||
NixOps
|
||||
}
|
||||
object "**Identity Management**" as AAA {
|
||||
Authentication
|
||||
|
|
@ -50,10 +49,12 @@ package Virtualization {
|
|||
Application C
|
||||
}
|
||||
map "**Application options**" as App {
|
||||
Vaultwarden => Matrix
|
||||
Edumeet => Matrix
|
||||
NextCloud => Pixelfed
|
||||
Webmail => Peertube
|
||||
Forgejo => Mastodon
|
||||
Hedgehoc => Mastodon
|
||||
Project planning => Owncast
|
||||
Office => Castopod
|
||||
}
|
||||
}
|
||||
|
||||
|
|
@ -1,74 +0,0 @@
|
|||
# 2025-06-24 Fediversity configuration data flow
|
||||
|
||||
This data flow diagram refines the [global architecture diagram](./interactions-migration.mmd) with respect to how a deployment is obtained from an operator's application configuration and a hosting provider's runtime setup.
|
||||
|
||||
## Legend
|
||||
|
||||
- Circle: actor
|
||||
- Angled box: type
|
||||
- Rectangle: value
|
||||
- Rounded box: function
|
||||
- Diamond: state
|
||||
- Arrow: points towards dependant
|
||||
|
||||
## Description
|
||||
|
||||
An **application module** specifies operator-facing **application options**, and a **resource mapping** which determines the application's underlying implementation in terms of which resources it requires to be deployed. Application modules can be supplied by external **contributors**, which would package applications against that interface.
|
||||
|
||||
For its **runtime environment**, a **hosting provider** has to supply a **policy mapping** that would take their self-declared **resource configuration** (which determines *available* resources, i.e. a description of the infrastructure on which to run the applications) and the output of an application's resource mapping (which determines resource *requirements*) and produce the description of a **deployment**.
|
||||
|
||||
An **operator** can supply an **application configuration** and request the hosting provider to let the resulting deployment take effect, such that it will accumulate **application state**, which can later be migrated to other hosting providers.
|
||||
|
||||
Applications and runtime environments thus interface through **resources**, the properties of which are curated by Fediversity **maintainers**.
|
||||
|
||||
|
||||
```mermaid
|
||||
flowchart
|
||||
|
||||
subgraph configuration
|
||||
application-config
|
||||
end
|
||||
subgraph resource[resource module]
|
||||
resource-options
|
||||
provider-options
|
||||
end
|
||||
subgraph application[application module]
|
||||
application-options{{application-options}} --> application-config
|
||||
application-config --> config-mapping
|
||||
resource-options{{consumer-options}} --> config-mapping
|
||||
config-mapping(resource-mapping)
|
||||
end
|
||||
subgraph fediversity[runtime-environment]
|
||||
config-mapping -->|required resources| resource-mapping(policy-mapping)
|
||||
|
||||
provider-options{{resource-options}} --> resource-config --> |available resources| resource-mapping -->|configured resources| deployment[deployment]
|
||||
deployment --> |deploy| state{application state}
|
||||
|
||||
end
|
||||
|
||||
maintainer((maintainer)) -->|curates| resource
|
||||
|
||||
|
||||
contributor((contributor)) -->|packages| application
|
||||
operator((operator)) -->|enters| configuration
|
||||
|
||||
|
||||
hosting-provider((hosting provider)) -->|maintains| fediversity
|
||||
|
||||
```
|
||||
|
||||
## Discussion
|
||||
|
||||
Decoupling of operator-facing application configuration and resource use allows for portability at the infrastructure level: hosting providers determine how applications are deployed to available resources through policies which are agnostic to applications. Additionally it allows hosting providers to isolate applications from each other depending on their deployment model, leveraging the entire toolkit provided by the Nix ecosystem. This puts single-machine and cluster deployments on equal footing, since policies are simply Nix language functions.
|
||||
|
||||
At first glance this is an increase in complexity as opposed to configuring NixOS directly, since it adds a layer of indirection. It also requries Fediversity maintainers to declare resource types for use by application packagers and hosting providers. But the layering drastically simplifies application composition over what NixOS can currently offer, frees the hosting provider to choose how to implement required services, and enables security-conscious deployments at very fine granularity.
|
||||
|
||||
## Next steps
|
||||
|
||||
- Versioning: Each of the components can change; model all supported interactions such that deployments will always be correct.
|
||||
|
||||
Primarily, both applications and runtime environments depend on the resource API, and need to be versioned against it. Application packages can be updated on top of that, and will need to provide facilities to migrate between both application versions and resource API versions, both in terms of configurations and application state.
|
||||
|
||||
- Provider migrations: Prototype an application-agnostic migration workflow.
|
||||
|
||||
Since state migration is application-specific, application packages will need to ship with instructions for how to move their data between hosting providers, also taking version migrations into account. This will likely require extending the resource API with ways to express where state is located, and give hosting providers the tools to expose interfaces though which migrations will take place.
|
||||
|
|
@ -1,26 +1,126 @@
|
|||
# migration data model requirements
|
||||
|
||||
Given:
|
||||
To transfer between two providers, the target provider must be able to import the sending provider's versions. (e.g.: a deployment may have latest fediversity, latest pixelfed, but previous mastadon) Thus, for each "realease" of the data model, it needs to be versioned, and applications/APIs also are versioned.
|
||||
* (May need a way to show on the front-end which versions are in place, and which migrations are supported. However, for application versions which are completely controlled by the installation and setup, this is "solved".)
|
||||
|
||||
- no change in control of domains;
|
||||
- two Fediversity set-ups (to be provided by ProcoliX) with a run-time environment such as ProxmoX, for an initial test using the same version;
|
||||
- a Fediversity configuration of at least a single application (to start)
|
||||
for release version 0, focus on known current needs
|
||||
* to be expanded later as each new application is added and can be transferred between providers
|
||||
* review migration guides for the known apps with an eye to odd/unusual details that influence design choices (task for Niols? others?)
|
||||
|
||||
Our data model must describe a migration:
|
||||
Specifically, this suggests scoping to migrating:
|
||||
|
||||
- specifying [entity relations](https://mermaid.js.org/syntax/entityRelationshipDiagram.html#relationship-syntax) e.g. many-to-many;
|
||||
- migrating both deployed and staged configurations;
|
||||
- deploying of applications using the same versions;
|
||||
- retaining relevant application state;
|
||||
- handling of application-specific migration logic, such as to rewrite URLs as needed;
|
||||
- managed infrastructure (rather than managed applications)
|
||||
- between servers owned by procolix
|
||||
- same proxmox version
|
||||
- NixOS VMs set up by us so we can guarantee identical application versions
|
||||
- hosting limited to a single application (to start)
|
||||
|
||||
Tests:
|
||||
First, a bit of an inventory (list without much structure now, later will create structured form/schema with e.g. many-to-many links, useful for the migration code):
|
||||
* clearly mark items that will not be in the first migration as eventually or speculative
|
||||
* or reamove them if they would be too far in the future
|
||||
* later we understand what is useful for migration code, we can extract and transform in to a format suitable as data model documentation
|
||||
|
||||
1.
|
||||
A Fediversity user may wish to migrate their Fediversity set-up between monolithic and distributed configurations.
|
||||
In an admin screen they can get their configuration and data for transfer.
|
||||
Using this they may migrate to the desired configuration.
|
||||
1.
|
||||
At any time a Fediversity user may wish to migrate their Fediversity set-up.
|
||||
They can go to an admin screen where they can get their configuration and data for transfer.
|
||||
This data can be provided to a new service provider where they will be up-and-running again, with minimal downtime.
|
||||
Hosting Provider provides:
|
||||
* proxmox, git
|
||||
* hardware
|
||||
* filesystem storage
|
||||
* DNS automation hooks?
|
||||
* central/shared garage storage or only hardware+diskspace for the garage VMs to create storage?
|
||||
* with central: more efficient but less isolated
|
||||
|
||||
FooUniversity (Operator)
|
||||
* invoice info
|
||||
* is all info expected to be transferred from provider A to provider B?
|
||||
* May not want to transfer e.g. bank details, because they are already set up at B
|
||||
* May also depend on regulation (which information are you allowed to hand out?)
|
||||
* Admins:
|
||||
* credentials
|
||||
* persistent identifiers
|
||||
* mappings between them (also need to travel across providers)
|
||||
* e.g. if we can't change content URLs, we may need to create (and from then on carry around) a redirects mapping
|
||||
* those mappings are likely application-specific, but they all belong to the same type class
|
||||
* domain(s)
|
||||
* what is needed for DNS management?
|
||||
* users
|
||||
* display name
|
||||
* email(s)
|
||||
* login id
|
||||
* oauth2 (eventually)
|
||||
* 2fa
|
||||
* password
|
||||
* passkeys (eventually)
|
||||
* LDAP? (eventually?)
|
||||
* all applications
|
||||
* sub domain ( social.example.org vs example.org/social )
|
||||
* info for proxmox setup such as to provision VMs (to reproduce proxmox )
|
||||
* mem
|
||||
* cpus
|
||||
* storage mounts
|
||||
* IPs likely not the same in the target network
|
||||
* storage
|
||||
* filesystem
|
||||
* very well specified per application
|
||||
* blob storage config (garage, s3-like)
|
||||
* index
|
||||
* Can we make it a requirement that Garage is behind a predictable URL, eg. `<application>.garage.<customer domain>`? As opposed to something vendor-specific, eg. `pixelfed-university.garage.procolix.com/<customer domain>/<application>`
|
||||
* may need to rewrite URLs to blobs automatically, depending on the underlying URL scheme, which may be per setup or application
|
||||
* limits? per application? per user? where are these used/set/enforced?
|
||||
* TODO: what does e.g. borgmatic need to back up storage?
|
||||
* out of scope?: focus on actual state, disregarding reconstructable stuff
|
||||
* SQL database
|
||||
* dump/snapshot
|
||||
* TODO: what does e.g. borgmatic need to back up databases?
|
||||
* application specifics
|
||||
* postfix? (is email in version 0?)
|
||||
* pixelfed
|
||||
* where is blob storage
|
||||
* in the specific case of Pixelfed, if blob storage changed URL, we might need to rewrite the pictures URLs in the database (try to avoid this)
|
||||
* redis (in the case of pixelfed, it is not just a cache)
|
||||
* misc config: theme, name of instance, email of sysadmin
|
||||
* database
|
||||
* on-disk files
|
||||
* Daniel Supernault is currently making it so evertying can be stored remotely in a garage or sql database
|
||||
* users (login id) (in database? in redis?)
|
||||
* user preferences/settings
|
||||
* peertube
|
||||
* mastodon
|
||||
* matrix? (is it in version 0?)
|
||||
* logos
|
||||
|
||||
Other considerations:
|
||||
|
||||
- Put a boundary for what is
|
||||
- operator-configurable
|
||||
- needs to get fixed, but at the implementation level
|
||||
- what can be configured dynamically per environment
|
||||
- Most importantly we need to preserve persistent identifiers
|
||||
|
||||
- When transforming the data-model code to a deliverable version of the data model as part of the technical architecture document, documenting user-data storage and with respects fot security and GDPR
|
||||
|
||||
See also:
|
||||
|
||||
- possible overlap/inspiration: Stalw.art [configuration docs](https://stalw.art/docs/server/general)
|
||||
|
||||
## MVP scoping ideas
|
||||
|
||||
User story 1: New customer
|
||||
When a new customer goes to the Fediversity website we want to show that user what Fediversity is all about and what it can give to the customer. This points the customer to a signup form where they can enter all the details that are needed to get it working. Here they can also decide what applications to use (at first no more than three). Details can be, the user/admin login, name, address, bank details, domain, other users, and applications. Than when the customer hits the install/provision/go button everything starts to install automagically. After which the customer is presented with (some) url's to login to.
|
||||
|
||||
User story 2: Take out / move to other instance
|
||||
At any time a customer may wish to change service providers. They can easily go to an admin screen where they can get their configuration and data packaged for transfer. This packaged data can be provided to a new service provider where they will be up-and-running again easily, with minimal downtime.
|
||||
|
||||
proposed MVP scope:
|
||||
- block storage
|
||||
- blob storage (garage)
|
||||
- physical servers
|
||||
- proxmox vm management
|
||||
- nixops service
|
||||
- nixops scripts
|
||||
- 1 to 3 applications packaged in Nix (Mastodon, Peertube, Pixelfed)
|
||||
- frontend / website
|
||||
- working dns, can be external, but automated
|
||||
- takeout area
|
||||
- import area
|
||||
- 2 Fediversity environments to transfer between
|
||||
- demonstration of User story 1
|
||||
- demonstration of User story 2
|
||||
|
|
|
|||
|
|
@ -1,25 +0,0 @@
|
|||
---
|
||||
title: Fediversity migration entity relations
|
||||
---
|
||||
erDiagram
|
||||
setup["Fediversity setup"]
|
||||
env["run-time environment"]
|
||||
deployed["deployed configuration"]
|
||||
staged["staged configuration"]
|
||||
token["deployment token"]
|
||||
script["migration script"]
|
||||
|
||||
setup }o--o{ env : offers
|
||||
setup ||--o{ operator : serves
|
||||
operator ||--o{ domain : owns
|
||||
deployment }|--|| domain : uses
|
||||
operator ||--o{ deployment : has
|
||||
deployment ||--|{ token : generates
|
||||
deployment ||--o| deployed : has
|
||||
deployment ||--|| staged : has
|
||||
deployed |o--|| staged : compares
|
||||
deployed ||--|{ application : describes
|
||||
application ||--o{ version : follows
|
||||
application ||--o{ script : runs
|
||||
deployed }|--o{ version : follows
|
||||
script }o--|| token : uses
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 164 KiB |
File diff suppressed because one or more lines are too long
|
Before Width: | Height: | Size: 16 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 73 KiB |
|
|
@ -1,30 +0,0 @@
|
|||
flowchart
|
||||
|
||||
subgraph configuration
|
||||
application-config
|
||||
end
|
||||
subgraph resource[resource module]
|
||||
resource-options
|
||||
provider-options
|
||||
end
|
||||
subgraph application[application module]
|
||||
application-options{{application-options}} --> application-config
|
||||
application-config --> config-mapping
|
||||
resource-options{{resource-options}} --> config-mapping
|
||||
config-mapping(config-mapping)
|
||||
end
|
||||
subgraph fediversity[fediversity setup]
|
||||
config-mapping -->|required resources| resource-mapping(resource-mapping)
|
||||
|
||||
provider-options{{provider-options}} --> provider-config --> |available resources| resource-mapping -->|configuration| deployment{deployment}
|
||||
|
||||
end
|
||||
|
||||
maintainer((maintainer)) -->|curates| resource
|
||||
|
||||
|
||||
contributor((developer)) -->|curates| application
|
||||
operator((operator)) -->|enters| configuration
|
||||
|
||||
|
||||
hosting-provider((hosting provider)) -->|maintains| fediversity
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 50 KiB |
File diff suppressed because one or more lines are too long
|
Before Width: | Height: | Size: 22 KiB |
|
|
@ -1,47 +0,0 @@
|
|||
flowchart
|
||||
|
||||
user((user)) --> |use| deployment
|
||||
|
||||
configuration1 -->|deploy| deployed1
|
||||
maintainers --> |maintain| fediversity
|
||||
|
||||
fediversity --> |update| provider1
|
||||
subgraph provider1["fediversity setup A"]
|
||||
subgraph configurations1[configurations]
|
||||
configuration1[staged configuration]
|
||||
configuration1 --> |update| configuration1
|
||||
deployed1[deployed configuration]
|
||||
end
|
||||
deployed1 --> |describe| deployment
|
||||
provider-config[runtime config] --> |describe| host
|
||||
provider-config --> |implement runtime interfaces| configurations1
|
||||
subgraph host[runtime environment]
|
||||
deployment[applications]
|
||||
state{state}
|
||||
end
|
||||
end
|
||||
|
||||
deployment --> |store| state
|
||||
|
||||
operator((operator)) --> |change| configuration1
|
||||
|
||||
subgraph provider2["fediversity setup B"]
|
||||
subgraph configurations2[configurations]
|
||||
configuration2[staged configuration]
|
||||
deployed2[deployed configuration]
|
||||
end
|
||||
subgraph host2[runtime environment]
|
||||
deployment2[applications]
|
||||
state2{state}
|
||||
end
|
||||
end
|
||||
|
||||
operator --> |trigger| migration(migration)
|
||||
configurations1 & state --> migration
|
||||
migration --> configurations2 & state2
|
||||
provider((hosting provider)) --> |maintain| provider1
|
||||
subgraph fediversity[fediversity source code]
|
||||
applications[application modules]
|
||||
backends[runtime backends]
|
||||
config{{runtime options}}
|
||||
end
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 68 KiB |
File diff suppressed because one or more lines are too long
|
Before Width: | Height: | Size: 33 KiB |
|
|
@ -1,24 +0,0 @@
|
|||
---
|
||||
title: Data model of sample web application
|
||||
---
|
||||
erDiagram
|
||||
operator {
|
||||
string username
|
||||
string password_hash
|
||||
}
|
||||
deployment {
|
||||
json deployed_configuration
|
||||
option[string] staged_configuration
|
||||
option[string] version
|
||||
}
|
||||
backup["back-up"] {
|
||||
string bucket
|
||||
string endpoint
|
||||
}
|
||||
keypair {
|
||||
string access_key
|
||||
string secret_key
|
||||
}
|
||||
operator ||--o{ deployment : has
|
||||
deployment ||--o{ backup : has
|
||||
backup ||--|{ keypair : authorises
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 54 KiB |
File diff suppressed because one or more lines are too long
|
Before Width: | Height: | Size: 12 KiB |
14
default.nix
14
default.nix
|
|
@ -1,14 +0,0 @@
|
|||
{
|
||||
pkgs ? import <nixpkgs> { },
|
||||
}:
|
||||
{
|
||||
shell = pkgs.mkShellNoCC {
|
||||
packages = with pkgs; [
|
||||
pandoc
|
||||
texliveMedium
|
||||
librsvg
|
||||
mermaid-cli
|
||||
plantuml
|
||||
];
|
||||
};
|
||||
}
|
||||
|
|
@ -1,160 +0,0 @@
|
|||
<!--
|
||||
> Get insight in the total global investments of the Fediverse (OID)
|
||||
> To get an overview of the total investment of capital, human resources and other valuables, we will research the usage of these in the (visible) Fediverse globally. A report of this will be released.
|
||||
|
||||
> Release a report on the estimated collective current investment on fediverse technology:
|
||||
> Look at qualifiers like:
|
||||
>- Used system resources (CPU, storage, networking)
|
||||
>- Amount of software developers actively working on Fediverse software products
|
||||
>- Amount of system administration engineers actively working on Fediverse software products
|
||||
>- Amount of moderation and governance people
|
||||
-->
|
||||
|
||||
# An estimate of investments in the Fediverse
|
||||
|
||||
## Introduction
|
||||
|
||||
To provide an estimate of the investments made into the Fediverse, defined[^1] as a decentralized interoperable network of social media sites, apps, and services built on the ActivityPub protocol, is a daunting task, owing due to:
|
||||
|
||||
1. a lack of research (in our experience) on this topic thus far;
|
||||
1. the vast number of services part of the Fediverse[^2];
|
||||
1. the Fediverse's decentralised nature;
|
||||
1. involvement of voluntary contributions;
|
||||
1. the third-party nature of some of the integrations.
|
||||
|
||||
Nonetheless, we have taken upon ourselves the task to provide a first glimpse on this subject. Given the Fediverse's interoperability empowers users, a better overview on the resources in this technology helps clarify its momentum for key decision-makers interested in adopting, investing in and interfacing with this technology. We further hope our work will contribute and ignite more serious research into this topic.
|
||||
|
||||
In this document we describe our assessment of the investments made in the Fediverse. We start with describing our methodology for gathering data on the Fediverse and share information on the services, platforms and software applications we have deemed relevant to include.
|
||||
|
||||
## Methodology
|
||||
|
||||
In order to better scope our research, we will address the mentioned challenges by:
|
||||
|
||||
1. given the lack of research on this topic so far, gathering missing data by contacting representatives of the respective projects;
|
||||
1. to account for the vast number of services part of the Fediverse, focusing on the major services[^3] part of the Fediverse, in this case the software with at least 10,000 active monthly users as per Fediverse Observer[^2], in total accounting for over 95% of the active users across Fediverse services, i.e.:
|
||||
* Threads
|
||||
* Mastodon
|
||||
* Pixelfed
|
||||
* NodeBB
|
||||
* Lemmy
|
||||
* Peertube
|
||||
* Loops
|
||||
* Wordpress
|
||||
* WriteFreely
|
||||
1. to account for the Fediverse's decentralised nature, extrapolating for each service to their overall number of (visible[^4]) instances from their flagship instances;
|
||||
1. to account for the involvement of voluntary contributions, separately citing internal versus overall contributors active on the projects, and extrapolating from the former to estimate the latter;
|
||||
1. to account for the third-party nature of some of the integrations, explicitly distinguishing these in our overview.
|
||||
|
||||
### NodeInfo
|
||||
|
||||
Fediversity instances tend to expose data using the NodeInfo protocol (<https://nodeinfo.diaspora.software/>). Data exposed this way is gathered in <https://fediverse.observer/>, which we use as our source for metrics:
|
||||
|
||||
* estimated number of installations
|
||||
* estimated number of users
|
||||
* estimated number of monthly active users
|
||||
|
||||
### Human resources
|
||||
|
||||
#### Moderators
|
||||
|
||||
<!-- #### Amount of moderation and governance people -->
|
||||
On users with moderation privileges ActivityPub unfortunately exposes no structured data yet, although this is an outstanding feature request[^5].
|
||||
|
||||
In addition, for some single-tenant platforms such as WriteFreely, moderation does not apply. Platforms that support user sign-ups, such as Mastodon, may similarly disable user sign-up, in which case moderation similarly is not relevant.
|
||||
|
||||
<!-- TODO: distinguish active user data by whether instances enable user sign-up -->
|
||||
|
||||
#### Developers
|
||||
|
||||
<!-- #### Amount of software developers actively working on Fediverse software products -->
|
||||
The amount of active developers we estimate as users:
|
||||
|
||||
* as identified by unique emails
|
||||
* who are not bots, as measured by whether their name contains 'bot',
|
||||
* who contributed at least **5** commits to the default Git branch at the main forge/fork
|
||||
* over the past year.
|
||||
|
||||
We obtain this metric by running a Nushell query[^6] on the project's respective Git repositories.
|
||||
|
||||
Based on project estimations on internal engineers involved measured in FTE, we further estimate the total amount of development involved by extrapolating from these FTE figures to include external contributors based on their relative number of commits --- thereby for the purpose of this estimate presuming similar time and effort required for external versus internal commits.
|
||||
|
||||
#### System administrators
|
||||
|
||||
<!-- #### Amount of system administration engineers actively working on Fediverse software products -->
|
||||
|
||||
### Used system resources
|
||||
<!-- >- Used system resources (CPU, storage, networking) -->
|
||||
#### CPU
|
||||
* minimum/average/peak percentage of (number of) CPU cores used?
|
||||
<!-- (presumes similar performance across CPU models) -->
|
||||
* CPU model used
|
||||
#### storage
|
||||
in e.g. GB currently used by the instance
|
||||
#### networking
|
||||
in e.g. min/max/average MiB/s in/out of the instance, along with physical caps potentially limiting these
|
||||
<!-- #### RAM -->
|
||||
### Capital
|
||||
<!-- * income -->
|
||||
<!-- note that while most of the Fediverse projects have had grants from NLNet, NLNet does not publish structured information on financial resources committed or reimbursed. -->
|
||||
<!-- * estimated costs for the service -->
|
||||
|
||||
## A closer look at the Fediverse platforms
|
||||
<!--
|
||||
* Name of service/platform
|
||||
* Description of service/platform
|
||||
* capital
|
||||
* income
|
||||
* estimated costs for the service
|
||||
* NodeInfo
|
||||
* estimated number of installations
|
||||
* estimated number of users (Monthly Active Users)
|
||||
* human resources
|
||||
* [ ] Amount of software developers actively working on Fediverse software products
|
||||
* estimated number of developers working on the service
|
||||
* [ ] Amount of system administration engineers actively working on Fediverse software products
|
||||
* [ ] Amount of moderation and governance people
|
||||
* estimated number of moderators
|
||||
* Used system resources
|
||||
* [ ] CPU
|
||||
* [ ] storage
|
||||
* [ ] networking
|
||||
-->
|
||||
|
||||
| Project | Installations | monthly active users |
|
||||
|-|-|-|
|
||||
| mastodon | 8033 | 736878 |
|
||||
| pixelfed | 501 | 126065 |
|
||||
| nodebb | 43 | 52399 |
|
||||
| lemmy | 407 | 41341 |
|
||||
| peertube | 962 | 25804 |
|
||||
| loops | 1 | 26548 |
|
||||
| wordpress | 2863 | 11510 |
|
||||
| writefreely | 492 | 11188 |
|
||||
|
||||
## Estimating investments in the Fediverse
|
||||
|
||||
<!-- * Conclusion -->
|
||||
|
||||
## Notes
|
||||
[^1]: Kissane, E., & Kazemi, D. (2024, September 4). Findings Report: Governance on Fediverse Microblogging Servers. https://fediverse-governance.github.io/#brief-glossary
|
||||
[^2]: https://fediverse.observer/allsoftwares
|
||||
[^3]: Note that this focus would exclude work on protocols such as W3C's work on the ActivityPub protocol, as well as on non-core repositories, and ancilliary software whose development is run by others than by the lead developers of the mentioned services, such as bridges, cross-posters, third-party clients, browser extensions, instance indices, etc.
|
||||
[^4]: Visibility, for our purposes meaning exposing metadata using the NodeInfo protocol, for Mastodon, the Fediverse service with the highest amount of active users, notably excludes an instance with more active users than its biggest visible instance <https://mastodon.social/>, namely Donald Trump's Truth Social.
|
||||
[^5]: This feature requested may be tracked at: https://github.com/swicg/activitypub-trust-and-safety/issues/25
|
||||
[^6]: The used query here is: `git log --pretty=%h»¦«%s»¦«%aN»¦«%aE»¦«%aD | lines | split column "»¦«" commit subject name email date | upsert date {|d| $d.date | into datetime} | where ($it.date > ((date now) - 365day)) | where not ($it.name has 'bot') | group-by name | transpose | upsert column1 {|c| $c.column1 | length} | sort-by column1 | rename name commits | where ($it.commits >= 5) | reverse | length`
|
||||
|
||||
## References
|
||||
|
||||
* https://en.wikipedia.org/wiki/Fediverse
|
||||
* https://fedidb.org/
|
||||
* https://mastodon-analytics.com/
|
||||
* https://www.thinkimpact.com/mastodon-statistics/
|
||||
* https://fediverse.observer/
|
||||
* https://the-federation.info/
|
||||
* https://fediverse.party
|
||||
* https://socialhub.activitypub.rocks/t/fep-f1d5-nodeinfo-in-fediverse-software/1190
|
||||
* https://codeberg.org/fediverse
|
||||
* https://hachyderm.io/@esk/113793277371908181
|
||||
|
||||
## Changes
|
||||
Older versions of this directory lived here: https://git.fediversity.eu/Fediversity/meta/src/commit/0006758ab7d12c2914f915813815bea89208fc6d/Fediverse-investments-an-estimation.md
|
||||
|
|
@ -1,58 +0,0 @@
|
|||
# 2025-04-14 Sync Kiara/Valentin
|
||||
|
||||
- @fricklerhandwerk asked for a walk through https://git.fediversity.eu/Fediversity/Fediversity/pulls/307
|
||||
- @kiara:
|
||||
- TF seemed like easier to work with
|
||||
- A lot of details, but got it to run with the deployed infra
|
||||
- Tried TF with nixos-anywhere, but that [seemed not to pick up on our config](https://git.fediversity.eu/kiara/Fediversity/pulls/1)
|
||||
- Also tried [terraform-nixos](https://github.com/nix-community/terraform-nixos/), but that is deserted
|
||||
- @fricklerhandwerk: probably need to take a few steps back since the project is doing a backflip, and re-assess what we want morally and then re-align on the technical strategy
|
||||
- @kiara desired work order
|
||||
- website
|
||||
- remove the unused code
|
||||
- panel
|
||||
- should be a reference implementation to demo the ideas
|
||||
- let front-end people productise independently, using our APIs
|
||||
- infra
|
||||
- want to replace NixOps4 with Terraform
|
||||
- we have private keys lying around in the repo
|
||||
- @fricklerhandwerk: can just move them to agenix?
|
||||
- @kiara: yes, need to nuke everything and start over
|
||||
- pins
|
||||
- need to consolidate the different ways of doing things
|
||||
- VMs
|
||||
- eventually want to remove the hard-coded stuff
|
||||
- @fricklerhandwerk: what about integration tests? our basics is not tested, we need the proxmox workflow under control before doing other stuff
|
||||
- @kiara: agreed. would like to get to a system that others can pick up by reading through the tests
|
||||
- @fricklerhandwerk: possibly we need to take even more steps back, such as nailing down our development workflows
|
||||
- e.g. we can't even make suggestions in code reviews on Forgejo
|
||||
- @kiara: we could spin up Gerrit, but where does it stop?
|
||||
- @fricklerhandwerk: outline:
|
||||
- open up an infra repo (or eat the existing one from within)
|
||||
- set up SSO, some Git server, issue tracker, and a deployment workflow for that
|
||||
- start over with the application code, begin with Nix first, integration tests first, no PR accepted without tests and reviews
|
||||
- spiral up from there; we already know a lot of the rest of the owl
|
||||
- it may end up amounting to bootstrapping the whole infra idea...
|
||||
- @kiara: agreed, the basics aren't testable because everything is hard coded
|
||||
- most importantly, everyone on the team should be able (i.e. capable and allowed to) change anything about the system, and for that we really need to agree on how it works and how to approach things
|
||||
- which is also why we'd need a proper architecture decision record (ADR) system, by which I simply mean being disciplined about writing things down
|
||||
- @kiara: I consider the application services and the deployment code around it the core of our work
|
||||
- the (currently Django) shell invoking that I consider an example implementation of the product on top
|
||||
- we already know there will be other such implementations because Procolix wants to productise it in their existing setup
|
||||
- getting the boundaries between those clear before new people (e.g. external contributors, future team members) come in
|
||||
- therefore the most important thing would be building an interface for spinning up the Nix environment and invoking the deployment from wherever
|
||||
- currently it's only documented as embodied in our implementation
|
||||
- @fricklerhandwerk: agreed; and we should reduce our scope for what we work on to the absolute minimum, and focus on user stories for integrators
|
||||
- although they should still be expressed through something you can click on, based on automatic testing of course
|
||||
- @fricklerhandwerk: it seems we agree that we need to do a spring cleaninig
|
||||
- @kiara: yes (service modules seem not to be the problem though)
|
||||
- @fricklerhandwerk: would terraform not make things harder?
|
||||
- @fricklerhandwerk: agree it's not as mature still tho
|
||||
- (some back and forth on Terraform vs NixOps4)
|
||||
- @fricklerhandwerk: although the decision to stick with NixOps4 was made a long time ago, the rationale seems not to have been written down
|
||||
- trade-offs:
|
||||
- NixOps4 is not mature and can't do some crucial things yet; may risk the timeline
|
||||
- Terraform done from json/nix could use Nix language wrappers
|
||||
- TF references are stringly typed, it's slightly brittle
|
||||
- next steps:
|
||||
- start pairing tomorrow on the spring clean, and shovel code
|
||||
309
meeting-notes/2025-04-07-project-context-braindump.md
Normal file
309
meeting-notes/2025-04-07-project-context-braindump.md
Normal file
|
|
@ -0,0 +1,309 @@
|
|||
- context
|
||||
- status quo
|
||||
- geopolitics
|
||||
- surveillance
|
||||
- capital accumulation
|
||||
- monopolistic gatekeepers
|
||||
- big tech
|
||||
- legislation
|
||||
- digital markets act
|
||||
- digital services act
|
||||
- fediverse
|
||||
- open-source
|
||||
- federated
|
||||
- various applications
|
||||
- limited momentum
|
||||
- self-hosting
|
||||
- expertise
|
||||
- containers
|
||||
- configuration
|
||||
- SSO
|
||||
- LDAP
|
||||
- sysadmin burden
|
||||
- operating systems
|
||||
- reproducibility
|
||||
- network security
|
||||
- software LCM
|
||||
- backups
|
||||
- state of the internet
|
||||
- network-effect-fueled oligopolies
|
||||
- commercial interests
|
||||
- enshittification
|
||||
- misinformation
|
||||
- surveillance
|
||||
- manipulation
|
||||
- gamification
|
||||
- polarization
|
||||
- IP harvested by scrapers to spam the internet with AI slop
|
||||
- gamification-fueled addiction
|
||||
- lack of democratic control
|
||||
- illegal content
|
||||
- covert foreign/commercial online influencing campaigns
|
||||
- cambridge analytica
|
||||
- polarizing filter bubbles from engagement-fueled algorithms
|
||||
- stratify society
|
||||
- may culminate in terrorism
|
||||
- qanon's role in Jan 6 capitol insurrection
|
||||
- energy usage of data centers and AI
|
||||
- open-source
|
||||
- devops
|
||||
- nixos
|
||||
- developer-centric
|
||||
- self-hosting
|
||||
- yunohost
|
||||
- fediverse
|
||||
- innovation cycle
|
||||
- research
|
||||
- commerce
|
||||
- dissemination
|
||||
- commons
|
||||
- distribution
|
||||
- ecosystem
|
||||
- stakeholders
|
||||
- EU
|
||||
- NGI
|
||||
- [report](https://nlnet.nl/fediversity/)
|
||||
- let users separate content and data from internet-based sofware and services
|
||||
- re-establish boundaries between content owner and service provider
|
||||
- allow mixing/matching alternative/complementary services
|
||||
- service portability + data decoupling
|
||||
- achieve openness to new entrants
|
||||
- unlock clustered service verticals with dominant market positions
|
||||
- presentation
|
||||
- commons
|
||||
- context
|
||||
- security
|
||||
- economy
|
||||
- geopolitics
|
||||
- why
|
||||
- sovereignty
|
||||
- trust
|
||||
- collaboration
|
||||
- european declaration on digital rights and principles
|
||||
- privacy protection
|
||||
- user control and choice
|
||||
- portability
|
||||
- inclusion
|
||||
- decentralisation
|
||||
- NGI
|
||||
- internet commons
|
||||
- hardware
|
||||
- libraries
|
||||
- distribution
|
||||
- server apps
|
||||
- client apps
|
||||
- nlnet
|
||||
- OIDF
|
||||
- intro
|
||||
- fundamental right of individuals
|
||||
- privacy
|
||||
- self-determination
|
||||
- freedom of expression
|
||||
- internet is crucial infrastructure that should be maintainable long-term
|
||||
- nixos
|
||||
- transparency
|
||||
- open software
|
||||
- fediversity
|
||||
- presentation
|
||||
- objective
|
||||
- bring easy-to-use, budget-conscious, _federated_ hosted cloud services to organisations and individuals
|
||||
- goals
|
||||
- digital autonomy
|
||||
- innovation
|
||||
- service/data portability
|
||||
- federated decentralized services
|
||||
- sustainable economic ecosystem
|
||||
- open
|
||||
- benefits
|
||||
- providers
|
||||
- ease of operations
|
||||
- share investments
|
||||
- lower maintenance
|
||||
- ease of deployment
|
||||
- part of a larger ecosystem
|
||||
- users
|
||||
- easy of use
|
||||
- data portability
|
||||
- no vendor lock-in
|
||||
- service portability
|
||||
- digital sovereignty
|
||||
- independence from big tech
|
||||
- principles + assumptions
|
||||
- run on hardware
|
||||
- target providers to offer federated services
|
||||
- digital sovereignty
|
||||
- ease dev/maintenance
|
||||
- ease deployment/running of federated services
|
||||
- federated decentralised OSS using open standards
|
||||
- service portability
|
||||
- tech stack
|
||||
- django
|
||||
- nixos
|
||||
- nix packages
|
||||
- nixops4
|
||||
- proxmox
|
||||
- bare-metal hardware
|
||||
- custom code and databases
|
||||
- services
|
||||
- Mastodon
|
||||
- PixelFed
|
||||
- PeerTube
|
||||
- Matrix
|
||||
- Nexcloud
|
||||
- Stalwart
|
||||
- Owncast
|
||||
- Lemmy
|
||||
- EduMEET
|
||||
- [objectives](https://nlnet.nl/fediversity/background/)
|
||||
- primary
|
||||
- new technical building blocks
|
||||
- 3 partners
|
||||
- secondary
|
||||
- funding mechanism
|
||||
- nlnet
|
||||
- [NGI emphasis](https://www.ngi.eu/ngi-projects/ngi-fediversity/)
|
||||
- replaces traditional social networking
|
||||
- create a practical, user-friendly, and secure communication environment
|
||||
- NGOs
|
||||
- waag
|
||||
- [state of the internet](https://waag.org/en/event/state-internet-2025/)
|
||||
- retake internet from US big tech
|
||||
- regulate tech as we do other fields
|
||||
- marleen stikker
|
||||
- book: 'het internet is stuk - maar we kunnen het repareren'
|
||||
- history of the internet explaining big tech platforms as step back in sovereignty
|
||||
- technology is not neutral
|
||||
- emphasizes human values over techno-optimism pushed by silicon valley
|
||||
- role of data access
|
||||
- understanding
|
||||
- democracy
|
||||
- control
|
||||
- mentions historical role of tactical media
|
||||
- [EuroStack](https://www.euro-stack.info/#eurostack)
|
||||
- goals
|
||||
- Sovereignty and Security
|
||||
- Sustainability
|
||||
- Decentralized Sovereign Infrastructure
|
||||
- Strong Democracy
|
||||
- De-Proprietarization and Interoperability
|
||||
- Data as a Common Good
|
||||
- Inclusive Governance
|
||||
- 7 layers
|
||||
- data + AI
|
||||
- software
|
||||
- cloud
|
||||
- IoT
|
||||
- networks
|
||||
- chips
|
||||
- raw materials, energy and water
|
||||
- [open forum europe](https://openforumeurope.org/our-vision/)
|
||||
- principles
|
||||
- user centricity
|
||||
- competition
|
||||
- flexibility
|
||||
- sustainability
|
||||
- community
|
||||
- developers
|
||||
- want easy path to users
|
||||
- want easy updating
|
||||
- hosts
|
||||
- want managed applications
|
||||
- want off-the-shelf solutions
|
||||
- operators
|
||||
- want app store of sovereign services
|
||||
- want things to just work
|
||||
- users
|
||||
- want easy UX
|
||||
- want sovereign infrastructure
|
||||
- want tools reflecting their values
|
||||
- human-centric
|
||||
- inclusive
|
||||
- accessible
|
||||
- why
|
||||
- policy-makers
|
||||
- achieve sovereignty to deliver on digital rights
|
||||
- sovereign managed applications
|
||||
- catalyze dissemination to have internet commons reach critical mass
|
||||
- starting out with social media over gatekeepers' effect amid geopolitical considerations
|
||||
- robust technology
|
||||
- fediversity
|
||||
- portable
|
||||
- fediverse
|
||||
- sovereign
|
||||
- nixos
|
||||
- [reproducible](https://reproducible.nixos.org/)
|
||||
- [vibrant](https://repology.org/repositories/graphs)
|
||||
- [security-conscious](https://tracker.security.nixos.org/)
|
||||
- hosts
|
||||
- off-the-shelf
|
||||
- easy for host and users
|
||||
- demand due to geopolitical relevance
|
||||
- users
|
||||
- sovereign
|
||||
- no lock-in
|
||||
- private
|
||||
- SSO/LDAP
|
||||
- ease
|
||||
- simple install
|
||||
- sensible defaults
|
||||
- update/backup policies
|
||||
- choice
|
||||
- open to hosts
|
||||
- portable data/hosting
|
||||
- different apps
|
||||
- control
|
||||
- open
|
||||
- federation
|
||||
- advanced settings
|
||||
- how
|
||||
- design
|
||||
- front: app store style UI not unlike [yunohost](https://apps.yunohost.org/catalog)
|
||||
- stack
|
||||
- user-facing
|
||||
- fediverse
|
||||
- ...
|
||||
- under the hood
|
||||
- [nix](https://nixos.org/)
|
||||
- NixOS
|
||||
- service contracts: [SelfHostBlocks](https://nlnet.nl/project/SelfHostBlocks/)
|
||||
- [upstream](https://git.fediversity.eu/Fediversity/Fediversity/issues/127#issuecomment-5669) nix packages to source repos to normalize reproducibility and accelerate LCM
|
||||
- [opentofu](https://opentofu.org/)
|
||||
- VM hypervisor: [proxmox](https://proxmox.com/)
|
||||
- storage: [garage](https://garagehq.deuxfleurs.fr/)
|
||||
- backups / data portability: [borgmatic](https://github.com/borgmatic-collective/borgmatic)
|
||||
- data interoperability: [json-schema](https://json-schema.org/)
|
||||
- validate
|
||||
- [visualize](https://github.com/json-schema-form-element/jsfe)
|
||||
- component architectures
|
||||
- traditional
|
||||
- web panel front/back
|
||||
- orchestration
|
||||
- VMs
|
||||
- hypervisor
|
||||
- application VMs
|
||||
- storage
|
||||
- supporting
|
||||
- identity management
|
||||
- authentication
|
||||
- authorization
|
||||
- accounting
|
||||
- central database
|
||||
- nextbox
|
||||
- accounting
|
||||
- state
|
||||
- secrets
|
||||
- central services
|
||||
- DNS
|
||||
- email
|
||||
- decoupled
|
||||
- clients
|
||||
- [monolith](https://git.fediversity.eu/Fediversity/Fediversity) (django)
|
||||
- host all-in-one
|
||||
- [front](https://git.fediversity.eu/Fediversity/protagio.nl-frontend)
|
||||
- back
|
||||
- [existing](https://git.fediversity.eu/Fediversity/myprotagio-api) (php)
|
||||
- new (django)?
|
||||
- orchestration module
|
||||
- nixos
|
||||
- selfhostblocks
|
||||
- opentofu
|
||||
|
|
@ -1,75 +0,0 @@
|
|||
Attendees: @kiara @fricklerhandwerk
|
||||
|
||||
- adapted semantics of JSON schema conversion to the module system: https://git.clan.lol/clan/clan-core/pulls/3335
|
||||
- fixed some build issues in https://git.fediversity.eu/Fediversity/Fediversity/pulls/307
|
||||
- got form rendering to work again in https://git.fediversity.eu/Fediversity/Fediversity/pulls/285
|
||||
- also minor cleanups on the way to getting it mergeable
|
||||
- discussed considerations of mapping NixOS modules to UI elements
|
||||
- problem: NixOS modules don't have a notion of field label (important for forms) and the best we can currently do is derive it from the attribute name (meh)
|
||||
- related work by @hsjobeki:
|
||||
- https://discourse.nixos.org/t/zurich-24-11-zhf-hackathon-report/59250#p-197228-on-user-interfaces-for-nixos-configurations-6
|
||||
- https://github.com/NixOS/nixpkgs/pull/341199
|
||||
- @fricklerhandwerk: not convinced that adding more hard-coded fields to module options is the right way
|
||||
- it's ad hoc, where does it end?
|
||||
- the problem statement is relevant though, we need to somehow annotate presentation aspects
|
||||
- @kiara: https://rjsf-team.github.io/react-jsonschema-form/ implements these annotations
|
||||
- @fricklerhandwerk: textual references are a maintenance burden; opportunity for human error
|
||||
- sketched an idea for structural annotations using a module system wrapper:
|
||||
|
||||
```nix
|
||||
let
|
||||
fancy-wrapper = go-wild (
|
||||
{ lib, ... }:
|
||||
let
|
||||
inherit (lib) mkOption types;
|
||||
in
|
||||
{
|
||||
options = {
|
||||
initialUser = mkOption {
|
||||
type = types.submodule {
|
||||
options = {
|
||||
displayName = mkOption {
|
||||
type = types.str;
|
||||
description = "Display name of the user";
|
||||
meta.ui = lib.mkOptionMeta {
|
||||
type = types.uiSchema;
|
||||
value = {
|
||||
title = "Display name";
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
});
|
||||
in
|
||||
{
|
||||
module-options = fancy-wrapper.module;
|
||||
annotations = fancy-wrapper.annotations;
|
||||
}
|
||||
```
|
||||
|
||||
The `fancy-wrapper` would inject a custom `lib` where module-system-related functions will essentially act as `id` to preserve the information passed to them. On its outputs it will
|
||||
- reconstruct the module specification, throwing away the `meta` annotations
|
||||
- splice out the `meta` annotations and convert them to regular modules with the appropriate fields
|
||||
|
||||
Then, the value of `fancy-wrapper.annotations` would mirror the stuctrue of the module in the example be equivalent to something along the lines of:
|
||||
|
||||
```nix
|
||||
{ lib, ... }
|
||||
let
|
||||
inherit (lib) mkOption types;
|
||||
in
|
||||
{
|
||||
options = {
|
||||
initialUser = {
|
||||
displayName = mkOption {
|
||||
type = types.uiSchema;
|
||||
default = {
|
||||
label = "Display name";
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
Matching up the string identifiers could then be done programmatically by a function (supplied with the fancy wrapper library for use within the Nix language), so humans would be out of the loop.
|
||||
|
|
@ -1,31 +0,0 @@
|
|||
# 2025-05-06 developer sync
|
||||
|
||||
- @niols
|
||||
- got the full roundtrip of deploying with NixOps4 working in a NixOS test
|
||||
- this was not obvious how to do efficiently, especially because the deploying node keeps rebuilding all of the dependencies within the test (or fails because it wants to download some source)
|
||||
- there were some issues wiring up ACME for the reverse proxy
|
||||
- @fricklerhandwerk
|
||||
- investigated https://selfprivacy.org/
|
||||
- it's funded with a Fediversity subgrant, does something very similar for smaller-scale (self-hosted) deployments
|
||||
- they have [their own notion of application](https://selfprivacy.org/docs/theory/selfprivacy_modules/) defined in terms a special flake output (seems not to be enforced by e.g. module system types?)
|
||||
- very similar to what we're doing, and similar to ngi.nixos.org it tries to solve the problem that NixOS doesn't have its own notion of application, which is the main barrier to entry
|
||||
- we should probably try to converge on an upstream RFC, because multiple groups seem to be duplicating (and doing slightly divergent) work
|
||||
- @kiara: i recently played with snowfallorg's GUIs nixos-software-center and nix-configuration-editor again. the former tries to do an app store for nixpkgs (including icons for some applications), but was based on a categorization no longer followed since RFC 140 (which introduced `pkgs/by-name/`), tho it seems the more recent categorization effort (RFC 146) might revive such discoverability again. on efforts toward discoverability, we should also file flakehub there. if i look at ngi.nixos.org tho, i think what they do well there is discoverability of option modules / services - making me wonder what we mean when we say application here. if i were to then think about how to generalize that, i would look into using `.package` defaults to explicitly associate packages with `programs` / `services` defaulting to them, such that tools like search.nixos.org would link from `services.nginx` to package `nginx` and the other way around. hopefully, that could achieve something like NGI's associations at nixpkgs scale.
|
||||
- @fricklerhandwerk: yes, leveraging the `.package` association would be an 80/20 shortcut to improve search.nixos.org, but ultimately it's a cludge until we have a proper data model for applications.
|
||||
- investigated https://github.com/ibizaman/selfhostblocks
|
||||
- it's not fully mature yet, but seems usable and would help us plug different e.g. auth, secrets, or storage backend if we adopt it
|
||||
- @kiara: big fan here, already indicated to pierre i'd be down to help out as shepherd once he formally files the proposal as RFC
|
||||
- will meet the developer at Zurich ZHF end of May
|
||||
- all of this seems vaguely related with @roberth's [modular services](https://github.com/NixOS/nixpkgs/pull/372170)
|
||||
- one could argue that modular services abide to "canonical" contracts (in terms of SelfHostBlocks), in the sense that they live in the NixOS options tree
|
||||
- @kiara: this PR seems a prerequisite to doing their selfhostblocks' thing in nixpkgs, yeah
|
||||
- also investigated https://clan.lol/blog/vars/
|
||||
- if viewed in terms of SelfHostBlocks and modular services, `vars` proposes a canonical contract for wiring up files at evaluation time and producing them (somehow, typically at activation time since it's aimed at secrets)
|
||||
- they plan to build an interface for exchanging values at service runtime (which sounds reasonable)
|
||||
- @kiara: i'd be interested to read up on this plan - at Planet Nix they did mention theoretical integrations like with vault/openbao. i have been playing with their outstanding PR, which seems to heavily lean on backend implementation to do the heavy lifting. their monorepo seems to have more functionality already (including [different modules](https://git.fediversity.eu/Fediversity/Fediversity/issues/314)), but unfortunately is fairly tightly coupled with the clan use-case, making it harder to play around with than their simpler PR-oriented [flake](https://github.com/Lassulus/vars).
|
||||
- thanks @niols for helping with coming up with that clarification
|
||||
- these similarities indicate that it's a worthwhile problem to solve
|
||||
- when combining these ideas, we may e.g. have a canonical interface for applications
|
||||
- @kiara
|
||||
- refactored the build setup, with reviews from @fricklerhandwerk
|
||||
- kept iterating on the terraform deployment
|
||||
|
|
@ -1,35 +0,0 @@
|
|||
# 2025-06-11 Fediversity developer sync
|
||||
|
||||
- @kiara has been updating the project proposal to reflect current ideas
|
||||
- https://git.fediversity.eu/kiara/fedi-goals/src/branch/rewrite/
|
||||
- need to make sure all stakeholders are on board with the updated vision
|
||||
- new slated project manager would need to know what they're signing up for
|
||||
- we reviewed and discussed the draft
|
||||
|
||||
- @niols got the full integration test for deploying via the panel to pass
|
||||
- https://git.fediversity.eu/Fediversity/Fediversity/pulls/361
|
||||
- we tinkered on reducing the number of hacks involved
|
||||
- @fricklerhandwerk had some ideas for that, but the sketches need cleanup
|
||||
- https://git.fediversity.eu/Fediversity/Fediversity/pulls/364
|
||||
- @kiara and @fricklerhanderk continued editing the adjustments to the project proposal
|
||||
- @kiara: whether/how to concentrate on external contributors (and if so, how to sensibly reflect that in a key result)
|
||||
- @kiara: whether keeping the fediverse in even helps communicate our mission, considering fediversity could not fix the fediverse if we wanted to (given speed of adoption imo def isn't about self-hosting)
|
||||
- @fricklerhandwerk incorporated discussion results into the writeup
|
||||
- https://git.fediversity.eu/kiara/fedi-goals/pulls/2
|
||||
- https://git.fediversity.eu/kiara/fedi-goals/pulls/3
|
||||
|
||||
## Draft success metrics for the adjusted objectives
|
||||
|
||||
- Implement a way to run online services emphasizing user autonomy and data portability
|
||||
- Integration tests pass for
|
||||
- Setting up a fediversity hosting environment from a declarative configuration
|
||||
- Configuring, deploying, and migrating a set of dummy applications
|
||||
- Code passes data protection audit
|
||||
- Disseminate our results by engaging the open-source community to further expand on work in this direction
|
||||
- Present results on at least 3 conferences
|
||||
- At least 5 applications compatible with Fediversity thanks to external contributions by 2027-03
|
||||
- Exploit our work by enabling reproducible deployments of an initial set of portable applications
|
||||
- There are 3 fediverse applications available out of the box:
|
||||
- Mastodon
|
||||
- PeerTube
|
||||
- Pixelfed
|
||||
|
|
@ -1,12 +0,0 @@
|
|||
Attendees: @niols @kiara @fricklerhandwerk
|
||||
|
||||
- updated the project board
|
||||
- made some clarifications around splitting https://git.fediversity.eu/Fediversity/Fediversity/pulls/389 into manageable chunks
|
||||
- agreed on a general strategy to get a grip on the project layout:
|
||||
- migrate everything to modules
|
||||
- keep using flake-parts but don't use the flake parts except for CI checks
|
||||
- we may simply swap it out with our custom modules eventually, since most of them will be custom anyway
|
||||
- eventually we will be able to render most of contributor documentation via a Git hook
|
||||
- a few small steps already pushed as PRs
|
||||
- @niols and @kiara will focus on speeding up CI and making the runner reproducible
|
||||
- @fricklerhandwerk will keep developing the data model with @kiara
|
||||
|
|
@ -1,16 +0,0 @@
|
|||
Attendees: @kiara @fricklerhandwerk
|
||||
|
||||
- Discussed @fricklerhandwerk's WIP branch for implementing https://git.fediversity.eu/Fediversity/Fediversity/issues/103
|
||||
- The resource policy idea seems sound
|
||||
- The test sample doesn't look minimal at first glance, but in fact is
|
||||
- An entire NixOS configuration is only minimal in terms of resource policy -- just put it in a VM
|
||||
- An application that configures a whole NixOS needs to set many more things to make it run
|
||||
- The login-shell sample also allows us to explicitly enumerate resource-specific configuration options to demonstrate how they're declared and used
|
||||
- We re-iterated on the stance not to touch actual applications before we have the whole workflow tested with samples
|
||||
- Our packaged applications are already tested and in a state where we could translate them to the proper data model mechanically once it's in place and well-understood, so this will be a well-scoped problem for next year
|
||||
- It emerged again that we need to figure out a notion of compatibility (and therefore versioning) before being able to model migrations
|
||||
- Once the data model draft type-checks and the tests pass, this will be the next research question
|
||||
- We need to check if we want or have to make simplifying assumptions, such as not allowing version rollbacks
|
||||
- Chances are, once we have compatibility clarified, migrations will be trivial
|
||||
- @kiara will spend some time today debugging the draft
|
||||
- Likely we'll need the next week to finish that part and play with it a bit, such as by adding a few more test cases.
|
||||
|
|
@ -1,28 +0,0 @@
|
|||
Attendees: @fricklerhandwerk @niols @kiara
|
||||
|
||||
- @fricklerhandwerk
|
||||
- almost completed the data model up to deployment, including a test
|
||||
- @kiara fixed up some typos and evaluation errors
|
||||
- remaining is to mold `nixops4Deployment` into a type that is accepted
|
||||
- started compiling the mid-term technical report
|
||||
- will pause work on the data model until that's done (next week)
|
||||
- @niols worked on extracting a minimal flake for the test
|
||||
- (discussed how to handle lazy/strict source closures)
|
||||
- @kiara
|
||||
- tried containerizing the CI but it didn't work out yet
|
||||
- setting up a cache may improve turnaround time by a lot
|
||||
- will pair with @niols the week after next
|
||||
- tried patching the workflow to enable automatic dependency updates, made small progress
|
||||
- we can do dependency bumps manually for now
|
||||
- will pause work on CI until the technical report is done
|
||||
- todo for end-to-end beta: (REST) API for interacting with a runtime environment (general idea already settled in earlier discussions)
|
||||
- GET json schema for configuring applications
|
||||
- GET configuration
|
||||
- POST configuration
|
||||
- POST deploy
|
||||
- GET deployment (version, config, status, ...)
|
||||
- GET (stream) deployment progress
|
||||
- Webhook: deployment state updates, e.g. completed, failed, ...
|
||||
- TODO: workflow for migration
|
||||
- ...
|
||||
-
|
||||
|
|
@ -1,20 +0,0 @@
|
|||
Attendees: @kiara @fricklerhandwerk @niols
|
||||
|
||||
- CI still bad: checkout action flaky, secrets exposed to all contributors
|
||||
- We discussed switching to Gerrit (for review suggestions) and buildbot-nix (for CI)
|
||||
- It will be a lot of effort, but it's already a lot of effort and we better spend it now than when more people join the project
|
||||
- Chances are this will solve the secrets issue automatically
|
||||
- Regressions in Proxmox provisioning
|
||||
- needs tests and docs, `proxmox-provision.sh` was written ad hoc beginning of the year
|
||||
- we haven't been exercising our knowledge of provisioning since
|
||||
- would be nice to rewrite in Python, also as a way to turn it into a NixOps4 resource provider
|
||||
- NixOps4 future:
|
||||
- @roberth signaled the path to nested deployments may not be all that long
|
||||
- @fricklerhandwerk: currently our use case is perfectly suited by the state of affairs (especially having everything one language), but eventually we'll need something more powerful
|
||||
- @niols: dry run threatens to be a can of worms with nested deployments
|
||||
- @fricklerhandwerk: we'd need to mock away everything, we don't have a programming pattern for that yet (sigh)
|
||||
- @niols: for now we expose only the NixOS configurations to get evaluated separately
|
||||
- @kiara kept dabbling at the data model, fixing small issues
|
||||
- @fricklerhandwerk will go through the WIP branch and cherry-pick what works
|
||||
- @niols will add tests to provisioning code to fix regressions from recent refactorings
|
||||
- will start refactoring `infra/flake-parts.nix` to remove the wild function passing
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 82 KiB After Width: | Height: | Size: 95 KiB |
|
|
@ -1,5 +1,4 @@
|
|||
@startgantt
|
||||
skinparam backgroundcolor transparent
|
||||
|
||||
<style>
|
||||
ganttDiagram {
|
||||
|
|
@ -13,7 +12,7 @@ ganttDiagram {
|
|||
}
|
||||
</style>
|
||||
|
||||
2024-12-20 to 2025-01-05 is closed
|
||||
2024-12-20 to 2025-01-5 is closed
|
||||
2025-07-01 to 2025-08-31 is closed
|
||||
Project starts 2023-12-01
|
||||
projectscale monthly
|
||||
|
|
@ -21,52 +20,47 @@ projectscale monthly
|
|||
[Reporting period 1] happens at 2025-05-31
|
||||
Separator just at [Reporting period 1]'s end
|
||||
-- WP1 Project Management --
|
||||
[M1 First ActivityPub presence] as [a1] starts 2023-12-29 and requires 7 days and is 100% completed
|
||||
[D1.1 Data Management Plan] as [a11] starts 2023-12-01 and ends 2024-02-29 and is 100% completed
|
||||
[M6 First Tech talk] as [a6] starts 2024-05-31 and requires 7 days and is 100% completed
|
||||
[M7 First Workshop] as [a7] starts 2024-07-31 and requires 7 days and is 100% completed
|
||||
[M1 First ActivityPub presence] starts 2023-12-29 and requires 7 days and is 100% completed
|
||||
[D1.1 Data Management Plan] starts 2023-12-01 and ends 2024-02-29 and is 100% completed
|
||||
[M6 First Tech talk] starts 2024-05-31 and requires 7 days and is 100% completed
|
||||
[M7 First Workshop] starts 2024-07-31 and requires 7 days and is 100% completed
|
||||
|
||||
-- WP2 Vertical Hosting --
|
||||
[D2.5 Technical architecture document] as [b5] starts 2024-01-01 and ends 2025-06-15 and is 90% completed
|
||||
' [b5] is colored in Red
|
||||
[D2.1 Implementation] as [b1] starts 2024-03-01 and ends 2026-11-30 and is 50% completed
|
||||
[D2.2 Produce sample applications] as [b2] starts 2024-05-01 and ends 2026-11-30 and is 50% completed
|
||||
[D2.5 Technical architecture document] starts 2024-01-01 and ends 2024-03-29 and is 60% completed
|
||||
[D2.7 Analyze investment on fediverse] starts 2023-12-01 and ends 2024-04-30 and is colored in Red
|
||||
[D2.6 CI/CD setup] starts 2024-03-01 and ends 2024-10-31 and is colored in Red
|
||||
[D2.4 Nix Packages and NixOS Services] starts 2024-05-01 and ends 2024-11-29 and is 67% completed
|
||||
[D2.1 Software Release test environment] starts 2024-06-28 and ends 2024-11-29 and is 67% completed
|
||||
[D2.2 Software Release beta environment] starts 2025-01-01 and ends 2025-12-31 and is 0% completed
|
||||
[D2.3 Software release 1.0] starts 2025-12-01 and ends 2026-11-30 and is 0% completed
|
||||
|
||||
-- WP3 Vertical Public organizations --
|
||||
[D3.1 Requirements document] as [c1] starts 2025-01-01 and ends 2025-03-31 and is 100% completed
|
||||
[c1] is colored in Grey
|
||||
[D3.2 Pilot program proposals] as [c2] starts at [c1]'s end and ends 2025-05-31 and is 100% completed
|
||||
[c2] is colored in Grey
|
||||
[D3.3 Technical architecture document pilot programs] as [c3] starts at [c2]'s end and ends 2025-12-31 and is 100% completed
|
||||
[c3] is colored in Grey
|
||||
[D3.4 Nix service flakes, packages and services for pilot programs] as [c4] starts at [c2]'s end and ends 2025-12-31 and is 100% completed
|
||||
[c4] is colored in Grey
|
||||
[D3.5 CI/CD setup for pilot programs] as [c5] starts at [c2]'s end and ends 2025-12-31 and is 100% completed
|
||||
[c5] is colored in Grey
|
||||
[D3.6 Running Fediverse software for public organisations advisory] as [c6] starts at [c3]'s end and ends 2025-06-15 and is 100% completed
|
||||
[c6] is colored in Grey
|
||||
[D3.1 Requirements document] as [c1] starts 2025-01-01 and ends 2025-03-31 and is 0% completed
|
||||
[D3.2 Pilot program proposals] as [c2] starts at [c1]'s end and ends 2025-05-31 and is 0% completed
|
||||
[D3.3 Technical architecture document pilot programs] as [c3] starts at [c2]'s end and ends 2025-12-31 and is 0% completed
|
||||
[D3.4 Nix service flakes, packages and services for pilot programs] as [c4] starts at [c2]'s end and ends 2025-12-31 and is 0% completed
|
||||
[D3.5 CI/CD setup for pilot programs] as [c5] starts at [c2]'s end and ends 2025-12-31 and is 0% completed
|
||||
[D3.6 Running Fediverse software for public organisations advisory] starts at [c3]'s end and ends 2026-10-30 and is 0% completed
|
||||
[D3.6 Running Fediverse software for public organisations advisory] starts at [c4]'s end and ends 2026-10-30 and is 0% completed
|
||||
[D3.6 Running Fediverse software for public organisations advisory] starts at [c5]'s end and ends 2026-10-30 and is 0% completed
|
||||
|
||||
-- WP4 Open calls and grant management --
|
||||
[M2 Announcement open call] as [d2] starts 2023-12-29 and requires 7 days and is 100% completed
|
||||
[M3 First open call opens] as [d3] starts 2024-02-01 and requires 7 days and is 100% completed
|
||||
[M4 First batch of grantees selected] as [d4] starts 2024-03-29 and requires 7 days and is 100% completed
|
||||
[D4.1 Overview of granted projects] as [d41] starts 2026-07-01 and ends 2026-11-30 and is 0% completed
|
||||
[M2 Announcement open call] starts 2023-12-29 and requires 7 days and is 100% completed
|
||||
[M3 First open call opens] starts 2024-02-01 and requires 7 days and is 100% completed
|
||||
[M4 First batch of grantees selected] starts 2024-03-29 and requires 7 days and is 0% completed
|
||||
[D4.1 Overview of granted projects] starts 2026-07-01 and ends 2026-11-30 and is 0% completed
|
||||
|
||||
-- WP5 Enhancement and Usability --
|
||||
[D5.6 Setup UX design testlab] as [e6] starts 2023-12-01 and ends 2024-07-31 and is 100% completed
|
||||
[D5.1 User requirement document] as [e1] starts 2024-05-01 and ends 2024-08-30 and is 100% completed
|
||||
[D5.2 UX design] as [e2] starts 2024-09-02 and ends 2025-11-28 and is 100% completed
|
||||
[D5.3 UX design implementation] as [e3] starts 2025-12-01 and ends 2026-05-29 and is 100% completed
|
||||
[e3] is colored in Grey
|
||||
[D5.4 UX design user studies] as [e4] starts 2026-05-01 and ends 2026-09-30 and is 100% completed
|
||||
[e4] is colored in Grey
|
||||
[D5.5 Design iteration and final release] as [e5] starts 2026-05-01 and ends 2026-11-30 and is 100% completed
|
||||
[e5] is colored in Grey
|
||||
[D5.6 Setup UX design testlab] starts 2023-12-01 and ends 2024-07-31 and is colored in Red
|
||||
[D5.1 User requirement document] starts 2024-05-01 and ends 2024-08-30 and is colored in Red
|
||||
[D5.2 UX design] starts 2024-09-02 and ends 2025-11-28 and is 0% completed
|
||||
[D5.3 UX design implementation] starts 2025-12-01 and ends 2026-05-29 and is 0% completed
|
||||
[D5.4 UX design user studies] starts 2026-05-01 and ends 2026-09-30 and is 0% completed
|
||||
[D5.5 Design iteration and final release] starts 2026-10-01 and ends 2026-11-30 and is 0% completed
|
||||
|
||||
-- WP6 Outreach and Dissemination --
|
||||
[D6.1 Communication strategy] as [f1] starts 2023-12-01 and ends 2024-01-31 and is 100% completed
|
||||
[D6.2 Media package] as [f2] starts 2024-12-01 and ends at [c1]'s start and is 100% completed
|
||||
[D6.3 Communication report first period] as [f3] starts 2025-03-03 and ends 2025-04-30 and is 100% completed
|
||||
[D6.4 Communication report second period] as [f4] starts 2026-09-01 and ends 2026-10-30 and is 0% completed
|
||||
[D6.5 Developer outreach] as [f5] starts 2025-01-01 and ends 2026-11-30 and is 10% completed
|
||||
[D6.1 Communication strategy] starts 2023-12-01 and ends 2024-01-31 and is colored in Red
|
||||
[D6.2 Media package] as [f2] starts 2024-12-01 and ends at [c1]'s start and is 0% completed
|
||||
[D6.3 Communication report first period] starts 2025-03-03 and ends 2025-04-30 and is 0% completed
|
||||
[D6.4 Communication report second period] starts 2026-09-01 and ends 2026-10-30 and is 0% completed
|
||||
@endgantt
|
||||
|
|
|
|||
|
|
@ -1,13 +0,0 @@
|
|||
---
|
||||
title: Fediversity work package interdependencies
|
||||
---
|
||||
flowchart
|
||||
management["WP1: Project Management"]
|
||||
vertical["WP2: Vertical Hosting"]
|
||||
grants["WP4: Open calls and grant management"]
|
||||
ux["WP5: Enhancement & Usability"]
|
||||
dissemination["WP6: Outreach & Dissemination"]
|
||||
|
||||
management --> vertical & ux & dissemination & grants
|
||||
vertical --> ux
|
||||
vertical & ux & dissemination --> grants
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 43 KiB |
|
|
@ -1 +0,0 @@
|
|||
(import ./. { }).shell
|
||||
Loading…
Add table
Reference in a new issue