Fluxer
Plural accessibility in voice and text #339
Replies: 22 comments 32 replies
|
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
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 |
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. |
|
doing it exactly as pluralkit does is a bit of a naive approach, for a few reasons:
|
|
Considering the lack of subtlety with the current solutions, I don't think obfuscating the root user is a super high priority. We'd probably be better off making the feature useful and intuitive enough that that it's used for more use cases, preventing one from being the default go to assumption. I could see it being useful for large community server staff using it to switch between chatting as a user and chatting as a staff member for example. |
|
As for visibility, presumably the root profile that's displayed would be the per-server profile, with the proxy profiles linking back to that and not being retrievable aside from when used in a chat. If each proxy has a randomized UUID that you have to know to request them, then anyone trying to request the details would have to already know it, and if someone's following you around trying to expose that, it would fall under the rules umbrella of someone following you around and harrasing you, which already have it's own solutions |
|
Oh I meant restricting access to proxies, not the root account. That should be overall always visible. It's the existing of any proxies at all, and access to the list of them, that should have privacy controls |
|
Yeah, like I said, make it common enough to not be weird to see, and make them not provided my the server unless you request a specific UUID for the proxy. Sure theoretically someone could brute force find it to pull it, or share the ID around for other people to pull it, but someone putting the resources in to do that is already harrassment, and this is not a high damage thing for them to be doing. |
|
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. |
|
its not hard to make it so opening the user's profile shows the root account no? |
|
check the notes section for a starting point |
|
It's mostly a moderation nightmare in its implementation with most bots regarding webhooks. Having the message author remain the same, but having additional metadata for the sub-profile would mean blocks would work as is, and there wouldn't be any messing with things like User searching, Mass message deletion on bans, and other things like that. Functionally more than anything it'd just behave like a set of Per-server Profiles that just replace the display metadata on the fly. Per-server profiles aren't an issue, so i don't see why this would be. |
|
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:
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. |
|
This is roughly the implementation i think works best. Pretty much echoed completely by my own response, save for my inclusion of being able to send one message under multiple Personas. |
|
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. |
|
I think this is the most reasonable short-term way to implement this and it's not a ton of work. It would essentially make personas/subprofiles purely visual/decorative, only affecting how messages are displayed but not really affecting anything else. Main downside is it'd require both server-side and client-side changes. But for people who have home servers that are only accessed from the web, they could patch in the feature pretty easily even if the mainline repo doesn't take the merge (without requiring users to install any special software). Because my own homeserver has urgent need of this feature I'm likely to go ahead and implement it in a fork (architected to facilitate easy rebasing). I'll post here when I have it running and maybe then it can be used as a starting point for iterating on an official feature. As noted in other discussions below the block feature might need extensions to allow particular personas/subprofiles to be blocked without blocking the entire system. Edit: Another thing I think is important for this design is to have two separate fields for the message, the existing message field for clients that don't support the feature and a new one for clients that do support the feature. This would allow the server to embed system member tags for non-supporting clients directly in the message, so that old clients can tell what's going on, without cluttering up messages in the new client. |
|
You should definitely consider at least PRing this if you implement it for your own server+client. |
|
@Hate9 I definitely will, although preparing for PR submission and responding to PR comments may take some extra time. |
|
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 don't see any reason to believe a native implementation would have the same issue. I think the prevailing opinion seems to be that the message author remains the same and the changed profile is functionally just additional metadata. As a result it'd be sending under one account, which means none of the fuckery involving Webhooks replacing the original message. Additionally, it'd mean blocks and whatnot remain functional. |
|
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. |
|
The only thing is that multiple personas used at once comes with a bit of UX baggage, ie: what persona is prioritized for display name & avatar, what methods of displaying all senders is available, and the like. Thinking maybe clicking/tapping the PFP opens a pull-up menu with the senders of the message, as well as the author account at the top. Display priority is given to the first persona enabled, with a +1/2/3, whatever number appended, etc etc. It's a bit of a niche case, but i think if we're going to be considering native implementation for the sake of accessibility, as one of the first platforms doing it, it's the kind of thing that i think should be considered |
|
I'm thinking about having a different metadata field for the "other" contributing personas/subprofiles, so that the first one can be looked up and used for the nickname/avatar, with an indicator that there are more somewhere (and if there are two, perhaps both names will be shown, if possible; this gets weird at 3 or more). This would be a later extension of the feature, though, so that the feature can exist first. |
|
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. |
|
Fluxer also has that feature, so it's pretty easy to build something similar for this |
|
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: ProblemUsers 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:
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:
ProposalI 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. NotesI 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. |
|
I considered a Dropdown on the user's own card, but unfortunately, the user's own profile isn't always visible in the list at all times. That's why i think it needs a separated list/drop down of its own. |
|
It might also be good to be able to unblock a persona when you have the root account blocked. I could see this for an official sever where you have a staff member blocked but want to see what they post as a tagged staff memeber. |
|
For banning all users connected to a/the plural system, perhaps there could be a group all button to remove all plurals associated with each other/ban all type button in the open in mod view screen? That would certainly make it easier for moderators. |
|
Just to clarify I mean for per one we/us (not to just outright ban anyone that identifies as a plural system.) |
|
@coldreindeer It looks like, based on the implementation described here, the default would be to ban the whole user account, and then there might also be the option to ban specific personas rather than the whole account. That also definitely seems like the best option to me. |
|
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. |
|
Unfortunately, it's slower, and cumbersome, and usually an extra click or two from the main display as suggested by some of the proposals here. |
|
Server profiles as-is don't work for multiple reasons: 1. too many clicks to switch, some systems switch multiple times per minute. 2. when a server profile is changed it affects not only new messages but also how all historical messages from the same account are displayed. For plural systems they need historical messages to be displayed with the name of the member that originally said them even after switching later on. |
|
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.
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 |
|
keep your comments helpful or keep them to yourself. not every plural person is disordered, and "becoming normal" is not the "solution" you think it is for everyone. |
|
If you want to have a medicalized aspect to this (to be clear, not all plurality is plural for medicalized reasons. Some are just plural), why are you referencing an outdated resource? The ISSTD guidelines you mention, from what I can find, are from 2011. The DSM-V-TR (released 2022) mentions nothing about integration being a goal. The ICD-11 (released in Feburary of this year, 2026) mentions nothing about integration at all on their page about DID, and it goes out of its way to mention that having multiple personality states is not always indicative of a disorder of any kind. That as a bare minimum indicates that even from a medical perspective, plurality can be a normal (and for many people, while still a minority of the population, it is a normal). For some plural people, integration can be a solution or goal to their stresses in life, but there are many for which it is a stressor and would create even more problems. |
|
Hey, i understand your concerns probably come from a good place, and i respect that. As it stands, it's a grossly understudied and underrepresented set of conditions and experiences, and that's likely WHY you've been exposed to outdated information that has a view on the experience that doesn't align with many systems' goals and experiences. A lot of people who don't live the experience like to defer to people who study these phenomenons, however, those people in large capacity don't really exist, and even when people understand it on a certain level, it's very difficult for that information to become mainstream in any capacity. A lot of the people commenting on this, myself included, are systems, and they're the best people you can listen to on how this stuff should be included, why, and what the benefits of it are. However, i also don't think any sort of evaluation of psychiatric impact is relevant, as any social media have ethical concerns in that regard FAR before the question of whether plural folks are able to send messages as one of multiple users. Drawing the line there is kinda moot, in my opinion. Additionally, multiple people here HAVE tried to make a case for why this is beneficial to non-systems- like for roleplayers, or as an extension of server profiles for people who have a need for more granular control over expression around certain people or places,for use by Bridging bots or other things that utilize webhooks, and so on, so forth. It's a useful feature, for everyone, end of story. It's just that plural folks are largely the reason this discussion happens as they have the most direct experience interfacing with the current, inadequate systems of managing messages like this. Hundreds of thousands of messages, all sent manually and directly through webhooks or other means, all configuring their systems through the bots on their own- all opposed to bridge bots, where messages often arent sent through them knowingly or manually, and configuration is almost entirely on the server moderators, NOT each individual user. You begin to realise, working like that, how inadequate it is, VERY quickly. |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment has been hidden.
This comment has been hidden.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Problem
Hi! I'm a plural system, and my community is predominantly made up of plural systems. Basically, in this kind of identity, multiple people inhabit the same body.
Currently, my community uses a Discord bot called PluralKit to reflect which "alter" is currently speaking.
I'm interested in hosting a server for my community, but it'd be very difficult to convince them to switch to a new platform without accessibility functionality for them.
Proposed solution
Each account gets to send messages from one of multiple identities, complete with a different profile picture and name associated with the message.
An additional feature that would help is what other platforms call "voice statuses," basically an emoji (paired with a text string that appears on hover) to the right of your account name that shows up in a voice call you're in.
These features would allow for plural people to reflect their identities in casual conversation, making it easier to communicate between people with and without them.
Notes (optional)
If implemented improperly, this can be an easily abused feature. I think that the "voice status" feature is a model for how it can be implemented in a way that's transparent to users that may be scammed otherwise, as it allows users to see the account that is speaking at the same time as their identity.
I think this could be replicated in text, either by showing the account name on hover, or by showing the identity the message was posted from as a second icon near their account name. Ideally the account name is de-emphasized in favor of the current identity name, though.
Checks
All reactions