Plural accessibility in voice and text

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. I don't see a reason that it wouldn't be merged, assuming your implementation was functional and human-friendly. It's an accessibility feature at heart, and your implementation takes a majority of the actual issues into account- as such i think it would be pretty dogwater to not merge it. I'd be willing to provide additional UX feedback, if you do end up working on this, for whatever that's worth.

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.

Hello @haileyscommit @chiaracoetzee, I was wondering if either of you had started on making your own implementations intended for a PR or even just for your own client? I have also been considering the possibility of attempting to implement the persona's idea as well.

Hello @haileyscommit @chiaracoetzee, I was wondering if either of you had started on making your own implementations intended for a PR or even just for your own client? I have also been considering the possibility of attempting to implement the persona's idea as well.

I've been basically waiting for Hampus's okay on it. Also PRs are locked now so I wouldn't be able to contribute it anyway. edited to clarify: I haven't personally, directly asked Hampus because they've said they don't want unsolicited DMs

I've been basically waiting for Hampus's okay on it. Also PRs are locked now so I wouldn't be able to contribute it anyway. edited to clarify: I haven't personally, directly asked Hampus because they've said they don't want unsolicited DMs

I see, assuming I'm not misunderstanding you and by 'waiting' you meant you havent done much on it, would you be open to collaborating on this? I've mainly been waiting for the new refactor since poor hampus has enough on his hands right now, but I was going to begin studying the repo soon.

@AspectBox As of today I have a rough prototype of @haileyscommit's design above which I've published in a fork feature branch here: https://github.com/chiaracoetzee/fluxer-subprofiles/tree/features/subprofiles Only did web/desktop clients so far, not mobile. I've spent maybe 1 day on it so far but it seems to work well for our purposes on our home server. It supports both a pop-up subprofile selector and also PluralKit-style text prefixes for power users, as well as an importer that can import profiles from a PluralKit json export dump. Supports name, avatar, prefix, color. Supports three autoproxy modes, off, Manual (you select which subprofile is autoproxied), and Last Used (like PluralKit latched, autoproxy sticks to last used subprofile). Here are some screenshots. Tested reactions, replies, editing messages to change prefix, among other edge cases. Tested it with a large imported system with 60+ members. Let me know if any questions. Right now if you click on a subprofile avatar you just get the profile card for the owner account but I'll fix that up later. I deliberately organized my changes to make it easy to take rebases from upstream since I wasn't necessarily expecting to merge a PR back to fluxer any time soon. Should hopefully make it a bit less messy to construct a PR as well. image image image image

Hey @chiaracoetzee, this is awesome! Do you mind if I add you on Fluxer or Discord to collaborate a bit closer on this (in other words, can I send you git-bundles and ask stupid questions)? FWIW, I got this running in a local dev-container, and I might tackle a few of the missing and broken(-ish) things I've noticed, if that's okay with you.

@haileyscommit Please feel free! I invited you as collaborator so you can push directly to same repo. Feel free also to add me on Discord at username chiarastellata (I'm not fully set up to use Fluxer routinely yet). I'll check in after work. Thank you for your help. :)

This so cool!! I would also love to help test and hopefully make some contributions as well if you are open to it @chiaracoetzee?

I put up a Development post for my implementation at https://github.com/orgs/fluxerapp/discussions/2635 and we can have further discussion on this feature there. @AspectBox I added you as a collaborator on my repo, and please feel free to also jump in the dev/test server at https://chat-dev.hypersystem.xyz/ to try it out there and talk to other collaborators!