initial focus on single application for development

kiara commented

2025-05-06 14:45:48 +02:00

Owner

As a developer,
I want for our code-base to focus on a single application (until things mature - see #350),
so that development may be sped up until best practices materialize.

notes

c.f. #369, which attempts to challenge concerns here by delegating implementation details to SelfHostBlocks.

potential application-specific concerns here included:

PoC:
- compartmentalising state for backups/portability/redundancy (#123)
- migration actions such as rewrites of connections/URLs (#78)
- integration with single sign-on (#212) and LDAP (#337) for user management (or as a stop-gap, provisioning of initial user, see #178)
MVP:
- handling application upgrades (#159)
- creating schemas of (identified relevant) settings (c.f. #195)
- documentation (#86)
- hardening (#291)
post-MVP:
- handling backward-incompatible setting interface changes (Fediversity/Fediversity#159 (comment))
- coordinating with end-users to improve the user experience (c.f. #289)
if missing first-class Nix support:
- packaging for Nix
- creating NixOS service module
- integrating with identified contracts (see #369)
- maintaining the above on version updates (#127)
- coordinating with upstream developers on immutable-friendly development, particularly in case of applications written in PHP

**As** a developer, **I want** for our code-base to focus on a single application (until things mature - see #350), **so that** development may be sped up until best practices materialize. ## notes c.f. #369, which attempts to challenge concerns here by delegating implementation details to SelfHostBlocks. potential application-specific concerns here included: - PoC: - compartmentalising state for backups/portability/redundancy (#123) - migration actions such as rewrites of connections/URLs (#78) - integration with single sign-on (#212) and LDAP (#337) for user management (or as a stop-gap, provisioning of initial user, see #178) - MVP: - handling application upgrades (#159) - creating schemas of (identified relevant) settings (c.f. #195) - documentation (#86) - hardening (#291) - post-MVP: - handling backward-incompatible setting interface changes (https://git.fediversity.eu/Fediversity/Fediversity/issues/159#issuecomment-4548) - coordinating with end-users to improve the user experience (c.f. #289) - if missing first-class Nix support: - [packaging](https://github.com/NixOS/nixpkgs/tree/master/pkgs) for Nix - creating NixOS [service module](https://github.com/NixOS/nixpkgs/tree/master/nixos/modules) - integrating with identified contracts (see #369) - maintaining the above on version updates (#127) - coordinating with upstream developers on immutable-friendly development, particularly in case of applications written in PHP

👍 1

kiara changed title from ~~development process slowed down by use of multiple applications~~ to first focus on single application for development

2025-05-06 14:46:14 +02:00

kiara added a new dependency

2025-05-06 14:46:31 +02:00

#224 automated dev-ops workflows

kiara commented

2025-05-06 15:18:25 +02:00

Author

Owner

in case we are to try this, i'm a bit on the fence still what to prioritize (tho i totally agree on @niols's idea to focus on just cowsay in tests first):

mastodon (test broken - see #34) seems sorta lightweight (at least compared to our current pixelfed test), has mature permissions (custom roles), fairly standard setup (postgres/redis/elasticsearch), oidc/ldap built-in
pixelfed (test broken - see #33) koen has pushed over having their creator on board
peertube we have a working test for (currently - see #318)

in case we are to try this, i'm a bit on the fence still what to prioritize (tho i totally agree on @niols's idea to focus on just `cowsay` in tests first): - mastodon (test broken - see #34) seems sorta lightweight (at least compared to our current pixelfed test), has mature permissions (custom roles), fairly standard setup (postgres/redis/elasticsearch), oidc/ldap built-in - pixelfed (test broken - see #33) koen has pushed over having their creator on board - peertube we have a working test for (currently - see #318)

kiara commented

2025-05-06 15:29:50 +02:00

Author

Owner

this would also clean up the issue tracker a bit for now, see e.g. dependencies of #178 (i.e. #189 #190 #191 #192 #193 #194)

kiara added this to the Fediversity project

2025-05-06 15:50:38 +02:00

Niols commented

2025-05-07 09:07:51 +02:00

Owner

Also, Procolix has a working cluster of machines serving a HA Pixelfed, so we could just nixify that and think of how to deploy it automatically. (If Procolix were willing to share the infrastructure of the cluster in one form or another.) Mastodon and Peertube are also slightly more complicated to deal with because they have notions of front-end, workers, and things like that.

That being said, Procolix has the knowledge so it seems perfectly feasible to make a cluster for Mastodon or Peertube, and their documentation and communities (especially Mastodon) are much bigger and better, which would help a lot.

Also, Procolix has a working cluster of machines serving a HA Pixelfed, so we could just nixify that and think of how to deploy it automatically. (If Procolix were willing to share the infrastructure of the cluster in one form or another.) Mastodon and Peertube are also slightly more complicated to deal with because they have notions of front-end, workers, and things like that. That being said, Procolix has the knowledge so it seems perfectly feasible to make a cluster for Mastodon or Peertube, and their documentation and communities (especially Mastodon) are much bigger and better, which would help a lot.

kiara added the

type: user story

label

2025-05-20 16:16:17 +02:00

~~kiara referenced this issue 2025-05-28 09:50:17 +02:00~~

pooling instances to shared VMs #322

kiara commented

2025-05-28 14:42:14 +02:00

Author

Owner

i wonder if perhaps Forgejo itself would make for a good initial application given:

it's in SelfHostBlocks, potentially reducing application-specific code (see #369)
we needed it for our own infra anyway (#370)
as per the above, it allows our dev team to own #225 as our own initial client
relevant features are merged upstream (c.f. vaultwarden where SSO is still a PR)
it doesn't hinge on a language as unsafe as PHP like Nextcloud does

i wonder if perhaps [Forgejo](https://forgejo.org/) itself would make for a good initial application given: 1. it's in SelfHostBlocks, potentially reducing application-specific code (see #369) 1. we needed it for our own infra anyway (#370) 1. as per the above, it allows our dev team to own #225 as our own initial client 1. relevant features are merged upstream (c.f. vaultwarden where SSO is still a PR) 1. it doesn't hinge on a language as unsafe as PHP like Nextcloud does

Rows
Columns

initial focus on single application for development #327

notes