ralphm, right now I'm about XEP-0394: Message Markup
Yagiza
ralphm, I want to implement something like it in my client as an alternative to deprecated XEP-0071, but in it current state it is almost useless, so I don't want. And it seems, no one wants.
lskdjfhas joined
Yagiza
ralphm, and author said that he have no time to improve it.
ralphm
Yeah, XHTML-IM has various security concerns, that's why it was deprecated
lskdjfhas left
Yagiza
ralphm, the idea of the XEP is good, but it's current implementation is awful. We need to add more features and remove unneeded restrictions to make it a usable alternative to XEP-0071.
lskdjfhas joined
ralphm
There's been some recent discussion on it
ralphm
And there are a few other suggestions
Yagiza
ralphm, yes. But the main question is who will keep updating the XEP. At least, to advance it back to experimental state.
Yagiza: sure. I'd send an email to standards@xmpp.org about your suggestions for modification. Then either Jonas will ask for a pull request or more discussion ensues.
Yagiza
ralphm, ok, thanx
Nekithas joined
ralphm
No worries.
danielhas left
danielhas joined
oli
Yagiza: xep-0394 _sucks_
danielhas left
lorddavidiiihas left
oli
don't implement it.
lorddavidiiihas joined
danielhas joined
Yagiza
oli, the idea is good.
oli
no its not
oli
i hate the idea
Yagiza
oli, why?
Yagiza
oli, I myself hate an idea of using LML in IM, but I feel ut's a good idea to allow using rich text formatting.
oli
because it forces me to use some weird "markup"
alexishas left
Yagiza
oli, it forces you? Never heard about any XEP, which FORCES someone to do something.
Yagiza
oli, AFAIK all the XEPs are optional.
oli
why not use <b> <em> <i> ?
Yagiza
oli, what do you mean?
Yagiza
oli, where to use them?
oli
why not use some basic xhtml for rich text.
frainzhas left
oli
the client can decide how to implement it
oli
if you like 0394 then translate it
oli
client translates it to xhtml
oli
underlines as italics is weird...
Yagiza
oli, i can't get your point.
Yagiza
oli, what do you suggest?
oli
the richtext format on the wire should be xml, like xep-0071, but much simpler
oli
clients could implement whatsapp like markup, but translate it to xml
Yagiza
oli, using the way it described in XEP-0071 have nasty problem: formatted and unformatted texts are separated. So, it's possible to send absolutely different content to those, who's software supports XEP and for those, who's software do not. Also, it will make problem with P2P encryption XEPs.
ralphm
oli: the primary objection to having something syntactically a subset of (X)HTML is that people just throw at their closest HTML rendering engine, without checking.
Yagiza
oli, so, XEP-0394 is much better in that way: text itself and its formatting MUST be separated!
oli
maybe im confusing xeps
labdsfhas left
Yagiza
oli, yes. If you're about XEP-0393, it's really awful.
Yagiza
oli, I'm strongly against using LML in IM.
Yagiza
oli, also, it's too bad that XEP names are confusing.
oli
fuck, sorry
Yagiza
oli, I told about it more than a year ago, but nothing's changed so far.
Holgerhas left
Yagiza
oli, XEP-0393 describes LML, but called "Styling" and XEP-0394 describes styling, but called "Markup"!
Yagiza
oli, I also was often confused because of that and often mixed them up!
Jeremyhas joined
oli
ok, i will remember
0393 *bad*
0394 good
Yagiza
That's why I want to adopt XEP-0394, to fix those issues and make it usable, to start its implementation in my client.
oli
which client
oli
?
Yagiza
oli, yes. XEP-0393 is a bad idea itself. XEP-0394 is a good idea, but awful implementation in its current state.
Yagiza
oli, eyeCU.
Yagiza
oli, it has full implementation of XEP-0071 right now.
ralphm
I'd rename for being so much like ICQ you might have a trademark issue
Yagiza
oli, it can even use both http(s)/ftp and cid (BOB) chemas for embedded images.
Yagiza
ralphm, i don't think so. eyeCU called that way because it's geoloc-oriented. It has built-in online map engine, so you can see your contacts on the map.
ralphm
I don't have a beef in it, just saying that I'd avoid a legal discussion that you're likely to lose.
ralphm
I'm not taking about the client, I'm taking about its name.
ralphm
Talking
labdsfhas joined
Yagiza
ralphm, yes. You're just the first person, who ever tell that our client name may have legal issues.
ralphm
Better me than a lawyer
Yagiza
ralphm, yes. So, you gave me an idea to register "eyeCU" and eyeCU logo as a trademark!
ralphm
Good luck. I'm very curious about the outcome.
oli
OS/2 :)
Yagiza
ralphm, you are from Netherlands, you talk just like you're from USA! ;-)
Yagiza
oli, do you fel something bad about IBM OS/2?
Yagiza
feel
ralphm
I'm told I do sound like a Californian when speaking English.
oli
Yagiza: I used it in the 90s with fidonet and BBS
Yagiza
ralphm, yes, but that's not an idea. A character of a popular Russian sitcom said once: "USA is a country of lawyers and criminals!". The idea is that because of lawyers in USA anyone may suddenly find himself a criminal.
Yagiza
oli, me too!
oli
i dont think there is a problem with eyeCU and ICQ.
oli
it did remind me of CU-SeeMe
oli
ok, but thats offtopic
Yagiza
oli, I'm sure it's impossible in Russia, even now, when ICQ belongs to a Russian company. But I can't be sure about USA and other countries with strange laws and almighty lawyers.
oli
are there other clients that support xep-0394?
Yagiza
oli, I hope, no
Yagiza
oli, if there are, it makes its harder to improve it.
Yagiza
oli, the authors of those clients will try to resist serious changes.
ralphm
I don't see that as a valid reason against changes while it is experimental or even deferred.
Yagiza
ralphm, me so
Yagiza
ralphm, but
alexishas joined
Yagiza
ralphm, once I tried to suggest improvements for XEP-0363 here, some people started to argue against them. And the only argument was that there are existing implementations and authors will not implement my suggestions even after XEP is updated.
Holgerhas left
ralphm
Well, if they're backwards incompatible, it may require increasing the number at the end of the namespace. Whether a change gets accepted is ultimately up to the Council.
ralphm
Oddly, XEP-0363 is still in Last Call, so you might make another attempt.
lumihas joined
Yagiza
ralphm, to tell the truth, I didn't even try to post my suggestions to mailing list, 'cause they were hardly criticized by a pair of participants of this (or jdev) room.
Marandahas joined
Ge0rG
Somebody tried to make the 0363 client a full HTTP proxy and almost succeeded. The web is a huge mess for security, not only the markup but also the transport.
Yagiza
Ge0rG, IC
lorddavidiiihas left
Ge0rG
Also 0393 was supposed to document existing usage of the markup in some clients, and is sufficiently easy to implement. I'm not convinced that 0394 has a chance for wide adoption
Yagiza
Ge0rG, that's why I think it should be an informational XEP, not standards track.
Ge0rG
The names are really bad. I already suggested renaming them to markright (uses >) and markleft (needs < for all styling annotations)
daniel
Funnily enough 393 is better than what some clients are implementing
Yagiza
Ge0rG, the only idea I suggested is to send file hash when requesting a slot. So, if file is already on the server, server will reply just with URL, without upload slot.
daniel
Same syntax stricter rules
Ge0rG
Yagiza: I've implemented 0393 in my client. It's great.
Yagiza
Ge0rG, your arguments?
ralphm
Indeed, 0393 is basically codifying the Slack syntax, no?
Yagiza
Ge0rG, besides "it's great because I like it".
daniel
You only start noticing how important the parsing rules in 393 are when you use a client that doesn't follow
daniel
> Indeed, 0393 is basically codifying the Slack syntax, no?
I mix of WhatsApp and slack plus some in the wild testing
daniel
I mean WhatsApp and slack don't publish their exact rules
daniel
But it's the same general syntax
Ge0rG
Yagiza: your suggestion is nice, but now you created an oracle that will tell the user whether a given file exists on the server
Ge0rG
Yagiza: 0393 is in a sweet spot of easy to implement, easy to understand for users, sufficiently easy for handicapped people
Ge0rG
Also works over transports
Yagiza
Ge0rG, yes. And what's wrong with it?
alexishas joined
ralphm
Ge0rG: do you think that the body markup hints spec in the inbox is a useful complement to XEP-0393?
Ge0rG
ralphm: haven't read yet
blablahas left
daniel
ralphm: it feels overly generalized. That will end up like the stanza-id xep or the hints xep that is only used in one place. I'd prefer to use add a <styled xml=message styling /> hint
blablahas joined
alexishas left
alexishas joined
ralphm
Huh? Doesn't BHM just tell the other side which markup dialect was used in the body?
ralphm
BMH
daniel
Yes. But I don't think anyone will ever use anything else
daniel
And then why bother having to rely on a second xep
alexishas left
alexishas joined
404.cityhas joined
efrithas joined
frainzhas left
Yagiza
Ge0rG, which of above cannot be applied to XEP-0394?
pep.
I would just implement xhtml-im fwiw, maybe without CSS until we find a replacement. There is no good alternative for it as of today and deprecating it was a mistake.
pep.
Even then, CSS included in there is pretty simple, it's not CSS3
labdsfhas left
pep.
393 is fine as an input method, but that's about it
ralphm
pep.: the problem isn't which parts you use, it is how clients implement rendering, which is usually not checking the input and passing it to a generic HTML renderer
pep.
Yes, I just don't want to buy this argument, you can say that about pretty much anything
oli
lets not use the web
ralphm
I don't think the idea behind XEP-0394 is bad, as it provides a way to very explicitly mark up the plain text. Might be better if it was somehow combined with References.
marc_has joined
oli
references?
ralphm
https://xmpp.org/extensions/xep-0372.html
ralphm
And see also https://xmpp.org/extensions/xep-0385.html
waqas
I have very mixed feelings about xhtml-im, but the main thing I know about it is that every single client I looked at had RCE vulnerabilities.
404.cityhas left
pep.
Because it was the only place with vulnerabilities right
Yagiza
pep., why not just improve XEP-0394 instead of trying to rip-off CSS from XEP-0071?
waqas
It was. I think I averaged 15 minutes each, across more than a handful of clients before seeing something dumb.
waqas
Including some native clients with embedded HTML, where RCE meant full local system access.
Yagiza
pep., also, what's nice about LML as input method? WYSIWYG is always better for and user, than LML.
pep.
Yagiza: yeah I don't really care about the input method tbh
Yagiza
pep., so, then. Why improved XEP-0394 is not better than ripped XHTML-IM?
ralphm
waqas: especially in MUC context, because it doesn't require direct contact and the amplification angle?
oli
ralphm: > And see also https://xmpp.org/extensions/xep-0385.html
i don't understand what it has to do with markup and references.
pep.
Yagiza, Dismiss the comment about CSS. It's not that complex. If people want more stuff in security implications, let there be more stuff added. I don't think deprecating the xep altogether was the thing to do
ralphm
oli: XHTML-IM provides a way to include images
oli
ok
oli
xhtml-im includes a lot
Holgerhas left
ralphm
oli: so SIMS helps achieving that in a similar way as XEP-0394 does. Also why I think they should be aligned, spec wise.
efrithas left
waqas
Note that I'm neither for, nor against deprecation. I think it's a feature people may want. It was simply concerning how hard it was to find an implementation that was secure.
oli
Yagiza: which changes for xep0394 do you propose?
oli
where are the problems?
olihas left
olihas joined
ralphm
waqas: disconcerting indeed
pep.has left
ralphm
By the way, XEP-0393 and XEP-0394 could totally co-exist.
lnjhas joined
efrithas joined
labdsfhas joined
Yagiza
oli, add support for embedded images and hyperlinks.
Yagiza
oli, add normal "bold", "italic", "underscore" text decoration instead of strange "emphasis".
Yagiza
oli, add ability to specify font type, font size and text color.
Yagiza
oli, add ability to specify text alignment.
Yagiza
oli, add ability to remove list markers from the beginning of list item text when rendering.
Ge0rG
Yagiza [10:47]:
> oli, add ability to specify font type, font size and text color.
This will end up with clients sending 5px Comic Sans black on black, kthx
Yagiza
Ge0rG, as I said many times, any feature could be abused. We should deprecate XMPP itself, 'cause there are hundreds features in it which could be used for abuse.
oli
but it also get used. like in the mess we have with emails
ralphm
Yagiza: if those are your suggestions, then I'd rather have you look at the References stuff I just mentioned
ralphm
Also, if it were my client, I'd never implement font type, size, or color.
oli
supporting font size and color will be messy
Nekithas left
Nekithas joined
oli
monospace font has some value
ralphm
With backticks, sure
oli
everything else should be semantic markup only
Yagiza
oli, ralphm, it depends on what you are using it for.
oli
maybe xhtml-im is just the right way to do everything fancy
Yagiza
oli, yes, but it has flaws which XEP-0394 solves.
Yagiza
oli, so making XEP-0394 powerful enough, but without XHTML-IM flaws is a good way, I beleive.
ralphm
oli: I'd see the use of monospace for literals (one backtick) and code snippets (triple backticks) as purely semantic.
ralphm
Allowing users to specify font size, type, or color, just makes for a horrible mess. Like different clients/desktops having different default background colors.
ralphm
We have this XHTML-IM right now, and at some time patched Gajim to ignore those styles completely.
oli
maybe we could just encapsulate rfc822 messages
oli
would be super fun and messy
Yagiza
ralphm, author of XEP-0394 thinks about specifying not text color but only its hue and saturation. To allow client always make text contrast. So, that's not really a problem.
Yagiza
Inability to specify bold, italic and underscore in different combinations if much worse.
ralphm
I don't agree with the author then, that this is useful.
oli
have anyone thought about accessibility?
Yagiza
oli, what's wrong with accessibility? If contrast problem is solved, I guess no problem.
ralphm
I strongly think that markup should be semantic
oli
and i believe that xep-0393 is not very screen reader friendly
ralphm
E.g. while monospace for literals is nice, it doesn't work if you are in a terminal. Then you need some other way of rendering that differently. E.g. by setting a different background.
ralphm
oli: why not?
oli
i have to test it
ralphm
I'd say markdown-like syntaxes are actually very good for screen readers.
olihas left
olihas joined
!xsf_martinhas joined
lnjhas left
lnjhas joined
igoosehas left
igoosehas joined
oli
screen reader test: *one* _two_ `three`
alexishas left
alexishas joined
oli
»one underscore two underscore backquote three backquote«
oli
doesn't work well with android talkback
oli
~talkback~ select-to-read
jonas’
Yagiza, yes, you can adopt a deferred XEP, but I might retract XEP-0394 in the medium future actually
Yagiza
jonas’, so, I can try to publish my own XEP instead of that one?
jonas’
you can also adopt it if you want
jonas’
I’d be fine with that, since I want to go down other routes, I think
Yagiza
jonas’, that's nice
jonas’
Yagiza, my original idea where to go with XEP-0394 was to enforce a specific plain-text representation of the different markup variants to have an automatic plaintext fallback
jonas’
so e.g. a span marked with strong would have to be bracketed with *
jonas’
but that was just the last idea I had
Yagiza
jonas’, IC
Yagiza
jonas’, anyway, we should think about the best way to implement that all.
jonas’
I think we might end up with a revamped version of '71 actually
oli
so xep-0071 is security nightmare, xep-0393 horrible for screen readers and sexist, xep-0394 will be retracted
MattJ
oli, ok, what?
jonas’
what
oli
lets just use plaintext.
jonas’
sexist?
jonas’
what did I miss here?
oli
gender gap doesnt work
oli
*professor*in*
oli
sexist
Marandahas joined
oli
_professor_innen_
jonas’
ah, that
MattJ
jonas’, ? enlighten me?
daniel
that’s going to require so much explaining
jonas’
MattJ, in german, we have gender in nouns. the male version is the default.
jonas’
then there’s the "in" suffix which makes it a female word
jonas’
e.g. Lehrer (-> male teacher), Lehrerin (-> female teacher)
efrithas left
jonas’
now the male default is viewed as sexist by some (many even?), and also the restriction to two versions (male and female) as problematic
jonas’
so some constructs such as Lehrer*In (kind of a wildcard thing) or Lehrer_In (symbolising the gap in the language to support all the cases) have been invented
MattJ
I see
jonas’
in formal language, Lehrer/In was typical (but also only represents the two versions), LehrerIn has become a shorthand of that
jonas’
(I even brought that up when XEP-0393 was discussed)
MattJ
Sounds like it's the German language that's sexist, not XEP-0393 :)
jonas’
that’s true
MattJ
But yes, it highlights the fact that the XEP assumes these symbols are just free for it to use for its own purpose
jonas’
it does
oli
i'm arguing all the time that we just change the german language, but without any succesd
jonas’
oli, sounds like a plan, but in that case I’d actually like to see the "*" version; I like how globby it is :)
still waiting on Sams promise to deliver a formal grammar for the thing.
daniel
jonas’, one potential fix (of the two that i have in mind) would actually make things easier
daniel
although i would prefer the more complicated one. :-)
oli
jonas’: i would eliminate the multiple grammatical genders from the german language. problem solved
oli
okay, but what about screen readers?
jonas’
oli, I like you, you repeat all the arguments I brought up a year ago :)
jonas’
gives me the feeling I’m not totally outside of the norm
marchas left
!xsf_martinhas left
doshas left
doshas left
doshas left
doshas left
Marandahas joined
Marandahas joined
Yagiza
If I adopt XEP-0394, it won't be retracted, so calm down.
lnjhas left
Yagizahas left
Marandahas left
alexdehas joined
Ge0rG
Maybe XHTML-IM is just the wrong way to do anything. I don't want somebody else to be dictating how the text *I* shall read will look. I'm okay with the sender define monospace vs normal, and _maybe_ color hints from a predefined high contrast palette and _maybe_ relative font sizes for pasting headings.
tuxhas left
Marandahas joined
alexishas left
alexishas joined
oli
for chat i'm happy with plain text. for everything else we could resurrect google wave
jonas’
Ge0rG, so you want XHTML-IM :)
jonas’
not the current one
jonas’
but you want semantic markup
jonas’
emphasis, monospace, headings
goffihas joined
ralphm
oli: I think that's a minority opinion.
alexishas left
alexishas joined
oli
better plain text than xep-0393. i'll try to disable it in conversations, later.
lorddavidiiihas joined
alexishas left
alexishas joined
rionhas left
danielhas left
Syndace
Couple of OMEMO questions:
OMEMO defines KeyTransportMessages to be used to encrypt out-of-band non-message data like pictures or files or whatever you want. In reality these KTMs have become a tool to do manual ratchet forwarding/silent session creation in case a session is broken. So my question is: if you ever wanted to use KTMs for actual data, how would you even know, which KTM is for your photos, which one is for that pdf someone sent you and which one is just a ratchet forwarder? Is there any identification mechanism? If not, should we add one? And are there any XEPs using the KTM mechanism?
UsLhas joined
UsLhas joined
jonas’
Syndace, https://xmpp.org/extensions/xep-0396.html this maybe?
jonas’
if KeyTransportElement == KeyTransportMessage
alexishas left
danielhas left
alexishas joined
Syndace
jonas’: Thanks, it is ^^
daniel
Syndace: I think the original plan was to just reuse the element somewhere as a sub element
Syndace
daniel: That's how it's done in the XEP that jonas' linked, makes a lot of sense
daniel
And that would give you the context
daniel
Yes I don't like that xep for various reasons. But it is a good demonstration on how it was originally intended to be used
genofirehas left
danielhas left
Syndace
Okay cool. At least gives me a good hint on how to add KTMs to my lib...
danielhas left
alexishas left
alexishas joined
danielhas left
pep.has joined
ralphm
oli: I don't understand. People _already_ type markup like this, and I like that Conversations takes those hints. I don't really like that it retains the markers, though. Other messaging systems don't, when they interpret the plain text.
alexishas left
alexishas joined
jonas’
you must retain the markers when you make up markup out of thin air
jonas’
if we just had an out-of-band way to signal that the markers really are intended for markup....
pep.
If only
danielhas left
daniel
I by the way have a work around for the _programmier_innen_ problem that probably shouldn't cause side effects
Coming up with the parsing rules Was a process. It doesn't mean it has to end there. It can still be modified
daniel
That's what experimental xeps are for
lorddavidiiihas left
genofirehas left
rionhas left
rionhas joined
olihas joined
olihas joined
UsLhas joined
pep.has joined
oli
done. i just disabled ImStyleParser. now i can write underlines without the italics. make the _usenet_ great again.
vanitasvitaehas left
ralphm
jonas’: haha
marc_has left
!xsf_martinhas joined
alexishas left
alexishas joined
vanitasvitaehas left
vanitasvitaehas joined
alexishas left
alexishas joined
vanitasvitaehas left
vanitasvitaehas joined
!xsf_martinhas left
olihas left
olihas joined
!xsf_martinhas joined
!xsf_martinhas left
olihas joined
olihas joined
!xsf_martinhas joined
danielhas left
vanitasvitaehas left
vanitasvitaehas joined
lorddavidiiihas joined
marchas joined
marc_has joined
danielhas left
ThibGhas left
ThibGhas joined
404.cityhas joined
404.cityhas left
ThibGhas left
ThibGhas joined
lnjhas joined
Steve Killehas joined
Kevhas joined
Kevhas joined
Steve Killehas joined
Yagizahas joined
olihas left
olihas joined
blablahas left
blablahas joined
marc_has left
alexishas joined
waqashas left
waqashas joined
ta
> done. i just disabled ImStyleParser. now i can write underlines without the italics. make the _usenet_ great again.
Actually i'd like to see that in expert preferencies