Clearer separation of front-end UI control needed between Instance-admin configurability and developer-only configurability.

[johannab33]

This is probably a "parent" issue and I will annotate further as I pick apart specific things.

At the moment, I'm working from the position of someone who might eventually want to self-host a fully independent FediProfile server, with control over per-instance choices, while leaving intact the source requirements like licensing, T&C for the product, back-links to the authoritative repository, tip jars, support and docs, etc.

Right now I'm examining and tinkering with the visuals and controls functions of profile.stone-soup.ca and trying things from both the /login/root access, and from the "new user" view in a private browser window. The following is a quick-list of where I'm finding confusion:

• Landing page components are sometimes configurable by the instance /root login and still sometimes not
• The "Login with ..." options for Github and LinkedIn don't work except on the development instance
• The independent instance still shares a DB file space with the development instance, which is fine in the current circumstances but don't implement too many more if you don't trust every admin not to mess with someone else's DB (not sure you should trust me, either. I'm not malicious but I'm sometimes accident-prone)
• Can instance admins have configurability applied to default profile constructs and default themes? For example, select a sub-set of available themes, add their own, edit links in the default themes or links that are common to all themes.
• Can users have more control on their own parts of the themes, such as the order of sections, tabs, and whether or not they appear?
• • Many themes display sections and links out of order from what they appear to be in the profile (top-to-bottom setup appears right-to-left in view, this is backwards from what is expected in most cases (our language-based reading directions inform how the eye views "right way 'round" vs. "backwards".
• Can the brand assets (logos) for connected profile accounts and services be set up with a local store and under the control of the instance admin? I can see a use case for an individual instance wanting to offer flair other than "Mastodon" for activity-pub based servers, like CoSocial.ca or custom forks.
• Can the "Not on the Fediverse?" link be customizable rather than locked to joinmastodon.org? We now have an open Wiki project jointheFediverse.net which is platform-agnostic. Some FediProfile admins might want to aim at a certain individual service for joining, some might want to point at a regional or curated page of preferred instances, such as the FediPact subset, or the SocialWeb Canada subset.
• Can the fediProfile instance itself be limited/invite only? Even though it requires an existing login to authenticate (keep it that way, certainly!) it might still be desirable to only host profiles from a subset of the roving millions of Fediverse users. The use case I'm considering is the aforementioned regionalization - if we had a "Canadian" FediProfile affiliate, or an organization wanted to host profiles only for their members -how would that be limited?

[johannab33]

Adding a further note as to how I'm looking at this. I'll try to work from the above brain-dump and refine my thinking on how, as an admin and user-support person, I would look at wanting to separate permission-based layers of configurability.

I am presuming an eventual goal here is to have FediProfile available as a distributed network, and unless you have full-time resources, you want to do as little support as possible - which is going to require really good tools and documentation. Levels of privilege seem to be:

0. Software owner/developer: licensing, terms of distribution, core documentation links, and a call-back to FediProfile-the-project all need to be baked in, cannot be altered unless by someone who forked the whole think and is coding on their own.

1. Instance Administrator:

   • Configure back-end on installation (I don't yet know all the possibilities)
   • User management: authentication control (local users only? is THIS fediprofile for a certain initiative/brand? Invites vs open? Does the Admin need their own API keys or authentication for particular connections?
   • Service/Maintenance on front end for users: Control of all markdown or CSS that controls UX, configuration of default profile cards, back-links, branding, regionalization.
   • Payments integration?
   • Add/store additional assets on their own, eg., branding, imagery, banners
   • Exploring and Troubleshooting documentation (you have SQL queries and some exposure to an underlying DB. Depending on the Admin, might need to consider how to allow them to do their jobs but keep out of trouble.
   • can an Admin notify accounts using their instance of maintenance or news?

2. Profile Administrator (User, possibly tech support)

   • Banner/avatar: Assets are pulled from user's primary account, the one they used to authenticate (is this always true? can they update?)
   • Users configure via selectors/fill-in fields mostly. Access to common assets of this instance (e.g., icons to mark different services)
   • Are there ways users can configure the look/arrangement of their own theme? ("no" is fine as long as the Admin can address reports/complaints)
   • Can users report a problem to an admin?