AllBugsFeaturesChangelogSearchNew post
Sign in with Fluxer
Features

Personas feature (to support plural systems and roleplay) (WIP)

(#3528) Feature Under consideration
by RexSystem originally by @chiaracoetzee on GitHub
Similar to PluralKit on Discord, the Personas feature allows a single account to use multiple names and avatars and switch quickly between them on-the-fly. First requested in the earlier thread Plural accessibility in voice and text #339. We have a prototype implementation published at chiaracoetzee/fluxer-subprofiles/tree/features/subprofiles and a demo server up at https://chat-dev.hypersystem.xyz/ (feel free to come visit and try it out). Unlike proxy bot solutions like PluralKit or fishingbucket this is intended to be a first-class native feature in the main Fluxer distribution with both server-side and client-side changes. Features supported so far:
  • Switch between personas using either PluralKit-style prefix/suffix tags or the persona selection panel, accessed via a small icon in the composer bar.
  • Active Persona Mode (similar to autoproxy mode in PluralKit) allows you to send all untagged messages from a selected active persona, or to automatically change active persona whenever a tag is used.
  • Imports personas from PluralKit json export dumps, including importing all avatars into the Fluxer server's media storage.
  • Click on a persona's avatar to see detailed info on that persona, and info on the root account that owns them. Click root account for detailed info on the root account.
  • To switch the persona on a message, either edit it and add the persona tag of the new persona, or click "..." to the right of a message then click "Change persona".
  • Things like replies, reactions, edits, etc. all work as expected.
Welcoming feedback from anyone. NOTE: This feature was developed with AI assistance. Due to Fluxer's policy of not accepting AI-assisted PRs I will not be submitting a PR to Fluxer with this feature. Instead I'll be maintaining a fork at chiaracoetzee/fluxer-subprofiles/tree/features/subprofiles and rebasing periodically. Others are free to review the feature's implementation if they want to rewrite a similar feature from scratch that can be submitted. TODOs: (full list at my issues board)
  • In the current implementation all persona data is stored in the synced preferences blob which has a 256KB limit which is less than ideal. Planning to migrate this to a real DB table with REST API.
  • Need to sort out how our equivalent of system tags will work. We're thinking of some combination of text and icon, both optional. There's also been discussions of a server option to force on showing the icon of the owner account, for security/safety reasons.
  • Will likely add an Export button and generalize the "Import from PluralKit" button to an "Import" button that recognizes both PluralKit json dumps and its own export format, as well as any other formats we want to support. These are important for data portability of persona collections. I'd ideally like the exported format to include a bundle of avatar images so that it's fully self-contained.
v2 stuff (for later):
  • Way of doing name color (in DMs or with opt-in from server)
  • Group/tag systems for organizing subsystems (sub-groups of personas)
  • Consider timeout for Active Persona Mode (e.g. switch to off after x minutes as with the mute channel feature)
{11A34748-FC50-4BD5-817C-D98EE5BCABD9} {56B0B07B-EF66-412B-A0CC-0F887FB0E653} {A7D65470-E917-444F-A1A1-0056C4093E8A} {08E057F6-B3EA-49D9-A9F6-21D275CDF68D} {401EEB90-1D9D-43AF-B46C-01DD0A92FAFA} {93AF528D-C475-4F96-A02C-A0E24E10DAC2}
  • 649022919-56cc10c4-2663-443f-9a68-e9e88a37f067.png

    649022919-56cc10c4-2663-443f-9a68-e9e88a37f067.png

    553×456 | 51 kB

  • 649023639-5d894fff-daea-4a1f-b370-a435a99d98de.png

    649023639-5d894fff-daea-4a1f-b370-a435a99d98de.png

    674×753 | 87 kB

  • 649023744-26b72a1d-05f8-45f8-b787-62f33ac1a0fa.png

    649023744-26b72a1d-05f8-45f8-b787-62f33ac1a0fa.png

    1911×1480 | 237 kB

  • 649024440-e5ef2c73-b596-45eb-9061-bbfe4fa1146f.png

    649024440-e5ef2c73-b596-45eb-9061-bbfe4fa1146f.png

    1058×972 | 77 kB

  • 649024589-16dc1908-9d27-424d-9659-6b0611d6475e.png

    649024589-16dc1908-9d27-424d-9659-6b0611d6475e.png

    554×670 | 46 kB

  • 649028818-2b5ead23-9115-4a47-94c8-9826cf551bcd.png

    649028818-2b5ead23-9115-4a47-94c8-9826cf551bcd.png

    685×702 | 101 kB

16 comments

Sign in with Fluxer to comment and vote.
Comment by @chiaracoetzee
RexSystem 2 votes originally by @chiaracoetzee on GitHub OP
fyi @haileyscommit is working on a clean-room AI-free re-implementation of this feature for the purpose of submitting a PR to Fluxer. This may take some time but they are doing great work.
Permalink
Comment by tempest:squll.fartcore.ai
tempest:squll.fartcore.ai 1 vote originally by @HellishBro on GitHub 2 replies
I'm gonna consolidate my feedback here:
  1. Remove the system tag feature as it is obsolete with the Main Profile icon
  2. Rename "Import from PluralKit" to just "Import" (also, why not Tupperbox?)
    • This could also turn into politics really fast (IMO) if we only limit this to PluralKit and Tupperbox. Why not Utter, FishingBucket, /plu/ral, or the countless other projects with non-negligible amount of users?
  3. Subprofiles should be as fully-fledged as a Profile
  4. Subprofiles should be IDed / Snowflaked; Subprofiled Messages should retroactively update with the most up-to-date Subprofile information
  5. Do we make this system powerful or do we keep it lightweight? Is the purpose of the Subprofile system essentially PluralKit natively in Fluxer or something lighter?
  6. How should relationships like friending and blocking work? Configurable Per-Subprofile / Per-Profile?
  7. API and OAuth2 scope (ties into point 10)
  8. How will the bot ecosystem / 3rd-party Fluxer ecosystem use or depend on the Subprofile system?
  9. How should Subprofile viewing permission work? How granular should the permissions be? How would the permission system play into the overall larger Fluxer user permission system?
Permalink
Comment by @VanguardSys
RexSystem 1 vote originally by @VanguardSys on GitHub
Regarding 5: We think it should be powerful, but limited in scope; we wouldn't need to track fronting/switching with the Persona system, for example. Having independent fully-fledged profiles is fantastic, however.
Permalink
Comment by @j0lol
RexSystem 1 vote originally by @j0lol on GitHub 6 replies
Hi, main dev for Sable's Per Message Profile implementation here. First off: this looks very similar, and that is good. I would emphasise that you should not name then Personas if possible. I'm currently trying to get this language changed in Sable to a more neutral "Profiles" because some view this language as disrepectful. (Subprofiles is a fine name, even.) The picker should also ideally be reactive to when the user inputs a proxy tag. (IE changing when a match is found.)
Permalink
Comment by @j0lol
RexSystem 1 vote originally by @j0lol on GitHub
I would also like to emphasise that subprofile data should be private if the user wishes, and a full subprofile list should not be accessible (through UI, API, or otherwise) if the user does not want it.
Permalink
Comment by tempest:squll.fartcore.ai
tempest:squll.fartcore.ai 1 vote originally by @HellishBro on GitHub
@j0lol This can be accomplished via OAuth2 scopes, part of my point number 7. I'm also suggesting that streamer mode could also aid in hiding subprofile information, though some users may want to keep some subprofiles public at all times. This is also part of what I'm worried about: the subprofile feature becoming too heavy.
Permalink
Comment by Hailey
Hailey 1 vote originally by @haileyscommit on GitHub
We've discussed the name quite a lot, and we chose not to call it "subprofiles" because it could be confused with community-specific profiles that way. Personas is kinda the next-best fit.
Permalink
Comment by @chiaracoetzee
RexSystem 1 vote originally by @chiaracoetzee on GitHub OP
Thank you for the input! Subprofiles was what I used initially and is still definitely my 2nd choice, I'm flexible on the naming, but it was causing confusion with server profiles and for a general audience was a little too technical and less clear. Can have a broader discussion about revisiting the naming later. Making the picker responsive as they type a proxy tag is a good idea (much like how emojis work currently) but it risks being annoying since unlike with emojis, there is no single trigger character for tag prefixes. Like if I start a sentence with "C" should it just pop up all my personas with prefix tags starting with C even if I'm typing "Call me" or "Come on"? Maybe you'd have to hit TAB to show options. Or maybe it should be a user setting. I'm really not sure. In my most recent update I defined an unlisted/public/private system for personas where unlisted is the default (meaning details like bio of a persona are only available to those who see your messages and share a server/guild or are friends). Public means it shows up in the public persona listing for their account, private means it doesn't appear in the listing and also cannot be queried (they only see the bare minimum name and avatar in the snapshot data attached to messages). I'm open to revisiting this design, it's preliminary.
Permalink
Comment by @chiaracoetzee
RexSystem 1 vote originally by @chiaracoetzee on GitHub OP
I see what you mean now about the icon showing up based on what tag you're using in current message. Right now in current design the selector is showing active (default untagged) persona but I like the idea of it switching based on who the current message will be sent as, just as an extra visual indicator/warning. That's a good idea and I'll go ahead and do it. Edit: It is done, it's very cool! I was thinking of also having some kind of prefix character like & or something to search personas and then inject the prefix/suffix without having to click on the selector button, but that's a separate thing for later.
Permalink
Comment by @chiaracoetzee
RexSystem 1 vote originally by @chiaracoetzee on GitHub OP 4 replies
Other features I've added since last update:
  • Added personas to Flutter client for Android and iPhone and tested on both Android and iPhone devices
  • system tag which I call display tag, attached to all personas owned by a user, includes text and icon
  • internationalization and translations (for all supported Fluxer languages)
  • shows persona name in "is typing" message
  • ability to mention personas with @
  • nightly rebase job that keeps my feature fork up-to-date with upstream Fluxer
Hailey's clean-room re-implementation for the server and web client has also been progressing well! REST API, persona selector, persona settings, rendering persona messages, etc. image image image {6A6CA62C-2866-4F14-A65F-90F79D20712A}
  • 654215039-e8b37914-055b-42bb-baa7-df71b2d2a6e7.png

    654215039-e8b37914-055b-42bb-baa7-df71b2d2a6e7.png

    1566×1599 | 270 kB

  • 654215872-b371ea62-88ea-4212-980a-ce484f6b48a4.png

    654215872-b371ea62-88ea-4212-980a-ce484f6b48a4.png

    1080×2400 | 363 kB

  • 654217373-8ae000be-4547-4a52-b419-f0e917526b2a.png

    654217373-8ae000be-4547-4a52-b419-f0e917526b2a.png

    652×221 | 30 kB

  • 654217087-6045a304-977d-4e20-a125-748b45f6def5.png

    654217087-6045a304-977d-4e20-a125-748b45f6def5.png

    789×331 | 39 kB

Permalink
Comment by Speykious
Speykious 1 vote originally by @Speykious on GitHub
If I understand correctly, is TEST SYSTEM supposed to be the name of the main account? It should probably not look like it's a different kind of bot. I think that to indicate that this is someone talking through a persona, using a stack of two circles for the profile picture would potentially be better, with the main account's pfp largely hidden by the persona's pfp. image I'm thinking of these two cases. The left one is what's displayed when multiple people are typing, the second one is made up but seems more readable to me after trying it. It has slightly smaller circles with a bigger spacing to better see part of the circle in the background. Maybe with that kind of display you wouldn't need to directly show the system name? Either way a stack like this would be good I think
  • 654302335-6df27ae2-2d88-493e-8046-8a7561b41d0c.png

    654302335-6df27ae2-2d88-493e-8046-8a7561b41d0c.png

    788×380 | 240 kB

Permalink
Comment by Hailey
Hailey 1 vote originally by @haileyscommit on GitHub
I do like the stack design, however it does tend to imply that it's multiple people talking (so, a feature where multiple personas can be used for a message could use these). Plus, it would also make the profile pictures smaller since they'd need to fit in the same space. I think both of these approaches are actually already implemented in Fluxer in a couple places: the left one is used for typing indicators when multiple people are typing, and the right is used for group DMs. (For a hypothetical multiple-personas-writing-one-message feature, I'd use the one on the right.)
Permalink
Comment by @j0lol
RexSystem 1 vote originally by @j0lol on GitHub
Personally, I would avoid a design that looks like the often-maligned APP/BOT label on Discord.
Permalink