fediversity/fediversity

Fork 10

applications imported from contract-based implementations #601

New issue

Closed

opened 2025-12-02 15:43:01 +01:00 by kiara · 1 comment

kiara commented

2025-12-02 15:43:01 +01:00

Owner

As a Fediversity maintainer,
I want for Fediversity to be able to reuse existing application implementations,
so that we may expand our offering while focusing on our core value-proposition.

notes

selfhostblocks intro

SelfHostBlocks is an NGI project raising the level of abstraction possible in NixOS services by introducing the concept of contracts, providing a consumer/provider dichotomy mirroring our own dichotomy of resource-consuming applications versus resource-providing host environments.
SelfHostBlocks additionally implements a number of services using such contract consumers and iterating on their UX, which raises the question if we could reuse such work. (their service implementations are opinionated to the point of specifying filesystems, though nixpkgs-based service modules implementing contracts may offer a less opinionated alternative - maybe with those two together we can find something that works for us.)

implementation notes

This may be achieved by ensuring such services may be transparently wrapped, ideally with no service-specific code on our end:

implementation attempts
- data model experiment
- wip experiment
  - initially: maybe expose just enable to operator
  - eventually: handle SelfHostBlocks contract requests from environments, other (sub)modules exposed to operator/environment when any of their children are, expose non-contract non-submodule options to operator
    - note that contracts would not suffice to judge who should select a given option, with at least many options relevant to hosts not part of contracts (even before their reduced scope).
migrations: presuming adherance to backup (#126) and database backup (#124) contracts, would need:
- back-up contracts covering:
  - object storage (#125)
    - is this covered through the backup contract?
  - key value stores (valkey/redis)
    - is this supported in backup over the mount contract (usage)?
  - queues: unfortunately badly standardized, while back-up integrators like borgmatic so far also seem limited to files/databases - tho arguably the queues must be storing their data in terms of those as well.
from our existing Fediverse-based demo code (if mostly relevant as examples now given #327):
- sub-domain: could allow user-supplied application-specific sub-domains (#76), tho even that likely should not need application-specific code on our end
- SMTP
  - mastodon
  - peertube (not currently used from our end)
- service-specific
  - mastodon
    - streamingProcesses: no universal value for us to set for a NixOS configuration although some sane default might be desirable. otherwise, we might expose this transparently to users for configurations. in our host setting (#349) we might be able to automate this from our end (pending #116).
  - pixelfed
    - settings.OPEN_REGISTRATION: no sane universal default, so pass to users

**As a** Fediversity maintainer, **I want** for Fediversity to be able to reuse existing application implementations, **so that** we may expand our offering while focusing on our core value-proposition. ## notes <details> <summary> selfhostblocks intro </summary> [SelfHostBlocks](https://github.com/ibizaman/selfhostblocks) is an NGI project raising the level of abstraction possible in NixOS services by introducing the concept of [contracts](https://shb.skarabox.com/contracts.html), providing a consumer/provider dichotomy mirroring our own dichotomy of resource-consuming applications versus resource-providing host environments. SelfHostBlocks additionally implements a number of [services](https://shb.skarabox.com/services.html) using such contract consumers and iterating on their UX, which raises the question if we could reuse such work. (their service implementations are opinionated to the point of specifying filesystems, though nixpkgs-based service modules implementing contracts may offer a less opinionated alternative - maybe with those two together we can find something that works for us.) </details> ### implementation notes This may be achieved by ensuring such services may be transparently wrapped, ideally with no service-specific code on our end: - implementation attempts - [data model experiment](https://git.fediversity.eu/fediversity/fediversity/pulls/500) - [wip experiment](https://github.com/KiaraGrouwstra/selfhostblocks/compare/main...repl-fediversity) - initially: maybe expose just `enable` to operator - eventually: handle SelfHostBlocks contract requests from `environments`, other (sub)modules exposed to operator/environment when any of their children are, expose non-contract non-submodule options to operator - note that contracts would not suffice to judge who should select a given option, with at least many options relevant to hosts not part of contracts (even before their [reduced scope](https://github.com/NixOS/nixpkgs/pull/432529#issuecomment-3686663833)). - migrations: presuming adherance to [backup](https://shb.skarabox.com/contracts-backup.html) (#126) and [database backup](https://shb.skarabox.com/contracts-databasebackup.html) (#124) [contracts](https://shb.skarabox.com/contracts.html), would need: - [ ] back-up contracts covering: - [ ] [object storage](https://github.com/ibizaman/selfhostblocks/issues/469) (#125) - is this covered through the `backup` contract? - [ ] key value stores (valkey/redis) - is this supported in `backup` over the [`mount` contract](https://github.com/ibizaman/selfhostblocks/commit/56c06b4404f88a3935f33a84a3632ec766d882c8#diff-20e5a0c8f59a814070642e2eaa80661575ae82c8e44c7c2947250191004916d5) ([usage](https://github.com/ibizaman/selfhostblocks/commit/896c376b6d27b05a76c745352fd7f6b81cf34329#diff-cd686f8fae82dad77c3e42d889593b23f57e8814c7bb5f178cb859ecbcc36021R225-R240))? - [ ] queues: unfortunately badly standardized, while back-up integrators like [borgmatic](https://projects.torsion.org/borgmatic-collective/borgmatic/src/branch/main/borgmatic/hooks/data_source) so far also seem limited to files/databases - tho arguably the queues must be storing their data in terms of those as well. - from our existing Fediverse-based demo code (if mostly relevant as examples now given #327): - [x] sub-domain: could allow user-supplied application-specific sub-domains (#76), tho even that likely should not need application-specific code on our end - [ ] [SMTP](https://github.com/ibizaman/selfhostblocks/issues/471) - [mastodon](https://search.nixos.org/options?query=mastodon.smtp) - [peertube](https://search.nixos.org/options?query=peertube.smtp) (not currently used from our end) - service-specific - mastodon - [ ] `streamingProcesses`: no universal value for us to set for a NixOS configuration although some sane default might be desirable. otherwise, we might expose this transparently to users for configurations. in our host setting (#349) we might be able to automate this from our end (pending #116). - pixelfed - [x] `settings.OPEN_REGISTRATION`: no sane universal default, so pass to users

kiara added the

type: task

label

2025-12-02 15:43:01 +01:00

kiara referenced this issue

2025-12-02 15:44:31 +01:00

contracts available in nixpkgs #602

kiara referenced this issue

2025-12-02 15:44:35 +01:00

contracts useable across nodes #603

kiara referenced this issue

2025-12-02 15:44:53 +01:00

contracts handle generation of ephemeral state #604

kiara referenced this issue

2025-12-02 15:44:59 +01:00

contracts provide single sign-on (SSO) integration #605

kiara referenced this issue

2025-12-02 15:45:04 +01:00

contracts provide LDAP integration #606

kiara referenced this issue

2025-12-02 15:45:20 +01:00

NixOS service service portability scripts standardized #607

kiara added a new dependency

2025-12-02 15:45:41 +01:00

#369 application offering delegated

kiara added a new dependency

2025-12-02 15:46:16 +01:00

#602 contracts available in nixpkgs

kiara added a new dependency

2025-12-02 15:46:22 +01:00

#603 contracts useable across nodes

kiara added a new dependency

2025-12-02 15:46:33 +01:00

#604 contracts handle generation of ephemeral state

kiara added a new dependency

2025-12-02 15:46:39 +01:00

#605 contracts provide single sign-on (SSO) integration

kiara added a new dependency

2025-12-02 15:46:56 +01:00

#606 contracts provide LDAP integration

kiara added a new dependency

2025-12-02 15:47:34 +01:00

#607 NixOS service service portability scripts standardized

kiara added a new dependency

2025-12-02 16:12:33 +01:00

#494 data model used

kiara added the

13 points

label

2025-12-02 22:04:36 +01:00

~~kiara referenced this issue 2025-12-02 23:34:51 +01:00~~

ensure application resilience #598

kiara referenced this issue

2025-12-03 12:59:39 +01:00

applications' NixOS modules use modular services #621

kiara removed a dependency

2026-04-03 20:46:08 +02:00

#603 contracts useable across nodes

kiara removed a dependency

2026-06-06 13:50:53 +02:00

#602 contracts available in nixpkgs

kiara removed a dependency

2026-06-06 15:39:08 +02:00

#606 contracts provide LDAP integration

kiara removed a dependency

2026-06-06 15:39:19 +02:00

#605 contracts provide single sign-on (SSO) integration

kiara removed a dependency

2026-06-06 15:39:26 +02:00

#604 contracts handle generation of ephemeral state

kiara removed a dependency

2026-06-06 15:47:58 +02:00

#369 application offering delegated

kiara added the

ambition

application-offering

label

2026-06-12 00:41:04 +02:00

kiara commented

2026-06-28 18:09:56 +02:00

Author

Owner

while contracts and their use could be upstreamed, this ticket honestly seems not realistic given:

the amount of code involved still to make applications work
settings exposed to operators should be cherry-picked (/ manually filtered) anyway

while contracts and their use could be upstreamed, this ticket honestly seems not realistic given: 1. the amount of code involved still to make applications work 1. settings exposed to operators should be cherry-picked (/ manually filtered) anyway

kiara closed this issue

2026-06-28 18:09:56 +02:00