# Plural Acessibility \[Sub-profiles: send messages under different names and avatars from one profile\] **URL:** \ **Category:** Feature Proposal\ **Created:** [February 26, 2026, 3:03pm UTC](https://forum.delta.chat/t/plural-acessibility-sub-profiles-send-messages-under-different-names-and-avatars-from-one-profile/4804 "2026-02-26T15:03:36Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Coca](https://forum.delta.chat/user_avatar/forum.delta.chat/coca/32/3216_2.png) [@Coca](https://forum.delta.chat/u/Coca)\ **Post date:** [February 26, 2026, 3:03pm UTC](https://forum.delta.chat/t/plural-acessibility-sub-profiles-send-messages-under-different-names-and-avatars-from-one-profile/4804/1 "2026-02-26T15:03:37Z")
Please read [https://morethanone.info/](https://morethanone.info/) if you are not familiar with plurality before reading further. Specific members of a system shall be referred to as headmates in this text. This topic will discuss providing features to improve the accessibility of Delta Chat for plural systems. Headmates are likely to want to be able to be easily identifiable as specifically them when talking to other users on chat platforms. Currently systems which frequently switch between headmates or have a large amount of headmates face frustration with being clearly identifiable in Delta Chat. Profiles are not easily able to be switched to and managing many profiles can be very tedious, requiring each headmate to join a group chat; this does not scale well. We are proposing as a solution for this: sub-profiles. When a user has selected a sub-profle, messages they sent will be under the name and image of that sub-profile. These would be allow systems to comfortably switch between headmates on every group chat they are in and without worrying about managing multiple profiles. [https://pluralkit.me/](https://pluralkit.me/) is one of the most widely used tools for plural accessibility, with over 1 million guild installs on discord. This proposal is directly inspired by the UX of Pluralkit for systems, as it is likely the best tooling currently available. However, as it works through deleting and resending messages via webhooks it causes visual jitter in the chat UI that can be confusing for users who have not interacted with systems before due to `BOT` tags in messages it proxies. A similar solution directly integrated in the chat platform would not have these drawbacks. [https://stoat.chat/](https://stoat.chat/) is also already doing similar work to provide this feature called masquerade, however it has only been implemented on server-side and has no way to be easily used in the UI. Its name is also somewhat problematic, as “masquerade” is not neutral towards plural use (see addendums/naming). As with any other accessibility tooling these sorts of things have benefits for users outside of just the main target audience, sub-profiles can be used for things such as: - More personalized name and profile picture for specific contexts - Roleplaying characters - Clarity for multiple physical individuals working from the same account - Anecdotal evidence of a Siamese twins case benefiting ## Implementation This is a list of all the possible work necessary for the implementation of this proposal. Annotations are provided below. Inherent: Required for this to exist Usage: Ways users would use the feature Social: Extras for communicating to other users usage of sub-profiles Convenience: Extras that would be helpful to some users - Inherent: sending messages via premade sub-profile - Globally managed and not chat specific - Synchronized between devices - Inherent: sub-profile creation/editing/deletion - A sub-profile should have the same information root profiles do, ie a bio - Inherent: messages carry their sub-profile’s names & avatars - Usage: switching & triggers - GUI interface for switching between sub-profiles - Text input to allow switching between sub-profiles to be more fluid and quick - Reimplement common trigger modes from existing tools (see addendums/pluralkit proxy triggers) - Ability to edit a sent message and re-assign it to a different sub-profile without deleting - Social: sub-profiles listed in profile (off by default, toggleable globally or per-chat) - Social: arbitrary depth nesting of sub-profiles - Convenience: separate export/import for only sub-profiles - Would allow for migrators from Pluralkit to easily switch over if compatible or easily convertable from Pluralkit’s export - Convenience: chat-specific overrides for sub-profile fields (name/icon/etc) - Alternatively also having specific sub-profiles for chats would also work here ### Frontend - Modal for management of sub-profiles, accessible in settings - Button in the message composer that provides a drop down with sub-profiles to switch to - Synchronized with switching through text input if latching (see addendums/pluralkit proxy triggers) - A button for opening the sub-profile management modal could be convenient in the menu as well - Contact modal when opening a sub-profile from the chat should show the info of the sub-profile and the root profile as well - Support for setting several icons on a profile instead of just 1 - Paging through icons in profile view similar to telegram? - Automatically keep X old icons in there for everyone regardless of whether they use sub-profiles? - If social features added: browsable profile tree (list sub-profiles of current profile, navigate to sub-profile, navigate to super-profile, jump to system root) - Bonus: graph view (no one asked for this but it _would_ be funny) ## addendums ### naming Name choice criteria: - usage-agnostic (do not imply limitation to “only plural systems”, “only clear-cut plural systems”, “only systems of particular type” etc) - no value judgement (do not imply a specific nature/inner structure of the action, ie a level of deceit, a particular amount of identity separation) #### “sub-profile” Presently used in this doc. Does not imply particular usecase. Does not imply inner structure behind usage. _Does_ imply user-profile objects associated with the feature; that is indeed part of the proposal. #### “alias” Does not imply particular usecase. Does not imply inner structure behind usage. Confusable with email aliases. #### “masquerade” Stoat term. Implies a particular usage (roleplay / pretense). Implies masquerades are merely a cosmetic choice or disguise for a profile. #### “proxy” Pluralkit term. Socially neutral, but a result of implementation details (pluralkit bot needing to intercept and proxy messages due to discord API limitations); as such does not make much sense in a native impl. #### “tupper” Tupperbox term. Implies a particular usecase (skewed strongly towards tulpagenic systems). #### terminology to avoid **“parent/child” for sub-profile tree** : undesirable for social reasons (implies parent-child relationship between system members where none might exist). ### Sub-profile disambiguation This proposal initially contained subprofile disambiguation UI features; however, it was decided against it after further discussion and reading [this post](https://www.tumblr.com/sleepingdragoninn/808807363129769984/oh-and-our-cred). Implementing any kind of disambiguation together with this would proliferate the assumption that using sub-profiles is positively correlated with trying to deceive correspondents, effectively turning into tool-level discrimination. Sub-profile ambiguity is easily resolvable by asking or by opening the contact modal by clicking on the profile. Any disambiguation should not be done specifically for sub-profiles on the chat level. Release timing also matters. Shorthash/hashart glance identifiers on accounts are worth their own proposal, but if they’re conflated with this one they’ll create a negative connotation. ### Pluralkit proxy triggers What is familiar to PK users so far. Close replication would help users migrate. #### tag/prefix 1. User defines a textual prefix/postfix for a specific proxy (`A/text` for `Alice`, `B/text` for `Beth`) 2. Pluralkit sees incoming message 3. Message matches proxy tag (`A/good morning`)? Pluralkit sends the message under corresponding proxy (`Alice: good morning`) this always has priority over everything else #### automatic (preselected) 1. User sends a pluralkit command, selecting a specific proxy (`pk;autoproxy Alice`) 2. Pluralkit sees incoming message 3. Message has a tag (`B/good morning`)? Pluralkit sends message under corresponding proxy (`Beth: good morning`) 4. Message has no tags (`good morning`)? Pluralkit sends message under proxy from step 1 (`Alice: good morning`) #### automatic (latch) 1. User sends a pluralkit command, activating latch mode (`pk;autoproxy latch`) 2. Pluralkit sees incoming message 3. Message has no tag (`hello`) & no last used proxy is known? Do nothing (`System: hello`) 4. Message has no tag (`hello`) & a last used proxy is known (`Alice`)? Send under last used proxy (`Alice: hello`) 5. Message has a tag (`B/hello`)? Send message under corresponding proxy (`Beth: hello`); set “last used” to the corresponding proxy Scope for “last used” is kept for several hours to prevent situations where the system logs off for several hours and then misproxies a message by mistake. ## Credit - Cowritten by @cyanidesunrise - Reviewed by several creatures ---
**Author:** ![Minim](https://forum.delta.chat/letter_avatar_proxy/v4/letter/m/ccd318/32.png) [@Minim](https://forum.delta.chat/u/Minim)\ **Post date:** [February 27, 2026, 4:28pm UTC](https://forum.delta.chat/t/plural-acessibility-sub-profiles-send-messages-under-different-names-and-avatars-from-one-profile/4804/2 "2026-02-27T16:28:32Z")
So the first part of the string typed into the “send” field would need to be processed by a program with about the sophistication of [sed - Wikipedia](https://en.wikipedia.org/wiki/Sed) , not sent raw? This sounds like something best done with a client-side draft-editing app (the sort of program that could also auto-replace all instances of “teh” with “the” before sending). > [@Accessibility: Support Alt Text for Uploads and Stickers](https://support.delta.chat/t/accessibility-support-alt-text-for-uploads-and-stickers/4764/15): > > A WebXDC app could be used to manually add an alttext to a file when sending it to a chat. The user would need to manually attach the app to the chat, though, then attach the image in the app, a slower and kludgier UI. Having a UI option to pin a minimized draft-message-editing app to the bottom of a chat might make app functionality much more useful for this sort of purpose. It could be used for custom emoji-pickers, other special characters, stickerpacks, shared-secret encryption, file-forma… ---
**Author:** ![cyanidesunrise](https://forum.delta.chat/user_avatar/forum.delta.chat/cyanidesunrise/32/3212_2.png) [@cyanidesunrise](https://forum.delta.chat/u/cyanidesunrise)\ **Post date:** [February 27, 2026, 4:54pm UTC](https://forum.delta.chat/t/plural-acessibility-sub-profiles-send-messages-under-different-names-and-avatars-from-one-profile/4804/3 "2026-02-27T16:54:18Z")
> [@Minim](#): > > So the first part of the string typed into the “send” field would need to be processed by a program with about the sophistication of [sed - Wikipedia](https://en.wikipedia.org/wiki/Sed) , not sent raw? Not really, proxy tags are literal and you know their length before you begin, so sed would be vastly overkill. The dumbest possible impl would be a minimum length check + 2x literal substring match for every tag registered, if you allow combining prefixes and postfixes (pluralkit does, you can set your tag to something `{text}`). ---
**Author:** ![Minim](https://forum.delta.chat/letter_avatar_proxy/v4/letter/m/ccd318/32.png) [@Minim](https://forum.delta.chat/u/Minim)\ **Post date:** [February 27, 2026, 5:14pm UTC](https://forum.delta.chat/t/plural-acessibility-sub-profiles-send-messages-under-different-names-and-avatars-from-one-profile/4804/4 "2026-02-27T17:14:22Z")
Given some sort of draft-editing function, this sounds as if it would be pretty easy to implement clientside. Absent that, it would be possible to implement it in a chat-in-chat-style [WebXDC app](https://webxdc.org/apps), like Live Chat or Realtime Chat. Such a WebXDC app can be written and used by anyone, independently of the client. [webxdc.org](http://webxdc.org) has instructions on how to write one. ---
**Author:** ![cyanidesunrise](https://forum.delta.chat/user_avatar/forum.delta.chat/cyanidesunrise/32/3212_2.png) [@cyanidesunrise](https://forum.delta.chat/u/cyanidesunrise)\ **Post date:** [February 27, 2026, 5:36pm UTC](https://forum.delta.chat/t/plural-acessibility-sub-profiles-send-messages-under-different-names-and-avatars-from-one-profile/4804/5 "2026-02-27T17:36:15Z")
An implementation via an optional applet (and especially via an opt-in nested chat applet) is not fitting for an accessibility feature. Needing to go into the “add app” modal, specifically search for a subprofile app (which requires knowing it exists in the first place), add it to every chat you want to use it in, potentially copy subprofile settings between chats (sync nightmare if you have a lot of them; also delta allows you to make several instances of a webxdc app per chat which could get very confusing), or open a separate UI to send a “hi“ adds a lot of friction and tanks discoverability. This is exactly what we are trying **not** to do. The point is to add first-class support for the feature that feels as a natural part of the app, does not punish users with extra friction and is intuitively discoverable. I recommend reading this [post we referenced](https://www.tumblr.com/sleepingdragoninn/808807363129769984/oh-and-our-cred), it informs a lot of the draft choices. ---
**Author:** ![WofWca](https://forum.delta.chat/user_avatar/forum.delta.chat/wofwca/32/1702_2.png) [@WofWca](https://forum.delta.chat/u/WofWca)\ **Post date:** [February 27, 2026, 6:02pm UTC](https://forum.delta.chat/t/plural-acessibility-sub-profiles-send-messages-under-different-names-and-avatars-from-one-profile/4804/6 "2026-02-27T18:02:34Z")
What if one headmate wants to e.g. leave a group chat? Should all the other ones be forced to leave with them? ---
**Author:** ![cyanidesunrise](https://forum.delta.chat/user_avatar/forum.delta.chat/cyanidesunrise/32/3212_2.png) [@cyanidesunrise](https://forum.delta.chat/u/cyanidesunrise)\ **Post date:** [February 27, 2026, 6:07pm UTC](https://forum.delta.chat/t/plural-acessibility-sub-profiles-send-messages-under-different-names-and-avatars-from-one-profile/4804/7 "2026-02-27T18:07:02Z")
These sorts of things are handled on system consensus (because there is usually no other sane way to do it without splitting accounts). If a member doesn’t want to read a chat, they don’t read the chat while present. If they actively take psychic damage from being in one, the system may decide to leave. Being able to make situational display filters of chats would be useful in this regard, but it’s out of scope for this thread I think. ---
**Author:** ![link2xt](https://forum.delta.chat/user_avatar/forum.delta.chat/link2xt/32/1971_2.png) [@link2xt](https://forum.delta.chat/u/link2xt)\ **Post date:** [February 27, 2026, 6:22pm UTC](https://forum.delta.chat/t/plural-acessibility-sub-profiles-send-messages-under-different-names-and-avatars-from-one-profile/4804/8 "2026-02-27T18:22:35Z")
The usecase is very similar to what bridge bots need. Bridges normally use a single profile, but need to appear with different display names and ideally avatar for each message, with some indication that messages are sent by the bridge. Currently bridges can overwrite the display name per-message and it is indicated with `~` in front of display name, but avatar of the bridge bot is always displayed next to the message. EDIT 2026-03-22: There is a related topic > [@BOT - Impersonate / Alias names](https://support.delta.chat/t/bot-impersonate-alias-names/482): > > TL;DR; Bot can change avatar and nickname to impersonate people, but a [bot] label is shown and the profile on click is still the bot ones. This feature is particularly useful for bridge bots. ---
**Author:** ![tudbut](https://forum.delta.chat/letter_avatar_proxy/v4/letter/t/45deac/32.png) [@tudbut](https://forum.delta.chat/u/tudbut)\ **Post date:** [February 27, 2026, 6:34pm UTC](https://forum.delta.chat/t/plural-acessibility-sub-profiles-send-messages-under-different-names-and-avatars-from-one-profile/4804/9 "2026-02-27T18:34:37Z")
This seems useful, so then we would only need a UI for it right? And maybe also a way to have message-specific profile pictures. ---
**Author:** ![Minim](https://forum.delta.chat/letter_avatar_proxy/v4/letter/m/ccd318/32.png) [@Minim](https://forum.delta.chat/u/Minim)\ **Post date:** [March 2, 2026, 11:24pm UTC](https://forum.delta.chat/t/plural-acessibility-sub-profiles-send-messages-under-different-names-and-avatars-from-one-profile/4804/10 "2026-03-02T23:24:51Z")
Subprofile management that is not chat-specific is clear, but there are several ways to globally manage it. > [@Coca](#): > > Scope for “last used” is kept for several hours to prevent situations where the system logs off for several hours and then misproxies a message by mistake. If “last used” info was done on the basis of “last message sent from this profile that this device knows about”, then it would automatically be kept indefinitely (caveats that deleting recent messages, or failing to download them to some devices when switching devices, might change the last-used subprofile). Profiles may exist on multiple devices. It would be possible to store last-used info in the profile and sync between devices using system messages, but that might not really change functionality much. And, especially with message drops and delays, it would add a lot of ways for things to go wrong. Purely per-profile management could also cause problems. Currently it is possible to have different subsets of profiles on different devices. As with e-mail addresses, some profiles are concurrently shared or sequentially passed between multiple physical individuals, especially if they belong to a social role (like “an on-duty dispatcher”, “webmaster(s) of the forum”, or “our club’s current treasurer”). If two people are responding simultaneously from one profile on two devices, they probably wouldn’t want to reset one another’s subprofiles. They’d often want to use separate subprofiles. “Last subprofile used in this profile on this device” might be a useful thing to store on each device, and use to set the profile. It could have a selectable expiry time before going to default. Users would sometimes need to remember to switch subprofiles when switching devices. Purely per-device cross-profile subprofile selection would require each profile to have either the same set of subprofiles, or some fallback algo. But selectively copying and sharing subprofiles between profiles seems useful. > [@Coca](#): > > separate export/import for only sub-profiles The profile info is the transport info (cryptographic keys, e-mail addresses and passwords), so exporting or importing the subprofile would functionally require bringing the profile info with it. A profile could have different sets of subprofiles on different devices, though. Key rotation is planned and might make use of subprofiles. ---
**Author:** ![Minim](https://forum.delta.chat/letter_avatar_proxy/v4/letter/m/ccd318/32.png) [@Minim](https://forum.delta.chat/u/Minim)\ **Post date:** [March 2, 2026, 11:26pm UTC](https://forum.delta.chat/t/plural-acessibility-sub-profiles-send-messages-under-different-names-and-avatars-from-one-profile/4804/11 "2026-03-02T23:26:08Z")
> [@cyanidesunrise](#): > > Being able to make situational display filters of chats would be useful in this regard, but it’s out of scope for this thread I think. Currently, a blocking profile does not download or display messages from a blocked profile. Profiles on the same device have separate block settings: > [@The blocked user](https://support.delta.chat/t/the-blocked-user/1122/4): > > Blocking is completely local. If you block user, you simply don’t download their emails. There is a bug now that if you block a user, you will miss the message where they remove you and have inconsistent group state. It is interesting to see how other messengers implement this. What happens when you block a user and they send messages in the shared group, delete other users etc.? Sub-profile view filters would need a completely different implementation. There are actually already some filterlike search functions, but they are not very discoverable (accessed by typing magic strings into the searchbar), nor are they reusable. Subprofiles could also be useful as (or attached to) an improved filter UI. There is current discussion of [group moderation](https://support.delta.chat/t/new-feature-group-types/263) and specifically blocking within groups. It seems highly desirable to have subprofile-level blocking, especially if some subprofiles are bridged social media accounts from platforms that have more problems with obnoxious users than DC typically does. So discussing this at the same time as subprofiles might be useful. ---
**Author:** ![Minim](https://forum.delta.chat/letter_avatar_proxy/v4/letter/m/ccd318/32.png) [@Minim](https://forum.delta.chat/u/Minim)\ **Post date:** [March 2, 2026, 11:27pm UTC](https://forum.delta.chat/t/plural-acessibility-sub-profiles-send-messages-under-different-names-and-avatars-from-one-profile/4804/12 "2026-03-02T23:27:37Z")
> [@cyanidesunrise](#): > > The point is to add first-class support for the feature that feels as a natural part of the app, does not punish users with extra friction and is intuitively discoverable. That would be vastly preferable, more usable and useful. And apologies, I should not have responded to a request for a built in-feature with info about implementing it as an add-on. I had [previously suggested](https://support.delta.chat/t/accessibility-support-alt-text-for-uploads-and-stickers/4764/15) making a new extension type as a stopgap for accessibility features which the development team has not implemented, and was pointing out that a draft-editing UI would also be greatly superior to a chat-in-chat UI here. It was offtopic, and I’ve split that into a new [draft-editing extensions](https://support.delta.chat/t/draft-editing-apps/4840) thread now. ---
**Author:** ![SleepyCatten](https://forum.delta.chat/user_avatar/forum.delta.chat/sleepycatten/32/2705_2.png) [@SleepyCatten](https://forum.delta.chat/u/SleepyCatten)\ **Post date:** [March 8, 2026, 4:11pm UTC](https://forum.delta.chat/t/plural-acessibility-sub-profiles-send-messages-under-different-names-and-avatars-from-one-profile/4804/13 "2026-03-08T16:11:17Z")
As a plural (median, blurian) entity, we would honestly absolutely love to see functionality for this 🩷 If we were asking for priorities, we’d ask for basic formatting options first above it though, either through the use of markdown or (if push comes to shove) the limited formatting options available with Signal. 100% behind this though, and love PluralKit 🥰🫶 ---
**Author:** ![cyanidesunrise](https://forum.delta.chat/user_avatar/forum.delta.chat/cyanidesunrise/32/3212_2.png) [@cyanidesunrise](https://forum.delta.chat/u/cyanidesunrise)\ **Post date:** [March 8, 2026, 4:37pm UTC](https://forum.delta.chat/t/plural-acessibility-sub-profiles-send-messages-under-different-names-and-avatars-from-one-profile/4804/14 "2026-03-08T16:37:20Z")
> [@Minim](#): > > Currently, a blocking profile does not download or display messages from a blocked profile. Profiles on the same device have separate block settings: While talking about filters I was thinking they’d be separate from the block mechanism. Possibly conflated with muting instead (option to entirely hide muted conversations but still download them in the background + option to make mute presets?) > [@Minim](#): > > Purely per-device cross-profile subprofile selection would require each profile to have either the same set of subprofiles, or some fallback algo. But selectively copying and sharing subprofiles between profiles seems useful. Automatically sharing subprofiles between all profiles on the same device would probably turn into sync hell. Beneficial for weird setups where multiple accounts are in use for the same purpose already? I’m for non-synced switching (“last used on this device”) and no auto export here. > [@Minim](#): > > The profile info is the transport info (cryptographic keys, e-mail addresses and passwords), so exporting or importing the subprofile would functionally require bringing the profile info with it. A profile could have different sets of subprofiles on different devices, though. By “separate” we meant a mechanism that’s detached from account import/export. A zip containing just subprofile settings JSON (bare minimum info) and icons would be enough. This was mostly for platform migration purposes, IIRC pluralkit lets you dump your settings like this. ---
**Author:** ![Minim](https://forum.delta.chat/letter_avatar_proxy/v4/letter/m/ccd318/32.png) [@Minim](https://forum.delta.chat/u/Minim)\ **Post date:** [March 8, 2026, 5:03pm UTC](https://forum.delta.chat/t/plural-acessibility-sub-profiles-send-messages-under-different-names-and-avatars-from-one-profile/4804/15 "2026-03-08T17:03:10Z")
Changable filters would technically need to be separate from the current implementation of the block mechanism. I think we are saying the same thing about subprofiles. In terms of information, the subprofile is a screenname and and icon and perhaps some filter settings. Copying this subprofile from one profile to another seems like it would be easy, as long as you don’t try to automatically sync the two profiles afterwards. Even being able to semi-manually merge changes from one subprofile to another would be much more difficult to implement than a one-time cloning. Currently, parallel changes to blocklists etc. are done fully manually for each profile, partly for profile separation and privacy. One-time copying would mean that, while every subprofile would technically need a profile, it could use any profile, and be moved between profiles with a copy-delete. A profile can already have multiple e-mail accounts. > [@cyanidesunrise](#): > > I’m for non-synced switching (“last used on this device”) and no auto export here. That sounds simple, so if it’s functional too, that’s great. ---
**Author:** ![ell1e](https://forum.delta.chat/user_avatar/forum.delta.chat/ell1e/32/2308_2.png) [@ell1e](https://forum.delta.chat/u/ell1e)\ **Post date:** [March 11, 2026, 10:42am UTC](https://forum.delta.chat/t/plural-acessibility-sub-profiles-send-messages-under-different-names-and-avatars-from-one-profile/4804/16 "2026-03-11T10:42:12Z")
I’m sorry if this sounds like discrimination at all, but regarding the disambiguation, isn’t it kind of important for end-to-end encryption to be able to tell what profile a message originates from to avoid bad actors (that is, not-plural people using sub-profiles to deceive correspondents)? Similarly, tracking who you already spoke to before, which the tumblr post seems to suggest as bad, seems pretty important to e.g. make any sort of manual checkmark verifications work. Sorry if I’m missing something here, I genuinely don’t mean to offend. I get that avoiding discrimination is a huge concern, but I feel like so is trying to avoid forged messages completely outside of the plural context. ---
**Author:** ![irvan-putra](https://forum.delta.chat/user_avatar/forum.delta.chat/irvan-putra/32/2473_2.png) [@irvan-putra](https://forum.delta.chat/u/irvan-putra)\ **Post date:** [March 11, 2026, 10:54am UTC](https://forum.delta.chat/t/plural-acessibility-sub-profiles-send-messages-under-different-names-and-avatars-from-one-profile/4804/17 "2026-03-11T10:54:01Z")
yeah i also would like more security consideration since i have been dealing with persistence attacker using my friends profile picture and name, doing bad things ---
**Author:** ![cyanidesunrise](https://forum.delta.chat/user_avatar/forum.delta.chat/cyanidesunrise/32/3212_2.png) [@cyanidesunrise](https://forum.delta.chat/u/cyanidesunrise)\ **Post date:** [March 11, 2026, 11:36am UTC](https://forum.delta.chat/t/plural-acessibility-sub-profiles-send-messages-under-different-names-and-avatars-from-one-profile/4804/18 "2026-03-11T11:36:06Z")
As mentioned in Addendums/Sub-profile disambiguation, we did consider that, but found it unfitting to just put a bright “HEY LOOK THESE TWO MESSAGES WERE SENT FROM THE SAME DEVICE” sign on messages or profile modals. FWIW if using subprofiles in DMs does not start a new conversation, and DMs remain strictly 1:1 between two accounts, then the surface area for forging remains about the same? But that _is_ another kind of signing. I think if you _have to_ do disambiguation, the best way would be some sort of hash-art element to notifications / user appearance based on encryption keys, enough to throw the reader off if it changes but not enough to be distracting while it’s in the background. Maybe an avatar frame, maybe a faint background pattern in the message list, with the option to mark an account as trusted and turn it off. ---
**Author:** ![EtoOnAmill](https://forum.delta.chat/user_avatar/forum.delta.chat/etoonamill/32/2934_2.png) [@EtoOnAmill](https://forum.delta.chat/u/EtoOnAmill)\ **Post date:** [March 11, 2026, 11:42am UTC](https://forum.delta.chat/t/plural-acessibility-sub-profiles-send-messages-under-different-names-and-avatars-from-one-profile/4804/19 "2026-03-11T11:42:58Z")
I see where you are coming from, for that in my opinion it would be pretty important to have a easy way to check relationship with a profile and the subprofiles it controls. The best implementation of this in my opinion would would be making the social features available in the contact information to other users. I do not think an obligatory system tag would be the correct solution, and if something similar is implemented it should be as a customisation option. Also i don’t think any part of the proposal would be in opposition to “manual checkmark verification”. This also depends on wether subprofiles will be implemented as a graphical alteration of the main profile or something more independent. ---
**Author:** ![cyanidesunrise](https://forum.delta.chat/user_avatar/forum.delta.chat/cyanidesunrise/32/3212_2.png) [@cyanidesunrise](https://forum.delta.chat/u/cyanidesunrise)\ **Post date:** [March 11, 2026, 11:44am UTC](https://forum.delta.chat/t/plural-acessibility-sub-profiles-send-messages-under-different-names-and-avatars-from-one-profile/4804/20 "2026-03-11T11:44:32Z")
I kind of doubt this would add any _new_ avenues for forging. We already don’t have global authority on user identifiers, email addresses can be switched between & nothing’s stopping you from getting a lookalike address as far as i know. Preventing impersonation really just comes down to displaying the fingerprint in an intuitive way. Using a burner account with the same icon+bio as your friend is exactly as easy as using a subprofile with the same icon+bio as your friend. [Next page](https://forum.delta.chat/t/plural-acessibility-sub-profiles-send-messages-under-different-names-and-avatars-from-one-profile/4804.md?page=2)