application offering delegated #369

New issue

Open

opened 2025-06-09 10:20:17 +02:00 by kiara · 0 comments

kiara commented

2025-06-09 10:20:17 +02:00

Owner

As a Fediversity user,
I want for Fediversity to not artificially limit its application offering,
so that I may use it to address my needs.

notes

supersedes #350.

alleviating concerns from #327

PoC:
- integration with single sign-on (#212) and LDAP (#337) for user management (or as a stop-gap, provisioning of initial user, see #178): SHB's SSO / LDAP contracts
- [~] compartmentalising state for backups/portability/redundancy (#123): SHB's backup contracts, see above
- migration actions such as rewrites of connections/URLs (#78): this is the main question here, see above
MVP:
- creating schemas of (identified relevant) settings (c.f. #195): #195
- hardening (#291): concerns to be filed upstream (probably at nixpkgs more often than SHB)
- [~] handling application upgrades (#159): should qualify as mentioned mitigation strategy 'using abstractions'
- [~] documentation (#86): address using info from Nix modules as per #86 (generated documentation) / [front-end] #195
post-MVP:
- coordinating with end-users to improve the user experience (c.f. #289): dynamics here should in principle remain similar, despite further applications, i.e. not necessarily resulting in application-specific code necessarily, although arguably feedback for unseen applications would be all the more relevant to see how well things generalize here
- [~] handling backward-incompatible setting interface changes (#159): for the most part should be few and/or automateable, see that ticket for details
applications supported in Nix/SelfHostBlocks: this is made into a presumption here

**As** a Fediversity user, **I want** for Fediversity to not artificially limit its application offering, **so that** I may use it to address my needs. ## notes - supersedes #350. <details> <summary> alleviating concerns from #327 </summary> 1. PoC: - [x] integration with single sign-on (#212) and LDAP (#337) for user management (or as a stop-gap, provisioning of initial user, see #178): SHB's SSO / LDAP contracts - [~] compartmentalising state for backups/portability/redundancy (#123): SHB's backup contracts, see above - [ ] migration actions such as rewrites of connections/URLs (#78): this is the main question here, see above 1. MVP: - [x] creating schemas of (identified relevant) settings (c.f. #195): #195 - [x] hardening (#291): concerns to be filed upstream (probably at nixpkgs more often than SHB) - [~] handling application upgrades (#159): should qualify as mentioned mitigation strategy 'using abstractions' - [~] documentation (#86): address using info from Nix modules as per #86 (generated documentation) / [front-end] #195 1. post-MVP: - [x] coordinating with end-users to improve the user experience (c.f. #289): dynamics here should in principle remain similar, despite further applications, i.e. not necessarily resulting in application-specific code necessarily, although arguably feedback for unseen applications would be all the more relevant to see how well things generalize here - [~] handling backward-incompatible setting interface changes (#159): for the most part should be few and/or automateable, see that ticket for details 1. [x] applications supported in Nix/SelfHostBlocks: this is made into a presumption here </details>