Plural Acessibility

Feature Proposal
1

Please read 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/ 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/ 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.

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

5 Likes
2

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 , 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).

3

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}`).

4

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, like Live Chat or Realtime Chat.

Such a WebXDC app can be written and used by anyone, independently of the client. webxdc.org has instructions on how to write one.

5

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, it informs a lot of the draft choices.

2 Likes
6

What if one headmate wants to e.g. leave a group chat? Should all the other ones be forced to leave with them?

7

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.

8

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.

4 Likes
9

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.

1 Like
10

Subprofile management that is not chat-specific is clear, but there are several ways to globally manage it.

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.

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.

11

Currently, a blocking profile does not download or display messages from a blocked profile. Profiles on the same device have separate block settings:

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 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.

12

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 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 thread now.