Plural accessibility in voice and text

(#947) Feature Under consideration accessibility profiles

Thread

Comment by @chiaracoetzee
RexSystem 1 vote originally by @chiaracoetzee on GitHub
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.