kiara/meta
1
0
Fork 0
forked from fediversity/meta
Code Pull requests Activity

add minutes from design meeting

Browse source
This commit is contained in:
Kiara Grouwstra 2025-03-12 13:28:11 +01:00
parent 029c55e743
commit 9f25fd986d
No known key found for this signature in database
1 changed files with 76 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

76
architecture-docs/2025-03-05 design meeting.md Normal file
View file

@ -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 <https://git.fediversity.eu>, 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.