Updated readme based on new insights and plans #978
No reviewers
fediversity/developers
Labels
No labels
ambition
application-offering
ambition
configure-applications
ambition
front-end
ambition/install-applications
ambition
security
ambition
switch-host
ambition
update-applications
ambition
user-management
blocked
component
api-service
component
fediversity-panel
component
nixops4
documentation
points
0
points
0.5
points
1
points
13
points
2
points
21
points
3
points
34
points
5
points
55
points
8
points
infinite
productisation
project-management
question
role
application-developer
role
application-operator
role
hosting-provider
role
maintainer
security
technical debt
testing
type
bug
type
deliverable
type
key-result
type
objective
type
task
type
unclear
type
user-story
user experience
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
fediversity/fediversity!978
Loading…
Reference in a new issue
No description provided.
Delete branch "koen/fediversity:main"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
With the addition of Edsger Institute and the revised plan committed to the EC some of the parameters have changed.
A more strict focus on Nix has been re-introduced in to the plan: based on the work of Kiara in the last months, the need to include Proxmox in the mix has been removed. We are quite sure the plan can be executed without Debian based Proxmox.
The main focus on Fediverse applications has been removed from the text, since also personal (time) management tools and productivity tools are moving more into scope of the project.
@ -53,3 +55,3 @@- OperatorThey select the applications they want to run (Mastodon, Pixelfed, Matrix, etc.).They select the applications they want to run (Mastodon, Pixelfed, Matrix, Nextcloud, Immich etc.).immich i think is missing from our list (#380) so far?
not that we wouldn't wanna scale things, but it's perhaps best to set realistic expectations for the time being.
@ -67,2 +71,3 @@Given initial operators will be universities, users would be staff or students.The Fediversity offering is aimed at one or two operators servicing 1 to 100 users. Where one hosting provider has tobe able to scale to at least 1000 of operators.this scope should maybe get edsger buy-in
What does "one or two operators servicing 1 to 100 users," mean? It sounds like one Operator that is represented by one or two people, otherwise scaling to 1000 Operators would somehow imply running 500-1000 "Fediversity offering"s.
i share your reading here
@koen?
@ -58,3 +60,3 @@They pay the hosting provider for registering a domain name, maintaining physical resources, and monitoring deployments.Initially, Fediversity is targeted at organisations, such as universities.What is always included in the offering is a domain name and e-mail.this sounds closer to the productization side than to the core library
Ownership of the domain needs to be clearly attributed to Operators. Migrations are useless if you can't take your domain name with you. Hosting Providers will need to be able to work with domains they have not registered, be it as part of a migration, in which case another Hosting Provider would've registered the domain, or simply because the Operator wants to have full control over their domain.
The requirement for e-mail (hosting I presume?) is not quite clear to me. Hosting Providers will want an Operator e-mail address that they don't host themselves in order for billing issues to not complicate communication with the Operator, I assume? If the Operator must already have an e-mail, that could serve for the various "Contact Support/Admin/Moderators" features that Applications have, so why are Operators required to pay for e-mail hosting?
i think this product offering procolix intends to offer.
for the base case we'll presume the hosting provider has the access to the domain needed for what we intend to offer (which includes automation of the migrations to other hosting providers), to defer the more complex use-cases to not have to deal with all problems at the same time.
note that the initial target audience isn't so much the traditional self-hosting audiences, but more non-technical audiences - for the former audience existing solutions (having to yourself deal with Debian or NixOS) would likely suffice.
Access to DNS records and ownership of a registration are separate concepts. Being explicit about the ownership seems important to me because we're talking about non-technical Operators who may not realize they may be locked in through the domain name.
okay so. the migration route would make the 'lock-in' less to a hosting provider, more to the piece of (open-source) software. that said, i don't think this implies lock-in: so think we'd need the access to perform what operators would expect of us, but that isn't to say exclusive access.
in the long run, each of those steps could function with (granular) consent, better supporting the use-case of better leaving operators in charge of each step.
i think the main point here is really this is about a short-term scoping issue, rather than lack of intent to empower people.
@ -11,3 +11,3 @@Note that Fediversity is not about self-hosting.There already exist solutions for self-hosting, but they're not suitable for what we're trying to do.The ones we're aware of require substantial technical knowledge and time commitment by operators, especially for scaling to thousands of users.The ones we're aware of require substantial technical knowledge and time commitment by system-operators, especially for scaling to thousands of users.Consider
system administratorsto avoid confusion with Operator as defined in Actors.i think probably all these are intended to refer to the same group here? but if we didn't like the term here, we should maybe ask if we should consider changing it more widely.
It's just that Operators are defined to be non-technical (or at least not require technical knowledge) so they can't really be the same group when we're talking about selfhosters with technical know-how.
maybe pedantic, but in this case, i believe that makes the case for our proposition: you need know-how you may not have, and therefore we may pose a more viable alternative
@ -76,3 +81,3 @@- ApplicationUser-facing software (e.g. from Fediverse) run by the hosting provider for an operator.User-facing software run fully automated by the hosting provider for an operator."Fully automated," can mean many things and is an important point to align on IMO. As phrased here it sounds like Hosting Providers deploy Applications at the press of a button and this can only happen after Application domain-specific knowledge has been encoded by the Hosting Provider (in the form of a NixOS configuration).
As an example, Mastodon requires many services like a PostgreSQL database to store content and Sidekiq for background processing. Hosting Providers know their hardware so they know best how to configure these. Fediversity could at most provide very conservative defaults, running all of the services on a single server/hypervisor, with low connection limits and thread counts. So, single press of a button, yes, but only after the Hosting Provider has set up a deployment configuration with knowledge of the Application's domain, most Applications probably require a SQL database, Sidekiq might not be so common, ElasticSearch is optional for Mastodon (offer it as an extra feature Operators can opt into or always enable it because it takes load off of database servers...).
so, i think to some extent this is intended to improve over time
hosting providers shouldn't need to know nix. making them do it [edit: have domain-specific knowledge on deployed applications] is the status quo (where AWS got big and small companies cannot compete) - the point is reproducibility allows us to cooperate using open source.
could hosting providers fork? yeah, but i'm not sure we're ready to answer all the questions that might bring yet.
that said, i think reproducibility is part of project requirements - tho to be fair, perhaps it could be possible to gather info in production before reaching such full (reproducible) automation.
Reproducibility and automation are different things. The former implies no limitations on the domain knowledge of the actor doing the reproducible action.
I can easily imagine Fediversity providing a solid setup for Hosting Providers that run a single (beefy) server. But there's mention of scaling to 1000 Operators, that may (probably will) go beyond administering a single server. How can Fediversity tailor deployments to unknown setups?
The Application domain-specific knowledge does not necessarily have to be provide in the form of a Nix configuration, we could have a Hosting Provider "panel" but so far that was limited to being an interface for non-technical Operators.
reproducibility i mentioned mostly to summarize 'encoded [...] in the form of a NixOS configuration'.
initially, agree, tho i'm not sure our included batteries have to be unscalable by definition (taking into account the overhead of such more scaleable options) - tho tbf such concerns shouldn't be anywhere close for now.
agree we probably shouldn't have to worry about this for the foreseeable future
yeah, procolix wants this as well. while there'd be at least access to the nodes in the hosting provider group, perhaps on top of admin access to api+panel web apps, as well as #599, #223, #617, this topic could use fleshing out still.
right - batteries-included just means that with less such knowledge things could work as well, depending on the maturity of Fediversity (which as per the data model's 'resource mapping' can support pluggable logic on how to allocate resources to set-ups - now added to #341).