XSF Discussion - 2018-12-08

Hello!

jonas’, are you Jonas Schäfer?

Is it possible to adopt a deferred XEP?

Yes.

Which one?

ralphm, right now I'm about XEP-0394: Message Markup

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.

ralphm, and author said that he have no time to improve it.

Yeah, XHTML-IM has various security concerns, that's why it was deprecated

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.

There's been some recent discussion on it

And there are a few other suggestions

ralphm, yes. But the main question is who will keep updating the XEP. At least, to advance it back to experimental state.

https://xmpp.org/extensions/inbox/bmh.html https://xmpp.org/extensions/xep-0393.html

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.

ralphm, ok, thanx

No worries.

Yagiza: xep-0394 _sucks_

don't implement it.

oli, the idea is good.

no its not

i hate the idea

oli, why?

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.

because it forces me to use some weird "markup"

oli, it forces you? Never heard about any XEP, which FORCES someone to do something.

oli, AFAIK all the XEPs are optional.

why not use <b> <em> <i> ?

oli, what do you mean?

oli, where to use them?

why not use some basic xhtml for rich text.

the client can decide how to implement it

if you like 0394 then translate it

client translates it to xhtml

underlines as italics is weird...

oli, i can't get your point.

oli, what do you suggest?

the richtext format on the wire should be xml, like xep-0071, but much simpler

clients could implement whatsapp like markup, but translate it to xml

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.

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.

oli, so, XEP-0394 is much better in that way: text itself and its formatting MUST be separated!

maybe im confusing xeps

oli, yes. If you're about XEP-0393, it's really awful.

oli, I'm strongly against using LML in IM.

oli, also, it's too bad that XEP names are confusing.

fuck, sorry

oli, I told about it more than a year ago, but nothing's changed so far.

oli, XEP-0393 describes LML, but called "Styling" and XEP-0394 describes styling, but called "Markup"!

oli, I also was often confused because of that and often mixed them up!

ok, i will remember 0393 *bad* 0394 good

That's why I want to adopt XEP-0394, to fix those issues and make it usable, to start its implementation in my client.

which client

?

oli, yes. XEP-0393 is a bad idea itself. XEP-0394 is a good idea, but awful implementation in its current state.

oli, eyeCU.

oli, it has full implementation of XEP-0071 right now.

I'd rename for being so much like ICQ you might have a trademark issue

oli, it can even use both http(s)/ftp and cid (BOB) chemas for embedded images.

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.

I don't have a beef in it, just saying that I'd avoid a legal discussion that you're likely to lose.

I'm not taking about the client, I'm taking about its name.

Talking

ralphm, yes. You're just the first person, who ever tell that our client name may have legal issues.

Better me than a lawyer

ralphm, yes. So, you gave me an idea to register "eyeCU" and eyeCU logo as a trademark!

Good luck. I'm very curious about the outcome.

OS/2 :)

ralphm, you are from Netherlands, you talk just like you're from USA! ;-)

oli, do you fel something bad about IBM OS/2?

feel

I'm told I do sound like a Californian when speaking English.

Yagiza: I used it in the 90s with fidonet and BBS

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.

oli, me too!

i dont think there is a problem with eyeCU and ICQ.

it did remind me of CU-SeeMe

ok, but thats offtopic

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.

are there other clients that support xep-0394?

oli, I hope, no

oli, if there are, it makes its harder to improve it.

oli, the authors of those clients will try to resist serious changes.

I don't see that as a valid reason against changes while it is experimental or even deferred.

ralphm, me so

ralphm, but

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.

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.

Oddly, XEP-0363 is still in Last Call, so you might make another attempt.

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.

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.

Ge0rG, IC

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

Ge0rG, that's why I think it should be an informational XEP, not standards track.

The names are really bad. I already suggested renaming them to markright (uses >) and markleft (needs < for all styling annotations)

Funnily enough 393 is better than what some clients are implementing

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.

Same syntax stricter rules

Yagiza: I've implemented 0393 in my client. It's great.

Ge0rG, your arguments?

Indeed, 0393 is basically codifying the Slack syntax, no?

Ge0rG, besides "it's great because I like it".

You only start noticing how important the parsing rules in 393 are when you use a client that doesn't follow

> Indeed, 0393 is basically codifying the Slack syntax, no? I mix of WhatsApp and slack plus some in the wild testing

I mean WhatsApp and slack don't publish their exact rules

But it's the same general syntax

Yagiza: your suggestion is nice, but now you created an oracle that will tell the user whether a given file exists on the server

Yagiza: 0393 is in a sweet spot of easy to implement, easy to understand for users, sufficiently easy for handicapped people

Also works over transports

Ge0rG, yes. And what's wrong with it?

Ge0rG: do you think that the body markup hints spec in the inbox is a useful complement to XEP-0393?

ralphm: haven't read yet

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

Huh? Doesn't BHM just tell the other side which markup dialect was used in the body?

BMH

Yes. But I don't think anyone will ever use anything else

And then why bother having to rely on a second xep

Ge0rG, which of above cannot be applied to XEP-0394?

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.

Even then, CSS included in there is pretty simple, it's not CSS3

393 is fine as an input method, but that's about it

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

Yes, I just don't want to buy this argument, you can say that about pretty much anything

lets not use the web

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.

references?

https://xmpp.org/extensions/xep-0372.html

And see also https://xmpp.org/extensions/xep-0385.html

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.

Because it was the only place with vulnerabilities right

pep., why not just improve XEP-0394 instead of trying to rip-off CSS from XEP-0071?

It was. I think I averaged 15 minutes each, across more than a handful of clients before seeing something dumb.

Including some native clients with embedded HTML, where RCE meant full local system access.

pep., also, what's nice about LML as input method? WYSIWYG is always better for and user, than LML.

Yagiza: yeah I don't really care about the input method tbh

pep., so, then. Why improved XEP-0394 is not better than ripped XHTML-IM?

waqas: especially in MUC context, because it doesn't require direct contact and the amplification angle?

ralphm: > And see also https://xmpp.org/extensions/xep-0385.html i don't understand what it has to do with markup and references.

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

oli: XHTML-IM provides a way to include images

ok

xhtml-im includes a lot

oli: so SIMS helps achieving that in a similar way as XEP-0394 does. Also why I think they should be aligned, spec wise.

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.

Yagiza: which changes for xep0394 do you propose?

where are the problems?

waqas: disconcerting indeed

By the way, XEP-0393 and XEP-0394 could totally co-exist.

oli, add support for embedded images and hyperlinks.

oli, add normal "bold", "italic", "underscore" text decoration instead of strange "emphasis".

oli, add ability to specify font type, font size and text color.

oli, add ability to specify text alignment.

oli, add ability to remove list markers from the beginning of list item text when rendering.

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

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.

but it also get used. like in the mess we have with emails

Yagiza: if those are your suggestions, then I'd rather have you look at the References stuff I just mentioned

Also, if it were my client, I'd never implement font type, size, or color.

supporting font size and color will be messy

monospace font has some value

With backticks, sure

everything else should be semantic markup only

oli, ralphm, it depends on what you are using it for.

maybe xhtml-im is just the right way to do everything fancy

oli, yes, but it has flaws which XEP-0394 solves.

oli, so making XEP-0394 powerful enough, but without XHTML-IM flaws is a good way, I beleive.

oli: I'd see the use of monospace for literals (one backtick) and code snippets (triple backticks) as purely semantic.

Allowing users to specify font size, type, or color, just makes for a horrible mess. Like different clients/desktops having different default background colors.

We have this XHTML-IM right now, and at some time patched Gajim to ignore those styles completely.

maybe we could just encapsulate rfc822 messages

would be super fun and messy

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.

Inability to specify bold, italic and underscore in different combinations if much worse.

I don't agree with the author then, that this is useful.

have anyone thought about accessibility?

oli, what's wrong with accessibility? If contrast problem is solved, I guess no problem.

I strongly think that markup should be semantic

and i believe that xep-0393 is not very screen reader friendly

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.

oli: why not?

i have to test it

I'd say markdown-like syntaxes are actually very good for screen readers.

screen reader test: *one* _two_ `three`

»one underscore two underscore backquote three backquote«

doesn't work well with android talkback

~talkback~ select-to-read

Yagiza, yes, you can adopt a deferred XEP, but I might retract XEP-0394 in the medium future actually

jonas’, so, I can try to publish my own XEP instead of that one?

you can also adopt it if you want

I’d be fine with that, since I want to go down other routes, I think

jonas’, that's nice

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

so e.g. a span marked with strong would have to be bracketed with *

but that was just the last idea I had

jonas’, IC

jonas’, anyway, we should think about the best way to implement that all.

I think we might end up with a revamped version of '71 actually

so xep-0071 is security nightmare, xep-0393 horrible for screen readers and sexist, xep-0394 will be retracted

oli, ok, what?

what

lets just use plaintext.

sexist?

what did I miss here?

gender gap doesnt work

*professor*in*

sexist

_professor_innen_

ah, that

jonas’, ? enlighten me?

that’s going to require so much explaining

MattJ, in german, we have gender in nouns. the male version is the default.

then there’s the "in" suffix which makes it a female word

e.g. Lehrer (-> male teacher), Lehrerin (-> female teacher)

now the male default is viewed as sexist by some (many even?), and also the restriction to two versions (male and female) as problematic

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

I see

in formal language, Lehrer/In was typical (but also only represents the two versions), LehrerIn has become a shorthand of that

(I even brought that up when XEP-0393 was discussed)

Sounds like it's the German language that's sexist, not XEP-0393 :)

that’s true

But yes, it highlights the fact that the XEP assumes these symbols are just free for it to use for its own purpose

it does

i'm arguing all the time that we just change the german language, but without any succesd

oli, sounds like a plan, but in that case I’d actually like to see the "*" version; I like how globby it is :)

what do you mean?

which part of my statement is unclear to you? ✏

like to see the * version

?

fwiw this could potentially be fixed in the xep

making the non-existent grammar more complex?

but that’s not as cool as complaining about stuff

still waiting on Sams promise to deliver a formal grammar for the thing.

jonas’, one potential fix (of the two that i have in mind) would actually make things easier

although i would prefer the more complicated one. :-)

jonas’: i would eliminate the multiple grammatical genders from the german language. problem solved

okay, but what about screen readers?

oli, I like you, you repeat all the arguments I brought up a year ago :)

gives me the feeling I’m not totally outside of the norm

If I adopt XEP-0394, it won't be retracted, so calm down.

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.

for chat i'm happy with plain text. for everything else we could resurrect google wave

Ge0rG, so you want XHTML-IM :)

not the current one

but you want semantic markup

emphasis, monospace, headings

oli: I think that's a minority opinion.

better plain text than xep-0393. i'll try to disable it in conversations, later.

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?

Syndace, https://xmpp.org/extensions/xep-0396.html this maybe?

if KeyTransportElement == KeyTransportMessage

jonas’: Thanks, it is ^^

Syndace: I think the original plan was to just reuse the element somewhere as a sub element

daniel: That's how it's done in the XEP that jonas' linked, makes a lot of sense

And that would give you the context

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

Okay cool. At least gives me a good hint on how to add KTMs to my lib...

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.

you must retain the markers when you make up markup out of thin air

if we just had an out-of-band way to signal that the markers really are intended for markup....

If only

I by the way have a work around for the _programmier_innen_ problem that probably shouldn't cause side effects

Will test this for a while

https://share.gultsch.de/daniel/1YQ0Fftaz84JZmZY/6h4kux4-TpOxZZMXs-4-MQ.jpg

Coming up with the parsing rules Was a process. It doesn't mean it has to end there. It can still be modified

That's what experimental xeps are for

done. i just disabled ImStyleParser. now i can write underlines without the italics. make the _usenet_ great again.

jonas’: haha

> 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

switching to propet old-school style?

https://upload.jabberhead.tk:5443/f0a454a3b03d017a262dfcfef56c2235742e325d/EweL3J5ZnfVQjrwbMfBuVaKojAwCnCtP2ZS0BG6v/0pgTCrRQSVusm4QBS9oICg.jpg

When you just want to game a little bit...

⚔️

Hope it got a good multiplayer: https://repl.it/site/blog/multi ...