applications imported from contract-based implementations #601

New issue

Open

opened 2025-12-02 15:43:01 +01:00 by kiara · 0 comments

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 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:

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
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).

**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](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.) ### implementation notes This may be achieved by ensuring such services may be transparently wrapped, ideally with no service-specific code on our end: - 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 - 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)).