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 +154
1 changed files with 154 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files
Showing only changes of commit 6e385a527d - Show all commits

154
architecture.md
View file

@ -220,6 +220,160 @@ Whereas the core abstraction in Fediversity is a NixOS configuration module, a m
![](https://git.fediversity.eu/Fediversity/meta/raw/branch/main/architecture-docs/host-architecture.png)
### Sample configuration schema
Whereas Nix(OS) option modules use Nix to specify types, in order to communicate the expected schema to other tools such as web applications, we use [JSON Schema](https://json-schema.org/) as an intermediate format, building upon [earlier work converting between such schemas by Nix collective Clan](https://clan.lol/blog/json-schema-converter/).
An example of such a schema might looks as follows:
```json
{
"$exportedModuleInfo": {
"path": []
},
"$schema": "http://json-schema.org/draft-07/schema#",
"additionalProperties": false,
kiara marked this conversation as resolved Outdated
fricklerhandwerk commented 2025-06-06 12:39:36 +02:00
Outdated
Review
Copy link

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 would be as follows. VMs in question run Fediversity to offer our supported applications. The diagram shows an example of how different components could be fit together, based on what Fediversity offers as a framework (note that this would depend on the respective services and host-facing backends to be implemented appropriately):

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 would be as follows. VMs in question run Fediversity to offer our supported applications. The diagram shows an example of how different components could be fit together, based on what Fediversity offers as a framework (note that this would depend on the respective services and host-facing backends to be implemented appropriately):
"properties": {
"domain": {
"$exportedModuleInfo": {
"path": [
"domain"
]
},
"default": "fediversity.net",
"description": "Apex domain under which the services will be deployed.\n",
"enum": [
"fediversity.net"
]
},
"enable": {
"$exportedModuleInfo": {
"path": [
"enable"
]
},
"default": false,
"description": "Whether to enable Fediversity configuration.",
"examples": [
true
],
"type": "boolean"
},
"initialUser": {
"$exportedModuleInfo": {
"path": [
"initialUser"
]
},
"default": null,
"description": "Some services require an initial user to access them.\nThis option sets the credentials for such an initial user.\n",
"oneOf": [
{
"type": "null"
},
{
"$exportedModuleInfo": {
"path": [
"initialUser"
]
},
"additionalProperties": false,
"properties": {
"displayName": {
"$exportedModuleInfo": {
"path": [
"initialUser",
"displayName"
]
},
"description": "Display name of the user",
"type": "string"
},
"email": {
"$exportedModuleInfo": {
"path": [
"initialUser",
"email"
]
},
"description": "User's email address",
"type": "string"
},
"password": {
"$exportedModuleInfo": {
"path": [
"initialUser",
"password"
]
},
"description": "Password for login",
"type": "string"
},
"username": {
"$exportedModuleInfo": {
"path": [
"initialUser",
"username"
]
},
"description": "Username for login",
"type": "string"
}
},
"required": [
"displayName",
"email",
"password",
"username"
],
"type": "object"
}
]
},
"forgejo": {
"$exportedModuleInfo": {
"path": [
"forgejo"
]
},
"default": null,
"description": "Configuration for the Forgejo service\n",
"oneOf": [
{
"type": "null"
},
{
"$exportedModuleInfo": {
"path": [
"forgejo"
]
},
"additionalProperties": false,
"properties": {
"enable": {
"$exportedModuleInfo": {
"path": [
"forgejo",
"enable"
]
},
"default": false,
"description": "Whether to enable Forgejo.",
"examples": [
true
],
"type": "boolean"
}
},
"type": "object"
}
]
}
},
"type": "object"
}
```
## 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: