diff --git a/architecture-docs/2025-03-05 design meeting.md b/architecture-docs/2025-03-05 design meeting.md new file mode 100644 index 0000000..891996c --- /dev/null +++ b/architecture-docs/2025-03-05 design meeting.md @@ -0,0 +1,76 @@ +# fediversity design meeting 2025-03-12 + +present: slik (thijs, tiemon) + procolix (lois, kevin, kiara) + +- thijs: what is the project called and who does what? +- thijs: how do you see front-end dev for this? +- kiara: we don't need you to do an implementation using some front-end framework - just the design will do. +- thijs: what will be the concrete deliverable then for the demo? +- kiara: if for fediforum we do not have the design implemented yet that is acceptable. +- thijs: maybe we will make it in time. +- tiemon: sounds ambitious. +- thijs: should we deliver code or would an interactive design do? +- kiara: an interactive design will do. +- kiara: could this handle animations too? +- tiemon: yes. +- thijs: could you explain some terminology here like fediverse, protagio, providers, panel? +- kevin: *explains* +- thijs: which applications will you do, and how do these get added? +- kiara: mastodon, pixelfed and peertube at least. +- kevin: *explains about fediversity sub-grants* +- thijs: who will select what applications get added then? +- kiara: formally the Open Internet Discourse Foundation. +- thijs: are there set criteria for this? are these political decisions? +- kiara: fediversity is open-source, tho as maintainers we will eventually need to make decisions take into account our capacity given the maintenance work involved. +- thijs: how might hosts, users, workspaces and accounts relate? +- kiara: we will offer SSO across applications. +- thijs: what if people say use this from both professional as well as other roles? can they then have workspaces representing their accounts at different hosts? +- kiara: i envision the web client as agnostic to orchestration capabilities, so a client application logged in to accounts at different hosts thru e.g. workspaces could technically be possible, tho i would not see this as significantly affecting our design currently. +- thijs: how about a host admin panel to e.g. restrict offered applications? or for hosts' accountants? +- kiara: hosts consist of sysadmins, so a config file may currently suffice for them as a user interface. +- kevin: hosts also already have their own client-facing front-ends. +- thijs: cli for now, so for the design focus on the operator panel? ok. +- thijs: *asking about terminology* +- *kevin + kiara explain* +- thijs: do you want to offer a federated UX? +- kevin: the deployed applications federate already. +- thijs: applications tend to offer support buttons. who is in charge of offering this support, operators, hosts or you? +- kiara: the operator, afaik. +- kevin: we might direct users to the application manuals. +- thijs: will fedipanel come with a knowledge base aimed at the operators? +- kiara: we could link to a static one deployed from our end. +- kevin: probably better to include this in the panel deployment. +- thijs: sure, let me know. +- thijs: we can show what we had so far in design program figma. +- tiemon: you can navigate and interact with the designs, and they can generate html as well. +- thijs: we like to work with job stories, so not just user stories like 'as a ...' but also including 'so that ...'. +- kiara: great, so do we. +- thijs: we can show some UIs we like for reference. +- thijs: you won't offer file management from the panel, right? +- kevin: correct. +- kiara: fyi our deployment is somewhat big-bang still, rather than say configure mastodon -> deploy -> configure pixelfed -> deploy - we can not yet enqueue such syncs. +- thijs: where can we find your application? +- kevin: the code is at , but we also have a recent demo video. +- tiemon: we saw that one, yeah. +- thijs: here is a wireframe so we can align on the chrome (= UI parts that are always there). +- kiara: we do not yet have workspaces, but multiple deployments per user could become an option. +- thijs: how about an admin interface to manage users? +- kiara: we will have to go thru hosts' SSO because of billing. +- kevin: yes this will go thru LDAP. +- thijs: how about showing stats about e.g. numbers of mastodon users? +- kiara: applications should already handle stuff specific to them, so we don't plan to do this. +- thijs: how about application settings (generic vs application-specific)? +- kiara: generic ones will apply to say configure VM resources or sub-domains, tho otherwise most should be application-specific. +- thijs: no auto-scaling? +- kiara: not for now. +- thijs: how about a billing interface? +- kevin: hosts would use their existing ones. +- tiemon: how is pricing determined then? +- kiara: hosts may set this based on the usage info we will provide. +- thijs: + - font: manrope? + - kiara: looks pretty. + - icon sets, selected by open-source / pretty / ...: + - [iconoir](https://iconoir.com/)? + - [phosphor](https://phosphoricons.com/)? + - kevin+lois+kiara: this one looks prettier.