-
Notifications
You must be signed in to change notification settings - Fork 389
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MSC4015: Voluntary Bot indicators #4015
base: main
Are you sure you want to change the base?
Conversation
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. |
This flag cannot be enforced technically since there is no difference in a bot or a normal user on | ||
the technical side. So we need to rely on the user. Furthermore, this flag is not supposed to be used | ||
to detect spambots. It doesn't come with guarantees. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
@@ -0,0 +1,115 @@ | |||
# MSC4015: Voluntary Bot indicators |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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).
@@ -0,0 +1,115 @@ | |||
# MSC4015: Voluntary Bot indicators |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some existing issues:
|
Co-authored-by: Hubert Chathi <[email protected]>
Rendered
Signed-off-by: Marcel Radzio [email protected]
Client implementation(s):