Plural accessibility in voice and text

(#947) Feature Under consideration accessibility profiles

Thread

Comment by @haileyscommit
RexSystem 1 vote originally by @haileyscommit on GitHub 1 reply
My vision for this was that it would do two things to help with abuse:
  • Show a subprofiles icon and the main profile picture on the message byline somewhere (in Compact mode, probably just the icon before the profile picture or name, similar to the bot tag).
  • Show the main profile when you expand a subprofile in the chat, de-emphasized. That way the main profile can be identified when necessary.
Additionally, subprofiles are only cosmetic and wouldn't affect permissions or blocks (you will stay blocked if you use a subprofile). Behind the scenes it would be "just" additional metadata, so the original message author is always there as well (and would still be used for other things like mentions, replies, blocks, and slowmode). I considered having subprofile use behind a permission, but I think that would end up in communities gatekeeping the feature. So it's better to double up on other abuse prevention methods. I am also considering taking this on myself... I'm just not confident that the effort would be worth it, if it isn't merged. An initial implementation would be for text, and it would really just cosmetically replace the profile picture and name of the sender with the subprofile's details [name color kept], and show the subprofile's details in the profile card, hinting at the main (system) profile somewhere on it. Future iterations could include VC support (depends on what I can do with VCs), cosmetic roles, or user-set custom name colors (which would be a part of regular profiles as well). edit: also I thought I'd call it Personas. Subprofiles might be better but it could be confused with server profiles. Not really sure on the name.
Comment by @haileyscommit
RexSystem 1 vote originally by @haileyscommit on GitHub
As far as the message metadata for it goes, I think I'd store an ID (referencing the subprofile) and the "short name" of the persona/subprofile along with the message [I do have to look into how webhooks and existing messages handle authorship metadata and reflect that behavior], and use the short name for a fallback message signature for clients that don't support the feature (i.e. older clients). In light of the "multiple contributors" suggestion, the shortname used for a message would account for the "other contributors". Plus, the shortname thing means that even if the subprofile/persona is deleted, the name, at least, can remain. I'll add the profile picture link to the message metadata too if webhooks do it (possibly reuse the field it uses?). It's something to look into when I can actually start working on it (once the codebase stabilizes and PRs are opened; or if hampus greenlights me sooner somehow). The rest of the profile metadata will be offloaded and only requested when the profile itself is looked up (i.e. clicking the profile picture). edit: something I've also considered for the feature is allowing bots to set an endpoint clients can call to get subprofile information. In particular, this could be helpful to support bridges, so that full profile information can be lazy-loaded, and that it won't have to pretend that every user using the bridge is a bot. Bots could therefore have unlimited subprofiles, even on the main instance, because the main instance isn't hosting them. (Otherwise, bots can't have subprofiles at all; yes this is related to limits.) I do want to have a way for users to be able to bypass the limit by using a bot but I haven't figured out how that would work yet.