MSC4015: Voluntary Bot indicators

[MTRNord]

Rendered

Signed-off-by: Marcel Radzio support@nordgedanken.dev

Client implementation(s):

• Cetirizine: Logic to fetch value and Visualizing (adds a bot icon to displaynames)
  

[turt2live]

For our future selves trying to determine if this is ready for FCP, I believe the implementation requirement for this MSC is effectively answering the question "Do users of X client want to distinguish between humans and bots, and does that need to be a strong guarantee?" multiple times (ideally against popular clients).

As of writing, this MSC is trivial to write code for, so I don't think it needs too many links to PRs on the subject. The implementation requirement is to fulfill two purposes: first, that the MSC is technically achievable (already proven implicitly by this MSC), and second that there's interest in the idea (even if not agreement on the technical aspects). The second point feels more vital for this MSC, as adding bot-specific flair isn't great if no one wants it.

For clarity, I believe this amounts to opening issues/questions against several other clients to ask the question above in some way, proving that they're interested in the feature and thus passing implementation. Whether those clients go the extra mile to actually write code to support this feature is great, but I don't think accomplishes the purpose of implementation here.

[FSG-Cat]

Not exactly sure where in the MSC wording that makes this clear should be slotted but noted here so its not forgotten.

Implementations of the MSC have to decide them selfs if they trust a given remote network and their bot markers enough to bridge them. Bridged users on discord for example and users of the popular in some groups on the platform accessibility tool Pluralkit will be incorrectly flagged as bots due to both examples using webhooks.

If a implementation ignores the bot markers from networks that are unreliable with their bot markers or implements special rules the bridge will be able to preserve a higher degree of usefulness of this voluntary bot marker.

[MTRNord]

Not sure if this is a thread for here or not but a possible User for this could be the TI-Messenger/Gematik since that spec requires marking Bots as "Chatbot" in the name currently.

(Page 39 of the "Spezifikation TI-Messenger-Client" Version 1.1.1 Document)

For english readers the screenshot says (translated using DeepL):

It MUST be possible to enter function accounts into the VZD-FHIR directory as endpoint of a "HealthcareService" resource of an organisation via the Org-Admin-Client. When configuring the endpoint by the actor in the role "Org-Admin", the display name MUST contain the marker "Chatbot" if the function account is realised via a chatbot. The following formation rule shall be used for the display name: [name of the function account] (chatbot).

[HarHarLinks]

As a reference, this is how I achieve this on my server for my community currently with emoji:

[uhoreg]

The implementation requirement is to fulfill two purposes: first, that the MSC is technically achievable (already proven implicitly by this MSC), and second that there's interest in the idea (even if not agreement on the technical aspects). The second point feels more vital for this MSC, as adding bot-specific flair isn't great if no one wants it.

For clarity, I believe this amounts to opening issues/questions against several other clients to ask the question above in some way, proving that they're interested in the feature and thus passing implementation. Whether those clients go the extra mile to actually write code to support this feature is great, but I don't think accomplishes the purpose of implementation here.

Some existing issues:

• Bots should not be considered as persons in a 1:1 element-hq/element-meta#1468
• Bots should not be considered when auto-naming rooms element-hq/element-meta#446
• We need to specify a way to flag whether a user is a bot or not (to allow bots to ignore each other when mirroring) (SPEC-12) matrix-spec#27 and Add more metadata to m.room.member events (for bots and ASes) (SPEC-113) matrix-spec#22 (We need to specify a way to flag whether a user is a bot or not (to allow bots to ignore each other when mirroring) (SPEC-12) matrix-spec#27 (comment) proposes a similar solution to this MSC)