-
pep.
https://github.com/mastodon/mastodon/pull/23913 Mastodon implementing rich text formatting with an ok wire format. hint hint
-
jonas’
Transform h1 through h6 tags to <p><strong>contents</strong></p>
-
jonas’
m(
-
Zash
Wasn't it already HTML embedded in JSON?
-
pep.
Well they're not respecting the semantics of html, but at least they're not just stuffing markdown in there
-
pep.
Zash, yeah but a very much restricted set
-
nicoco
I'm curious, why would markdown be a bad thing? too limited?
-
Zash
Not limited enough!
-
Zash
nicoco, we abolished XHTML-IM because web developers can't be trusted not to pass trough <script> and stuff, and markdown is a HTML superset with the same problems
-
Zash
Even with XEP-0393, there was at least one case of someone blindly passing it trough a markdown library with html pass-trough enabled
-
Zash
Thus we can't have nice ~things~ styling, it's not safe!
-
Ge0rG
we can't have nice ~things~ people
-
nicoco
thanks for the context. html pass-through sounds terrible indeed.
-
Zash
Ge0rG, we can't fix people tho, only take away their nice things
-
Ge0rG
that's a good start.
-
Menel
What was the reason not just to add many big warnings what not to do in the xep? And if someone does it anyways, it is on them?
-
MSavoritias (fae,ve)
🤷 good question
-
MSavoritias (fae,ve)
> I'm curious, why would markdown be a bad thing? too limited? Xhtml helps with accesibility https://github.com/mastodon/mastodon/pull/23913#issuecomment-1455180785
-
MSavoritias (fae,ve)
Html*
-
MSavoritias (fae,ve)
Plus its easier on the client to use the format. Instead of having to guess with whatever we currently have
-
jonas’
it would help if they didn't translate headers to <p><strong✎ -
jonas’
it would help if they didn't translate headers to <p><strong/></p> ✏
-
pep.
nicoco, to me it's not about the input format. It doesn't matter at all. It's all about the wire format✎ -
pep.
nicoco, to me it's not about the input format. It doesn't matter at all. It's all about wire format ✏
-
MSavoritias (fae,ve)
Yeah. Stanadard format to parse instead of arbitary characters
-
Link Mauve
jonas’, this is probably at display time, not in the wire.
-
jonas’
sure
-
Peter Waher
Zash: The solution is not to ban the entire (and useful) technology, but to recognize the problem and make sure to highlight/require the script tag not be permitted (i.e. pass HTML or Markdown through a preprocessor that weeds out illegal/unwanted stuff.). To this list, I would add the style attribute and the style element, and any element defined for the HTML header.
-
pep.
Basically what we had in xhtml-im
-
Peter Waher
correct
-
Peter Waher
It might be included in compliancy requirements, that such security vulnerabilities are addressed (i.e. compliancy requirements for clients)
-
MSavoritias (fae,ve)
Sounds like a nice step to me
-
moparisthebest
> Xhtml helps with accesibility > https://github.com/mastodon/mastodon/pull/23913#issuecomment-1455180785 Except it doesn't because markdown is HTML so... (No one that I'm aware of is advocating for a markdown wire format)
-
singpolyma
XHTML-IM is "abolished" just the spec says deprecated on it. It's still the best thing we've got and Implemented by several clients and even by memberbot :)
-
moparisthebest
xhtml-im is XMPP's "malloc/free is fine, just don't make mistakes" :)
-
Zash
Someone motuvated just need to un-deprecate it with a bigget security warning 🤷
-
singpolyma
Honestly I would remove all the "restricted subset" stuff from the spec, that's up to the implemetation. Lots and lots of apps have to sanitize HTML inputs already, including feed readers etc, it's not like this problem is unique to us or hard to solve
-
singpolyma
Just use whatever obvious sanitize your framework/context already has that every non xmpp app is using
-
Peter Waher
PS: Markdown is not HTML, but is a content format (and is often used to generate HTML, but can be used to generate other formats as well). Most Markdown dialects support the embedding of HTML elements (even though it restricts its usefulness when it comes to generate other forms of presentation formats). Still, it is not HTML, and it is parsed (and often pre-processed) before HTML is generated. There are very restricted Markdown dialects also, just as XHTML-IM was a very restricted version of XHTML. Benefits of Markdown include (apart from being easy to write) being extensible with a loosely coupled structure. It might make interoperability a challenge, unless interoperability is structured in a similar way as is done with XMPP (with extensions for different types of constructs).
-
moparisthebest
Peter Waher: a valid html document is a valid markdown document
-
Link Mauve
Peter Waher, Markdown is a HTML superset, in the sense that every valid HTML document is also valid Markdown. Markdown just extends HTML with other formatting, like "*foo*" in CDATA becoming synonymous to <em>foo</em>.
-
Link Mauve
Some Markdown implementations also reject HTML elements present in the text.
-
Link Mauve
It is usually configurable.
-
Peter Waher
No its not
-
Peter Waher
from the creator of the original Markdown:
-
Peter Waher
https://daringfireball.net/projects/markdown/✎ -
Peter Waher
https://daringfireball.net/projects/markdown/ ✏
-
singpolyma
No one is proposing markdown for xmpp anyway :P
-
Peter Waher
yes
-
Peter Waher
but it was not added to the list of proposed extensions
-
Peter Waher
A content-extension where multiple content formats could be embedded in a message (a more abstract and generic version than the existing)
-
Zash
multipart/alternative? feels like it may be overkill while at the same time not too unlike what we already have with plain ol' <body> and xhtml
-
moparisthebest
Multiple copies of the body in different places is also an antifeature: see: lang
-
Zash
Or email-style <body>Click here to see the newsletter</body>
-
pep.
> Multiple copies of the body in different places is also an antifeature: see: lang xml:lang is actually a proper accessibility feature :)
-
pep.
Maybe someday we'll stop dismissing those
-
jonas’
"we"?
-
MSavoritias (fae,ve)
Do we actually have a way for me to hint what language i am sending?
-
jonas’
I'd like to be excluded from that particular "we"
-
MSavoritias (fae,ve)
In the message
-
jonas’
MSavoritias (fae,ve), yes, xml:lang on your stream is by default transferred down to the <body/> of your message, unless your client overrides it for the stanza or the body.
-
Zash
This is also a privacy leak! Such fun!
-
MSavoritias (fae,ve)
Why? Cant you set it always to english?
-
jonas’
you can, but what's the point then :)
-
MSavoritias (fae,ve)
Then its not a leak ;)
-
jonas’
(and also breaks accessibility)
-
MSavoritias (fae,ve)
For the privacy nuts
-
jonas’
sure
-
jonas’
well, ideally, you'd set it to whatever (klingon or so) on the stream, and then explicitly for each message/body
-
jonas’
privacy-wise
-
pep.
jonas’: individually maybe, but as a community I think we largely fail
-
MSavoritias (fae,ve)
Sounds cool though. More clients should hins like that imo✎ -
jonas’
MSavoritias (fae,ve), you can even have multiple <body/> elements with different xml:lang to send translations of your message!
-
MSavoritias (fae,ve)
Sounds cool though. More clients should hint like that imo and have a settinp for it ✏
-
jonas’
and then clients can pick based on local preference what to display
-
MSavoritias (fae,ve)
😱 where is this stuff? It sounds cooler than stickers almost
-
jonas’
MSavoritias (fae,ve), aioxmpp has a complete implementation of that, it's in RFC 6120✎ -
jonas’
MSavoritias (fae,ve), aioxmpp has a complete implementation of that, it's in RFC 6120 ✏
-
jonas’
or RFC 6122 maybe✎ -
jonas’
or RFC 6121 maybe ✏
-
jonas’
(plus the corresponding dependencies)
-
jonas’
(such as the xml:lang inheritance rules in XML 1.0)
-
MSavoritias (fae,ve)
Heh. Lots of rfcs to cover
-
jonas’
indeed
-
jonas’
flipside: you can have multiple <body/> elements which say completely different things in different languages
-
jonas’
<body xml:lang="en">We want peace!</body><body xml:lang="de">Hafen um 9 angreifen!</body>
-
jonas’
nice covert channel.
-
Zash
Same with xhtml-im
-
Zash
same with email and multipart messages
-
jonas’
indeed
-
jonas’
and OMEMO, in fact :)
-
jonas’
instead of <body>YoUR ClIENt DoeS NOt SUpPOrT OMEmO</body>, you could also send something completely different <3
-
pep.
Yeah, in fact most OMEMO messages already have covert messages!!
-
jonas’
but this being one of those things where you have to trade absolute security and solving social issues with technical means vs. nice things, I'm ok with err-ing on the side of nice things
-
Zash
OTR in the <body> of OMEMO messages?
-
jonas’
Zash, door's there, hush, out
-
Zash
FINE
-
jonas’
most cursed message
-
jonas’
Zash, and then add an OX element, for good measure!
-
pep.
jonas’, yeah, that's also a trade-off I'm happy to make if it means including more people in
-
Zash
YESSsS
- Zash continues eating popcorn
-
pep.
For some reason I don't get, some people are completly imune to this
-
jonas’
I'm beyond the ~popcorn~ chocolated-peanut stage
-
jonas’
pep., immune to what?
-
jonas’
popcorn?
-
pep.
hah
-
pep.
To understanding that they're solution to these "Security issues" are to shut some of our users out✎ -
pep.
To understanding that their solution to these "Security issues" are to shut some of our users out ✏
-
MSavoritias (fae,ve)
Balance and all that
-
jonas’
it's ~turtles~ trade-offs all the way down
-
MSavoritias (fae,ve)
Question though: what is bad with 394?
-
pep.
Yeah, except when that balance affects more than just you, but also every other client around you
-
MSavoritias (fae,ve)
Xep 394
-
jonas’
MSavoritias (fae,ve), it's a solution to a problem which shouldn't exist in the first place
-
jonas’
it introduces all kinds of nuances, and we should just go back to properly sanitized XHTML-IM
-
jonas’
with nice test vectors
-
MSavoritias (fae,ve)
Heh you are one of *these* people /s
-
Zash
server-injected exploits in every message you mean
-
pep.
Testing suites could actually be a useful addition to the XSF's roles.
-
jonas’
MSavoritias (fae,ve), *these*?
-
jonas’
pep., *subtly points at '392*
-
MSavoritias (fae,ve)
That want xhtml :P
-
jonas’
MSavoritias (fae,ve), yeah sure
-
jonas’
nothing else makes sense
-
jonas’
it's semantic, it's well-established, it's well-documented, it embeds perfectly in XMPP, which is already XML-based
-
jonas’
all other formats also come with their own non-trivial injection security issues.
-
jonas’
we should "just" solve that by providing test vectors which implementations need to pass for security checks
-
jonas’
'394 is a huge overly complex mess, '392 is a huge underly complex mess
-
Zash
the mess is constant, you can only move it around
-
jonas’
(note who is the author of '394 ...)
-
jonas’
s/'392/'393/ obviously, '392 is the best™
-
pep.
jonas’, yeah 392, but again, that's not "The XSF", that's just you :)
-
pep.
Council could enforce this on accepting specs
-
jonas’
oh, I'm not listed as author of '394 anymore
-
pep.
I think you removed yourself
-
jonas’
yeah
-
MSavoritias (fae,ve)
Yeah. Accesibility, privacu and tests
-
jonas’
MSavoritias (fae,ve), then maybe for context, I wrote the initial version of '394 before I realized that it's not a good way forward
-
MSavoritias (fae,ve)
Yeah. Its not a good idea sending stuff out of band imo
-
MSavoritias (fae,ve)
The text should be structured itself
-
jonas’
ack
-
MSavoritias (fae,ve)
Like markdown or xhtml
-
jonas’
markdown is not structuring of the text itself
-
jonas’
(like '393 is not)
-
jonas’
there is no clear separation of text and content✎ -
jonas’
there is no clear separation of text and structure ✏
-
jonas’
but I'm not going down *that* rabbithole tonight
-
MSavoritias (fae,ve)
In the sense that the text tells you how to. 394 Seems like it adds it in the metadata
-
MSavoritias (fae,ve)
Which is an odd place
-
jonas’
pep. can explain all that to you
-
pep.
jonas’, yeah we've been going over it again in other channels..
-
pep.
For the past few days
-
MSavoritias (fae,ve)
:)
-
jonas’
good thing I was too distracted to pay attention
-
jonas’
I guess I'll distract myself for anothe few days until this storm blows over again
-
pep.
You're not in there!
-
pep.
Someday it'll be big enough for someone(tm) to resubmit it, and then it'll be chaos again for some time
-
pep.
I'm tring to gather some thoughts around why conveying intent is important (and actually the whole point of the protocol to me)✎ -
pep.
I'm tring to gather some thoughts around why conveying intent is important (and actually the whole point of a protocol to me) ✏