MSC4144: Per-message profiles

[tulir]

Rendered

Implementations:

• Clients rendering profiles:
  • gomuks web: Render MSC4144 Per-Message Profiles gomuks/gomuks#566
  • Sable: Implement per-message profile management and sending with a per-message profile SableClient/Sable#309
  • Cinny: timedoutuk/cinny@38454be
• Bots sending profiles:
  • Linear maubot: beeper/linear-maubot@88dfdd4
  • GitHub maubot: maubot/github@c6d768b
  • mautrix-discord: https://github.com/mautrix/discord/blob/v0.7.3/portal_convert.go#L360-L373
  • mautrix-slack: https://github.com/mautrix/slack/blame/v0.2.1/pkg/msgconv/from-slack.go#L92-L100
  • mautrix-irc: mautrix/irc@a506e9b
  • any bridge written using mautrix-go/bridgev2: bridgev2: add option to use single bot instead of appservice mautrix/go#484

Signed-off-by: Tulir Asokan tulir@beeper.com

[tulir]

@Stealthii said outside of a thread:

To address one of the main criticisms I have with this MSC: the suggestion of matching specifically this tag: <strong\s+data-mx-profile-fallback(?:="")?\s*>([^<]+): </strong\s*>

If we are recommending regular expressions, I would suggest the following, which is safer, handling multi-line input, other tags, matching the same closing tag, etc.

input = input.replace(/<(\w+)[^>]*\bdata-mx-profile-fallback\b[^>]*>[\s\S]*?<\/\1>/g, "")

This however is not 100% safe, no regular expression is. Personally I would like to argue for non-fallback content to be explicitly stated in that MSC in a separate property field, because regex should be used for matching, not content manipulation in matrix client or bridge implementations.

Similarly, suggesting trimming the plaintext component by "PMP name length + 2" also assumes that clients implement the spec accurately as it stands today, and do not deviate. This also cannot be guaranteed.

[tulir]

Personally I would like to argue for non-fallback content to be explicitly stated in that MSC in a separate property field

Duplicating the entire content is a really bad idea. Each fallback doubles the content, so if there are 3 different fallbacks (edits, formatting, per-message profiles), that'd result in 2*2*2 = 8 duplicates of the content. It might be "only" 6 duplicates if the non-fallback per-message profile is only inside m.new_content, but if anyone decided to invent a new thing needing a fallback copy, it'd jump to 12 or more

which is safer, handling multi-line input, other tags, matching the same closing tag, etc.

The regex is intentionally fairly strict, other tags are not meant to be allowed. It could maybe slightly be relaxed in terms of the trailing space inside the fallback to allow \n there (<br> is obviously not allowed), perhaps :\s* instead of :

Alternatively, I guess the fallback itself could be put in another field, such that clients can simply do formatted_body.replace(fallback, "") rather than using a regex 🤔

Similarly, suggesting trimming the plaintext component by "PMP name length + 2" also assumes that clients implement the spec accurately as it stands today, and do not deviate. This also cannot be guaranteed.

The only consequence of deviating from the spec is that the message will render incorrectly. If clients don't implement the spec correctly and their messages render differently than they intended, that's their problem, not the spec's.

[tulir]

@Blackilykat posted outside of a thread:

I'm not active in matrix spec proposals but am developing a bot which benefits from this feature and I'd like to give my 2 cents.

I think the sender should have more freedom on how to format the HTML fallback. Currently, it is required to be in exactly a <strong> tag with the data-mx-profile-fallback attribute containing exactly the text <profile>: . I think it would be beneficial to allow any tag (i.e. span) with the same attribute and any contents, including HTML formatted contents. This would include the original fallback but allow bots to customize the fallback if needed.

My use case: I am bridging a Minecraft chat over matrix. Different players have different chat formats which I would like to include in the fallback so outdated clients will see chat exactly as shown in-game. Clients which support this feature would instead show the message as if it was sent by that user, ignoring the HTML content inside the fallback.

If a client supports HTML-formatted content it should already have the logic to correctly parse HTML tags and ignoring a first tag with the data-mx-profile-fallback attribute, regardless of which tag it is or its contents, should not be difficult to implement.

[tulir]

Clients may want to remove fallbacks at a different stage than HTML parsing, so requiring the use of a parser is probably a bad idea. Several clients had trouble with reply fallbacks too.

A separate field containing the exact fallback string to remove should be easy and safe to remove, but it also feels slightly weird and has never been done before. Maybe I should just do that anyway

[Blackilykat]

Maybe you could include the length of the formatted fallback string instead of the whole thing to avoid sending/storing duplicate data.

[tulir]

That would require it to strictly be a prefix, which may not be the case if the message uses paragraph tags or other such things

[q-TheDog]

Client Implementation (Haven Desktop): Haven-Organization/haven-desktop@15fd359