Plural accessibility in voice and text

I believe there are some people already interested on porting PluralKit (infact its lirtterally the first thing i saw about bots being discussed lol) but native support could work better since it doesnt rely on community owners manually adding the bot and also more proper vc support (didnt think vc statuses on discord had actual uses like that! seemed like a pointless feature in my eyes)

Oh, my community uses voice statuses all the time for exactly this reason.

As a system, we personally think a feature like this would come with too many issues if implemented natively, but I think voice statuses would be great to have. Here's hoping we can get a pluralkit equivalent on the platform soon.

Yes I saw this discussed yesterday on Fluxer and one of the main things they wanted to address was fixing some of the core issues that Pluralkit has on discord (namely how PK entirely breaks blocking on discord which for me has been a key reason why I don't use it on personal discord servers because I see breaking a core feature like that as a hard blocker) Still, people are clearly looking into it and hopefully it will be able to avoid the pitfalls of PK on discord and being implemented at a lower level but this would require further discussion in how it would be implemented (in particular I want to see discussion about how blocking would be handled because core safety features have to remain functional with this kind of thing)

The idea I've landed on while thinking about how to build this in to the platform is to expand on the per-server profiles to have them be dynamically swapped between. My thoughts on what requirements to consider and plan out for implementation so far are

• UI for swapping profiles
• a server setting to enable/disable it
• some sort of tag beside a profile name to make it clear what account is communicating. Possibly toggleable client side
• consideration for some sort of Plutonium limitation
• how best to include a profile selection in a message.

I'm sure I'll remember more later. I figure we can get a design doc sketched out, then once the refactor is public, and things have calmed down a little, we can pitch the idea to Hampus, and if he says yes to any of it, then start working on actually building it

i would prefer not to have to pay for an accessibility feature

If fully integrated, it wouldn't solely be an accessibility feature. My thinking is for the bare minimum implementation it'd be just name, pronouns, and profile picture. basically what the per-community one is now with profile picture added, and a limited number of global profiles. Enough that anyone who needs it for accessibility would manage fine, but anyone using it for something more complicated, like a TTRPG campaign or something, would be somewhat limited. another option would be to limit the file size of secondary profile pictures for the free implementation. Mostly I want to limit the amount of stuff a free user can upload, and the amount of storage bloat that'll be added

some people have like 40 headmates, the limits would have to be pretty generous

some people have like 40 headmates, the limits would have to be pretty generous

I got ~70, so... I'm fine with some rather than none? But at that point I'd be waiting for a pluralkit equivalent instead.

From what I'm aware of, biggest pain point for PluralKit is that blocking people doesn't really work. So either a system for establishing "this bot message was caused by this used" could be helpful, or integrated multi-profile stuff. Ideally any implementation should provide privacy control, as to not announce to the whole world that someone is plural, unless they use the feature in a given community. As well as allowing to limit which community can see which profile, which would help a lot for queer people in general, and others. Though something to keep in mind is abuse potential, so making sure blocking and moderation tools are natively integrated is a good thing to do.

What would moderation look like on this? Because the accessibility is great don't get me wrong - but it can rapidly become a moderation nightmare if not taken into account to, especially letting it be a basically open feature to make multiple profiles.

They could be called "subprofiles" even. And apart from accessibility it could also double as a QOL feature for roleplaying.

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.

Plural myself and a ton of my friends are, and we all used Pluralkit before, but frankly, I've grown to really dislike how Pluralkit works for many of the reasons described in this thread. On top of those, it looks like garbage to have a text chat shunting itself up and down as PK deletes and re-posts messages. And it breaks replying, as well! If whatever ends up being done has these same issues as Pluralkit does, I won't be adding it to my communities, that's for sure.

I'd actually like to refer to a Discussion under Stoat's git for a few reasons: https://github.com/orgs/stoatchat/discussions/76 One, on the topic of use for plural communities, i actually think the option to basically include multiple Profiles as senders of the same message is a critical quality of life feature. It's incredibly common for systems using Pluralkit, Tupperbox, etc. to have proxies dedicated to sending a message when they're kind of unsure of the active fronter, or when multiple members are active in a discussion and have the same thing to contribute collectively. I'd also like to point to this discussion because of the ways it specifically targets transparency of the host account the messages are being sent through. It's a major concern that people have when it comes to moderation, after all. Additionally, i think an implementation not unlike this, where the original account is inextricably linked with the sent message, also likely solves the issue of being unable to block users. As a result of this design, it'd be sensible that blocking the host account would block all messages from it. I don't think this is an accessibility issue, i think it stands to reason most users would not have a reason to block specific system members/profiles whilst not blocking the host account, and this sentiment has largely been echoed by others i've been around.

Sounds like you want to be able to create multiple display profiles which can be switched between easily. Not impossible to add I think but then you come down to people who would use smth like that to try to make it more difficult for mods to moderate. Discord has a per server profile system for nitro users so I'm imagining similar system being done but instead of per server it would be switching between a chosen displayed profile.

Just noting for the record (and agreeing with monty58), I think that this kind of functionality really doesn't only benefit plural accessibility. As detailed in the respective Matrix MSC for this backend functionality, this can be super useful for bridging and as a much less clunky alternative to using Webhooks in bots.

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.

Just my two cents but I feel like this would be duplicating guild profiles as it doesn't take long to edit the name profile picture. Also as long as the guild allows it you can rename yourself for free which I think addresses this as it gives you an unpaid solution to distingiush between alters so work on a specific feature would just be duplicating existing work that would likely be more used to bypass plutonium limits than the perceived accessibility improvements it would bring. If a user wants more customization for their alter profile they can do it like they would with plutonium through guild profiles in addition to renaming themselves but functionally for accessibility I don't think there's anything lacking with renaming as it gives a clear distinctor.

For people who need a solution that's backwards compatible with existing servers and clients, a pure client-side solution could be implemented where the client is forked, multiple accounts log into the same client (one for each system member), and the client fast-switches between them inside the client using normal PluralKit prefixes and autoproxy. Upon joining a server rather than having all system members join at once (which could trigger abuse filters) they could join on-demand as they get used for the first time. The server would work as usual and singlet observers could use any client. While this is technically feasible it would probably run up against issues with abuse. It wouldn't be possible to block all members of a system at once, it wouldn't be possible to identify that two accounts belong to the same system except through profile descriptions, and if a server has any steps to complete when new members join a server, they'd have to do that for each member which would be painful. Plus member lists in channels would end up sprawling and unorganized for big systems. So I don't think this is necessarily the right long-term approach. But I did want to at least raise it as part of the discussion.

On top of my previous feedback I believe there is another aspec to consider. There's a reason other than the technical one which is that as per psychiatry, for this source I use the Adult Treatment Guidlines from the ISSTD, I recommend to the lead behind Fluxer to read the "Treatment goals and Outcome" chapter but I will provide an excerpt below.

Integrated Functioning as the Goal of Treatment

Although the DID patient has the subjective experience of having separate

identities, it is important for clinicians to keep in mind that the patient is not a collection of separate people sharing the same body. The DID patient should be seen as a whole adult person, with the identities sharing respon- sibility for daily life. Clinicians working with DID patients generally must hold the whole person (i.e., system of alternate identities) responsible for the behavior of any or all of the constituent identities, even in the presence of amnesia or the sense of lack of control or agency over behavior (see Radden, 1996).

Treatment should move the patient toward better integrated functioning

whenever possible. In the service of gradual integration, the therapist may, at times, acknowledge that the patient experiences the alternate identities as if they were separate. Nevertheless, a fundamental tenet of the psychotherapy of patients with DID is to bring about an increased degree of communication and coordination among the identities. I think this is important because Fluxer should not be encouraging behavior that worsens disorders and mental health issues if it can avoid it. Given that this point was brought up in regards to accessibility for DID/Pluralism I hope that the acknowledged clinical literature can be used to seen the issues with this claim in reality. To summarize it, implementing a feature that promotes the separate identities of alters for the presented reason being accessibility is going against acknowledged psychiatric documentation on treatment of Diassociative Disorders where the treatment goal is integrated functioning. A feature like the one discussed goes against the recommended treatment and worsens the condition of patients. That is something I feel Fluxer should refrain from doing if it can avoid it. The above can be fact checked by any licensed psychiatrist. As well to follow up to the technical points mentioned against my last post, this raises a case against the arguments raised against my point in regards to there being an existing feature that effectively allows the same thing (though not by design) called Community Profiles. There is also the aforementioned UX complications etc. to consider

The Sable Nightly 1.20.1 build features potentially very useful reference implementation of this sort of functionality for anyone interested in how this would look in practice. pmp1 pmp2 pmp3 pmp4 pmp5

As a possible workaround until a more permanent solution is implemented, could message embeds be used for this if that functionality was exposed in the client? Example: image

Per my comment above I have a prototype of this feature up at https://github.com/chiaracoetzee/fluxer-subprofiles/tree/features/subprofiles based on @haileyscommit's design and it's working well on our home server. It's web/desktop client only not mobile right now. Would need a lot more prep before submitting a proper PR. Supports both GUI subprofile selection and PluralKit-style prefixes, and can import a system from a PluralKit JSON export dump. Tested with a large imported system with 60+ members. Some screenshots below for reference. image image image

Hi! Plural system of 2 here, with some experience in moderation and using both of Discord's main proxy bots (PluralKit and Tupperbox). Just wanted to give our thoughts about a feature like this - putting it all in one comment to hopefully not drown out conversation. Feel free to ask us any follow-up questions and we'll gladly reply. First, we'd like to point out that accessibility benefits everyone, not just the target audience. As said before by others, a feature like this would be great for roleplaying, for expanding server-specific profiles, or even as a replacement for webhooks for certain bots. It's the same way that having a door open automatically makes it easier for handicapped people to go through it, but also means able-bodied people don't have to open it either. So even from a non-plural standpoint, we're in support of it. Plurals come in all shapes and sizes, including some with over 100 members. Many can have multiple members co-conscious and/or in "front" (interacting with the outside world). Sometimes front can be blurry, and it's not clear who's around. Switches in or out of front can at times be rapid or chaotic. So, trying to meet these needs one by one, using this new Personas feature: A Persona should represent one member, character, or identity.

• It has an avatar and display name distinct from the main/root profile.
• It can be toggled/switched to manually, or through trigger arguments such as prefixes and/or suffixes sent along with the message (such as f:<message> or {<message>}). Support for multiple distinct triggers would also be appreciated
• The active Persona should be able to remain active for subsequent messages, the behavior of which is set by the user. Using a trigger argument could temporarily (or not) switch Personas, such as for one message or from then on.
• Multiple Personas should be able to used simultaneously, to show multiple people in front, co-conscious, or blurring; or, multiple characters speaking at once.

Personas should be easy to organize.

• The limit of Personas one account can have should be generous. Some systems are huge, some people have a lot of characters, and some people have multiple uses for the Personas feature.
• They should support folders/groups, and folders/groups within those. A simple list would get cluttered quickly with several Personas.
• They should be searchable by name and by group. For example, if I wanted to find all our characters for a particular campaign.
• Importing from plural/proxying bots can be done with a simple "Import..." button. Many if not all of the proxying bots use a common JSON format, so compatibility should be trivial without having to make it plural-specific.

Personas should be easy to moderate. - Moderation actions (kick, mute, ban, etc.) apply to the user, not the Persona. Many plural spaces already follow this rule ("be responsible for you and your system"). - Personas should show the user behind them in sent messages, in member lists, and in voice channels. It should be abundantly clear when someone is using the feature to impersonate another user, or one of their Personas. - If a particular Persona is bothersome, they should be able to be blocked without blocking the user, and without obstructing normal blocking usage. Ideally, you could additionally block all of their Personas at once, showing their original unmodified messages and appearance. We're not as well-versed in the technical side of things, so hopefully this works as a design doc or something. If you'd like to learn more about plural systems and how to best accommodate us, https://morethanone.info/ is a good starting point.

A new discussion post has been made for the current implementation of the Persona system at https:/github.com/orgs/fluxerapp/discussions/2635

My WIP Personas implementation, which is aiming for a PR, now has a test server up, huge thanks to @chiaracoetzee: https://fluxer-personas.system32labs.com/ (source: https://github.com/haileyscommit/fluxer-contributions/tree/feat/personas) I am hoping to get a draft PR up soon to start getting maintainer feedback while I finish everything up. I just need to figure out how to get their attention to approve me for it.