Yagizaralphm, right now I'm about XEP-0394: Message Markup
Yagizaralphm, 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
Yagizaralphm, and author said that he have no time to improve it.
ralphmYeah, XHTML-IM has various security concerns, that's why it was deprecated
lskdjfhas left
Yagizaralphm, 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
ralphmThere's been some recent discussion on it
ralphmAnd there are a few other suggestions
Yagizaralphm, yes. But the main question is who will keep updating the XEP. At least, to advance it back to experimental state.
ralphmYagiza: 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.
Yagizaralphm, ok, thanx
Nekithas joined
ralphmNo worries.
danielhas left
danielhas joined
oliYagiza: xep-0394 _sucks_
danielhas left
lorddavidiiihas left
olidon't implement it.
lorddavidiiihas joined
danielhas joined
Yagizaoli, the idea is good.
olino its not
olii hate the idea
Yagizaoli, why?
Yagizaoli, I myself hate an idea of using LML in IM, but I feel ut's a good idea to allow using rich text formatting.
olibecause it forces me to use some weird "markup"
alexishas left
Yagizaoli, it forces you? Never heard about any XEP, which FORCES someone to do something.
Yagizaoli, AFAIK all the XEPs are optional.
oliwhy not use <b> <em> <i> ?
Yagizaoli, what do you mean?
Yagizaoli, where to use them?
oliwhy not use some basic xhtml for rich text.
frainzhas left
olithe client can decide how to implement it
oliif you like 0394 then translate it
oliclient translates it to xhtml
oliunderlines as italics is weird...
Yagizaoli, i can't get your point.
Yagizaoli, what do you suggest?
olithe richtext format on the wire should be xml, like xep-0071, but much simpler
oliclients could implement whatsapp like markup, but translate it to xml
Yagizaoli, 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.
ralphmoli: 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.
Yagizaoli, so, XEP-0394 is much better in that way: text itself and its formatting MUST be separated!
olimaybe im confusing xeps
labdsfhas left
Yagizaoli, yes. If you're about XEP-0393, it's really awful.
Yagizaoli, I'm strongly against using LML in IM.
Yagizaoli, also, it's too bad that XEP names are confusing.
olifuck, sorry
Yagizaoli, I told about it more than a year ago, but nothing's changed so far.
Holgerhas left
Yagizaoli, XEP-0393 describes LML, but called "Styling" and XEP-0394 describes styling, but called "Markup"!
Yagizaoli, I also was often confused because of that and often mixed them up!
Jeremyhas joined
oliok, i will remember
0393 *bad*
0394 good
YagizaThat's why I want to adopt XEP-0394, to fix those issues and make it usable, to start its implementation in my client.
oliwhich client
oli?
Yagizaoli, yes. XEP-0393 is a bad idea itself. XEP-0394 is a good idea, but awful implementation in its current state.
Yagizaoli, eyeCU.
Yagizaoli, it has full implementation of XEP-0071 right now.
ralphmI'd rename for being so much like ICQ you might have a trademark issue
Yagizaoli, it can even use both http(s)/ftp and cid (BOB) chemas for embedded images.
Yagizaralphm, 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.
ralphmI don't have a beef in it, just saying that I'd avoid a legal discussion that you're likely to lose.
ralphmI'm not taking about the client, I'm taking about its name.
ralphmTalking
labdsfhas joined
Yagizaralphm, yes. You're just the first person, who ever tell that our client name may have legal issues.
ralphmBetter me than a lawyer
Yagizaralphm, yes. So, you gave me an idea to register "eyeCU" and eyeCU logo as a trademark!
ralphmGood luck. I'm very curious about the outcome.
oliOS/2 :)
Yagizaralphm, you are from Netherlands, you talk just like you're from USA! ;-)
Yagizaoli, do you fel something bad about IBM OS/2?
Yagizafeel
ralphmI'm told I do sound like a Californian when speaking English.
oliYagiza: I used it in the 90s with fidonet and BBS
Yagizaralphm, 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.
Yagizaoli, me too!
olii dont think there is a problem with eyeCU and ICQ.
oliit did remind me of CU-SeeMe
oliok, but thats offtopic
Yagizaoli, 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.
oliare there other clients that support xep-0394?
Yagizaoli, I hope, no
Yagizaoli, if there are, it makes its harder to improve it.
Yagizaoli, the authors of those clients will try to resist serious changes.
ralphmI don't see that as a valid reason against changes while it is experimental or even deferred.
Yagizaralphm, me so
Yagizaralphm, but
alexishas joined
Yagizaralphm, 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
ralphmWell, 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.
ralphmOddly, XEP-0363 is still in Last Call, so you might make another attempt.
lumihas joined
Yagizaralphm, 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
Ge0rGSomebody 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.
YagizaGe0rG, IC
lorddavidiiihas left
Ge0rGAlso 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
YagizaGe0rG, that's why I think it should be an informational XEP, not standards track.
Ge0rGThe names are really bad. I already suggested renaming them to markright (uses >) and markleft (needs < for all styling annotations)
danielFunnily enough 393 is better than what some clients are implementing
YagizaGe0rG, 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.
danielSame syntax stricter rules
Ge0rGYagiza: I've implemented 0393 in my client. It's great.
YagizaGe0rG, your arguments?
ralphmIndeed, 0393 is basically codifying the Slack syntax, no?
YagizaGe0rG, besides "it's great because I like it".
danielYou 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
danielI mean WhatsApp and slack don't publish their exact rules
danielBut it's the same general syntax
Ge0rGYagiza: your suggestion is nice, but now you created an oracle that will tell the user whether a given file exists on the server
Ge0rGYagiza: 0393 is in a sweet spot of easy to implement, easy to understand for users, sufficiently easy for handicapped people
Ge0rGAlso works over transports
YagizaGe0rG, yes. And what's wrong with it?
alexishas joined
ralphmGe0rG: do you think that the body markup hints spec in the inbox is a useful complement to XEP-0393?
Ge0rGralphm: haven't read yet
blablahas left
danielralphm: 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
ralphmHuh? Doesn't BHM just tell the other side which markup dialect was used in the body?
ralphmBMH
danielYes. But I don't think anyone will ever use anything else
danielAnd then why bother having to rely on a second xep
alexishas left
alexishas joined
404.cityhas joined
efrithas joined
frainzhas left
YagizaGe0rG, 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
ralphmpep.: 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
olilets not use the web
ralphmI 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
olireferences?
ralphmhttps://xmpp.org/extensions/xep-0372.html
ralphmAnd see also https://xmpp.org/extensions/xep-0385.html
waqasI 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
Yagizapep., why not just improve XEP-0394 instead of trying to rip-off CSS from XEP-0071?
waqasIt was. I think I averaged 15 minutes each, across more than a handful of clients before seeing something dumb.
waqasIncluding some native clients with embedded HTML, where RCE meant full local system access.
Yagizapep., 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
Yagizapep., so, then. Why improved XEP-0394 is not better than ripped XHTML-IM?
ralphmwaqas: especially in MUC context, because it doesn't require direct contact and the amplification angle?
oliralphm: > 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
ralphmoli: XHTML-IM provides a way to include images
oliok
olixhtml-im includes a lot
Holgerhas left
ralphmoli: 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
waqasNote 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.
oliYagiza: which changes for xep0394 do you propose?
oliwhere are the problems?
olihas left
olihas joined
ralphmwaqas: disconcerting indeed
pep.has left
ralphmBy the way, XEP-0393 and XEP-0394 could totally co-exist.
lnjhas joined
efrithas joined
labdsfhas joined
Yagizaoli, add support for embedded images and hyperlinks.
Yagizaoli, add normal "bold", "italic", "underscore" text decoration instead of strange "emphasis".
Yagizaoli, add ability to specify font type, font size and text color.
Yagizaoli, add ability to specify text alignment.
Yagizaoli, add ability to remove list markers from the beginning of list item text when rendering.
Ge0rGYagiza [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
YagizaGe0rG, 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.
olibut it also get used. like in the mess we have with emails
ralphmYagiza: if those are your suggestions, then I'd rather have you look at the References stuff I just mentioned
ralphmAlso, if it were my client, I'd never implement font type, size, or color.
olisupporting font size and color will be messy
Nekithas left
Nekithas joined
olimonospace font has some value
ralphmWith backticks, sure
olieverything else should be semantic markup only
Yagizaoli, ralphm, it depends on what you are using it for.
olimaybe xhtml-im is just the right way to do everything fancy
Yagizaoli, yes, but it has flaws which XEP-0394 solves.
Yagizaoli, so making XEP-0394 powerful enough, but without XHTML-IM flaws is a good way, I beleive.
ralphmoli: I'd see the use of monospace for literals (one backtick) and code snippets (triple backticks) as purely semantic.
ralphmAllowing users to specify font size, type, or color, just makes for a horrible mess. Like different clients/desktops having different default background colors.
ralphmWe have this XHTML-IM right now, and at some time patched Gajim to ignore those styles completely.
olimaybe we could just encapsulate rfc822 messages
oliwould be super fun and messy
Yagizaralphm, 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.
YagizaInability to specify bold, italic and underscore in different combinations if much worse.
ralphmI don't agree with the author then, that this is useful.
olihave anyone thought about accessibility?
Yagizaoli, what's wrong with accessibility? If contrast problem is solved, I guess no problem.
ralphmI strongly think that markup should be semantic
oliand i believe that xep-0393 is not very screen reader friendly
ralphmE.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.
ralphmoli: why not?
olii have to test it
ralphmI'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
oliscreen reader test: *one* _two_ `three`
alexishas left
alexishas joined
oli»one underscore two underscore backquote three backquote«
olidoesn'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
Yagizajonas’, 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
Yagizajonas’, 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
Yagizajonas’, IC
Yagizajonas’, 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
oliso xep-0071 is security nightmare, xep-0393 horrible for screen readers and sexist, xep-0394 will be retracted
MattJoli, ok, what?
jonas’what
olilets just use plaintext.
jonas’sexist?
jonas’what did I miss here?
oligender gap doesnt work
oli*professor*in*
olisexist
Marandahas joined
oli_professor_innen_
jonas’ah, that
MattJjonas’, ? enlighten me?
danielthat’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
MattJI 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)
MattJSounds like it's the German language that's sexist, not XEP-0393 :)
jonas’that’s true
MattJBut 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
olii'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 :)
oliwhat do you mean?
jonas’which part of my statement is unclear to yu?
jonas’which part of my statement is unclear to you?
olilike to see the * version
oli?
danielfwiw this could potentially be fixed in the xep
jonas’making the non-existent grammar more complex?
danielbut that’s not as cool as complaining about stuff
jonas’still waiting on Sams promise to deliver a formal grammar for the thing.
danieljonas’, one potential fix (of the two that i have in mind) would actually make things easier
danielalthough i would prefer the more complicated one. :-)
olijonas’: i would eliminate the multiple grammatical genders from the german language. problem solved
oliokay, 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
YagizaIf I adopt XEP-0394, it won't be retracted, so calm down.
lnjhas left
Yagizahas left
Marandahas left
alexdehas joined
Ge0rGMaybe 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
olifor 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
ralphmoli: I think that's a minority opinion.
alexishas left
alexishas joined
olibetter plain text than xep-0393. i'll try to disable it in conversations, later.
lorddavidiiihas joined
alexishas left
alexishas joined
rionhas left
danielhas left
SyndaceCouple 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?
danielSyndace: I think the original plan was to just reuse the element somewhere as a sub element
Syndacedaniel: That's how it's done in the XEP that jonas' linked, makes a lot of sense
danielAnd that would give you the context
danielYes 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
SyndaceOkay 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
ralphmoli: 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
danielI by the way have a work around for the _programmier_innen_ problem that probably shouldn't cause side effects
danielComing up with the parsing rules Was a process. It doesn't mean it has to end there. It can still be modified
danielThat's what experimental xeps are for
lorddavidiiihas left
genofirehas left
rionhas left
rionhas joined
olihas joined
olihas joined
UsLhas joined
pep.has joined
olidone. i just disabled ImStyleParser. now i can write underlines without the italics. make the _usenet_ great again.
vanitasvitaehas left
ralphmjonas’: 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