Some useful features are extensions: If we go with GFM, we should at least specify what extensions to use
We do not want syntax for inline media: Instead, use MIMI MultiPart
We do not want syntax for raw html: This increases the scope a lot, since GFM does not define a whitelist. Clients would also need to impose additional security constraints.
"Soft line breaks" may be ignored (decided by renderer): If the user typed a newline, they probably want a newline
Ordered lists must increment by 1 and strip leading zeros 001 -> 1: Markup languages should not change the meaning of the input
No spoiler syntax for messages or media: In Discord it is ||secret||
No autolinks for mimi://
Emojis can have different meanings between platforms, like gun vs water pistol: Maybe clients can annotate what emoji style they use?
I also thought about math support, but I think that should not be part of the text message and instead be a different MIMI MultiPart entry of another content type.
From timo:
Using https://github.github.com/gfm/ as a basis, I have identified the following problems with GFM:
Emojis can have different meanings between platforms, like gun vs water pistol: Maybe clients can annotate what emoji style they use?I also thought about math support, but I think that should not be part of the text message and instead be a different MIMI MultiPart entry of another content type.