Plural accessibility in voice and text

(#947) Feature Under consideration accessibility profiles

Thread

Comment by @Enovale
RexSystem 1 vote originally by @Enovale on GitHub 1 reply
I discussed a feature like this many months ago with Hampus, and a few days ago as a checkup, he believes is very much feasible in the current implementation of V2. I was writing up a github discussion of my own before I found this one. Y'all have already come up with most of the same ideas as my solution, but for conciseness let me send my proposal comment here:

Problem

Users across all messaging apps, very prominently Discord, would like to be perceived and referred to by a different identity, avatar, pronouns, among other identifiers in certain contexts, without resorting to elaborate solutions like alt accounts. Users may want to do this for many reasons, but just to name a few:
  • Plural systems and/or people with DID wanting to associate a certain alter with sent messages
  • Users who want to be seen a specific way among certain people, such as close friends, professional colleagues, or family
  • Users role-playing as characters, for example in Tabletop Game communities
Platforms like Discord, Matrix, and Signal provide no native solution to this problem. However Discord users have come up with an interim solution, via bots utilizing Discord's webhook infrastructure. Typically users type in phrases that tell the bot to replace their next message with a webhook message styled after their chosen name and avatar, containing the original message content. I will refer to bot-produced messages pretending to be a user's given identity as "webhook messages" for simplicity, though note that Matrix bridge bots implement this behaviour with real accounts, though most of the same restrictions apply. I would like to address some problems with this solution:
  • Webhook messages cannot contain any extra profile info past their name and avatar. This allows very limited customization.
  • These messages also do not link back to the user account that sent the message, or even the bot that initiated the webhook. This means users reading the message cannot find the user's account to friend them, privately message them, or even know what bot is allowing the users to send the webhook messages.
    • You cannot meaningfully ping the characters identified by these webhook messages, you must ping the user that sent them, which can be confusing when reading message history.
    • You cannot block the users sending these messages, which is awful for user safety.
  • On Discord, webhook messages also have been bugged for years, not allowing user flyouts to function properly, regardless of if webhooks could contain more rich account data. They typically show the wrong avatar or wrong name.
  • These webhook messages are indistinguishable from any other webhook message, such as RSS feeds or github logs
    • This means that all messages are tagged with a "BOT" or "Webhook" tag, which is confusing to users and also incorrect in a manner of speaking.
    • Additionally, most moderation bots that aim to log message deletions or edits see this "replacement" as a deletion, and a new message and cannot trace back the original cause. Many current Discord moderation bots have to ping PluralKit's API to check if a webhook message is a PluralKit message and omit it from logs, which is fragile and prone to abuse.
  • Most implementations are cumbersome to add new characters to, due to the nature of bots. Some may use web control panels which helps, but it's a third party website one must visit to change their look within a chat app, which isn't ideal.

Proposal

I propose a feature I will refer to as Personas (though this is not meant to limit what it may be eventually labeled as in the Fluxer platform). This concept is malleable so consider the design I'm about to lay out a draft: Users are able to go into their profile customization settings, and using a similar system as is already implemented for Community Profiles, users can add a (hypothetically) arbitrary amount of Personas. These Personas inherit the global profile's details by default, like the Community Profiles do, and allow overriding all the profile data that you can customize in the global profile. The difference between Personas and Community Profiles is that Personas can be selected to be used for any given message at any time, and ideally can also be used during calls, streams, the current Persona is shown in the member list, etc. Perhaps a dropdown menu is available in the bottom left next to the rest of the user popout options like status and account switching. Just like Community Profiles, the original global account these Personas link should be obvious and easily retrievable by observing users. Perhaps in the member list there is a small cutout of the global user's avatar if it differs from the Persona. There is a button in the 3-dot menu of a Persona's popout to see the Global Profile, etc. But whenever possible, the Persona's information is the first and most prominent information the user sees. Certain exceptions may of course be made, audit logs should not be confusing when Personas are involved in actions, if Personas are visible in the member list perhaps they continue to be sorted by their global profile name, otherwise a user could cause rapid shifting in the member list. But these should be done only when necessary. The goal especially is for Plural Users or Users who want to only express themselves a certain way in certain communities to feel truly expressed in every aspect Fluxer can reasonably aim to provide (Not to sound too grandiose!). Back before Fluxer blew up, I chatted with Hampus about this feature, to discuss possible avenues for implementation, though this was before V2. Additionally, Hampus suggested all device's selected personas be pooled into an array of IDs in the presence object that could be used to show multiple personas as Online, if such a feature were to be implemented.

Notes

I made it clear that an intended use case would be people using specific personas with specific people, which, if taken to it's logical extreme, could include vulnerable people using Personas that could make them unsafe if seen by the wrong people. Should Personas be publicly viewable/indexable? If not, how would we even prevent it? Ideally I want this system to be usable by bots as well. If the community around Fluxer decides the current system is inadequate, at least ports of PluralKit's idea could use the Personas system to get around many, but not all of the aforementioned limitations. Would blocking individual personas be a desirable feature? ----- I'd also like to note for the purposes of this discussion, I am not a system, I don't even do tabletop roleplay often, I just look at the system such users are stuck with on Discord and get sad.
Comment by @bunnikyuube
RexSystem 1 vote originally by @bunnikyuube on GitHub
Interesting to see there's some level of approval that the idea is feasible, from Hampus himself. Just needs to be someone to develop the feature. I really like the inclusion of the idea of different Personas appearing in the member list- that's a thought i hadn't even considered coming from the angle of caring mostly about messages being sent. As a system it's a thought i appreciate a lot, as it functionally means a native "Currently fronting" list or indicator, which is already an incredibly desired tool for a lot of systems to the extent of entire other platforms existing for it, like SimplyPlural, Octocon or Pluralspace. That said, my main concern is how fitting this in would affect the user general user experience of the app. The way i see it is, the simplest way to include the feature would be in place of the Profile pull-up menu, because it should be no more than one click away from the main screen. But then that pushes those other features around. In addition, the idea of multiple "online" Personas adds a layer of complexity, as you need to integrate a separate workflow for messaging, for selecting which Persona is sending a message out of the various "online" ones. However, that isn't to suggest the idea of multiple "Online" Personas should be abandoned for simplicity's sake- i think for one it'd actually add a lot of value to the feature outside of just the plural community. The Roleplaying front especially would benefit from the indicated presence of varying personas for character presence. Bringing up the idea of multiple online personas cements it as a definite need in my mind, but it does add some workflow complexity. My proposal for the workflow is this;
  • The "Personas" dropdown appears at the top of the member list, separated by a visible seam, and displaying, in order of priority; First activated Persona of all listed, Default Server Profile Avatar/Name, Global profile Avatar/Name.
  • The Personas are treated as Tickboxes, enabling and disabling them in that menu will display them in the Members list as online publicly. (Maybe worth adding Online, Idle, DND, Ignore states too?)
  • The Message box displays the current persona in the left side of it in Avatar/Name form (optionally either or both), defaulting to the first activated persona or the default profile.
  • Additionally (when they're implemented) discord-style parametric slash commands could be used for sending messages instantaneously as a specific persona. Ie;
  • /p:PersonaName/ID [Message]
Done this way, it... would also be theoretically possible to block Personas individually. Which would be nice for quality of life and general usability, though i think there's also an agreement that it's pretty rare to have an excuse to block one Persona/alter and not others. That said, why not do it anyway? Unfortunately, i have very little technical insight to give on the matter, but the UX is incredibly important to Fluxer's popularity and my opinion and i'd love to contribute to a discussion in making a feature like this as smooth as it can be. Concept is definitely a switch-up from the one i sent in the comments a few months ago, but i think the multiple Online personas concept is far more important than sending one message under multiple. Under that context i think this workflow concept works fine, and Slash commands would be more than effective enough for sending one persona's messages at a time. It would be a major muscle memory issue for some (not having the traditional Pluralkit-style proxies), but that can be solved through community bots regardless.