XSF Discussion - 2017-11-10

Any webrtc aficionado here?

o/

\o

possibly in the future

I'm still waiting for clients that are proposing native WebRTC + native Jingle to do tests with Movim :)

(I'm a noob, my terminiology might be off): I'm looking for information on the SSLTCP ICE canidate. As far as I understand, it "mimics" a SSL/TLS handshake to fool some firewalls into accepting traffic, without doing actual SSL/TLS encryption (thus not fooling proper firewalls).

my questions: a) exactly what version of the clienthello (I think?) is mimiced? b) There appears to be something called TURNS which does full TLS that allows passage through proper filewalls (with the overhead of encryption). This is pretty hard to find via google - where's that documented?

</questions>

Guus, https://tools.ietf.org/html/rfc5766

that mentions "turns"

(including the quotes)

so maybe "TURN over TLS" is a good search term

(that term at least works for me with google, but my google is well-trained on RFCs etc.)

tx

a quick google suggests that ssltcp is propretary

*proprietary

so aside from reverse engineering google hangouts, it could be tricky to find out how it works

ah, Microsoft does document something similar, it appears. They're clalling that MS-TURN: http://interoperability.blob.core.windows.net/files/MS-TURN/[MS-TURN].pdf

"Pseudo-TLS over TCP"

so, yeah, the SSLTCP ICE pseudo clienthello is a SSL v2.0 clienthello with a specific challenge (yey for wireshark)

sslv2, amusing. but I wouldn’t be surprised if the kind of firewalls fooled by that would also be the kind of firewalls not giving a lot about actual transport security :-)

exactly what I was thinking. It also answers my question on why the multiplexer I was using didn't seem to pick it up with the default "TLS" probe :)

Guus: also stun and turn alpn IDs here https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids

still no our ALPNs in the list

xmpp-server and xmpp-client

zinid: supposedly iana approved and they will be there next update

I want to guess and say that was a month ago

daniel: the wording is a bit confusing, I'll have to think about how that whole section can be rewritten later, but here's a patch for the issue you mentioned: https://github.com/xsf/xeps/pull/539

SamWhited, yes. wording this is the only downside of this otherwise useful change... I think you did a good job though.

It may be better to rewrite that chunk as a list of rules in the order you should apply them when parsing

should probably contain a few 'negative' examples as well. like `*foo *bar` (indicate that this wont be styled)

but we can finish the XEP first before we add more examples

Good call, I should add some for this rule to that list (there is a list of things that aren't styled)

(added that one)

Conversations Master has already been updated to reflect that change by the way. That's going to be shipped with one of the bug fix releases that always follow my minor releases

Will be interesting to see where the broader 'leave keywords in' discussion leads

I still don't have the regular release for whatever reason

If people really end up hating the keywords we will have to think about and opt in annotations or what ever

Yah, I'll be curious about that. I still think it's an implementation detail and is up to individual clients/services, which is why I only made it a SHOULD after we upgraded it from MAY

I just promoted from beta to stable an hour ago

Guess you are not on the beta channel

oh, I thought it was already out, nevermind then

yah, I think the beta group didn't like my Google Apps account or something? I can't remember

> oh, I thought it was already out, nevermind then So did I 😀

hah, that explains it

has that / _ italics vs underline discussion come to an end?

the problem with opt-in (client sending 'this is styled') is how would a client know I meant *bold*, that's sorta the whole point

Guus: I'm not sure. I didn't hear any compelling reason to change it other than one or two XMPP clients were doing / aleady, so I didn't, but if it's what the community wants I'm happy to do so.

Guus, never

But I felt that didn't outweigh the fact that most other messengers seemed to be doing _ already and that _ has meant italics since the days of typewriters

I was discussing it with some frontend-oriented colleagues. They basically said: "Both underlining and italic are used to express emphasis. Never allow underlining for anything else than hyperlinks. Underlining has it's origin with typewriters, that (mechanically) didn't have skewed letters."

oh yah, I think you mentioned that; that seems like a good enough reason not to add underlines and to keep _ for italics to me.

is it an idea to simply define both as "emphasis" and let the client use whatever they prefer?

I defined it that way originally, where actually doing italics was a MAY; it's a SHOULD now, but I could be persauaded to go back.

so do you support /this/ for italics too?

I just thought it made more sense to strive for consistency.

I personally prefer _ for italics - but most historical usage implies underline.

I'm not actually sure where that comes from

There is of course nothing stopping clients from also supporting /this/, it just won't be as consistent

The typewriter historical usage implies italics, just not until you actually go to typeset it… maybe we should have a timer and it should randomly change into italics!

does the XEP say both or not though

The XEP doesn't mention /

I don't know the answer as to whether it should or not

I also thought it was likely that / would collide with paths

using / for markup is annoying, if your text has URLs (the stuff that ironically, requires an underline in rendering...)

/this/is/a/path/ would be italisized under the current rules

or "this" and "a" would anyways

URLs wouldn't

just "this", rather.

a folder file path would and a file path would not

meh, perhaps it's best to just go with something and stop discussing :)

at least for me that falls under who cares territory

It seems like there is a slight upside to using _ over /, so unless someone *really* comes up with a compelling reason I'll probably leave it as is

Although, at this point I'm not even sure if this will be accepted so ¯\_(ツ)_/¯

I have nothing compelling :) just that I've always done /italics/ and gajim does it too

it doesn't matter

yah, I like /italics/ pretty well too

yeah, hence my suggestion to define _ as well as / as 'emphasis' and throw consistency out of the window.

not sure if it's a fair tradeoff though

It doesn't seem worth it to me

what's 'emphasis' ? bold or italics?

emphasis is typically expresses with underline or italics

... but your quesion alone proves that it's a bad idea :)

I call it "bold" and "italics" right now in the protoxep, but they're both a SHOULD. Maybe I should merge those sections and say that they're different types of "emphasis", someone asked for it and I said I would, I just didn't want to make the change unless it was accepted (although now I've already done more work, might as well do a bit more)

to me, obviously, 'emphasis' is unclear so I'd say bold/italics etc

if the only argument is 'accessible' clients well they have to decide the difference anyway so

there isn't a XEP police going you translated that to voice wrong

/this/is/a/path/ would emphasize the whole thing

Because the inner / will be ignored

paths are important, they need emphasis.

With the PR SamWhited just made

Not with the published rules

but I think /this/is/a/path/to/a/file would not emphasize anything right?

because only folders are important, not files

moparisthebest: yes

:)

so directories are more important than files.

yep

daniel: I don't think the change I made affects that one will it?

oh you are right

it will emphasize /this/

with both the old and the new rules

still not cool though. and a reason not to use / as a keyword

what if my OS uses _ as a path seperator, then I'm back to the same problem

all of these messenger silently changes my send text is a problem I've always had in every client

I wish they followed these rules where at least the characters were left in

that fixes everything, so in my opinion what actually gets bolded/etc doesn't really matter

try pasting code in 'lync' or 'skype for business' for example, it's a nightmare

whatsapp nicely fades the keywords a little, but keeps them in place

perfect imho

SamWhited: what about nested formatting? formatting in code blocks is likely unwanted, but what about in quotations?

Guus: It's allowed by the spec

"Block quotes may contain any child block, including other quotations"

I misread that as "may contain other quotations"

I probably also need to define the block/span thing better

You're not mentioning hyperlinks - but I'd expect that most clients that do styling, would also make those clickable (and give them corresponding style). Maybe mention that?

I thought about it, but I didn't want to formally specify those (same with lists) because it's just something I'd expect clients to do by themselves and it's not really the same thing as the other indicators

Maybe just a quick mention to note that most clients probably will want to also auto-link hyperlinks

SamWhited: links shouldn't be rendered in preformatted blocks though.

and that lists were left off because users can type "1." easily enough

I'd not mention lists at all, I think.

I don't know if it matters if lists are rendered in preformatted blocks or not, but that does seem worth mentioning one way or another.

Even if it's just to say "clients may want to consider this and whether they want it or not"

Thanks!

... I'm wondering if the adoption rate of the XEP would be significantly higher if you'd forget about blocks completely, and do spans only.

(that's an elaborate way to admit that I'm a lazy client dev)

I wouldn't be against that, although I think the blocks aren't very difficult to implement either. Did you run into any trouble while playing with it?

SamWhited: not 'trouble', but it does require me to rewrite parts of the displaying code. Things are easier when I only need to concern myself with single lines.

I quite dislike implementing stuff that has all kind of exceptional cases "if then do that except for when this is that"

the spans are already complex. Having to think of nesting spans or blocks in other blocks - meh, I'd rather fix another bug. :)

as I said, lazy.

also, preformatted blocks add little value for me, personally (I can see how they could be useful, but I'd much rather have people use a service like pastebin, isntead of cluttering up my MUC)

blockquotes could be useful to an extend, but the XEP would be interesting in itself without it.

also: people in open_chat now are experimenting with cowsay in the muc.

I thought about making that an easter egg in my little client… if you did ```cowsay it would pipe it through that first and then display

shouldn't block text be mono-spaced?

That was the idea

I don't think it mentions that explicitly

oops, thanks, I'll add that to my todo as well

It mentions it in one of the examples!

> This should show up as monospace, preformatted text ⤴

Probably need some normative language there

is this valued: ``` hello ```

also, lines with ``` could easily by accident end with some random whitespace - might be good to explicitly allow for that?

hmm, no, I just didn't expand that section as much as I thought I did

It should only be the sequence "```\n" at the beginning of a line followed by "\n```"

I think; I'm not sure how likely accidental use of it would be without that

```<space>\n

why the space?

because people copy/paste stuff sloppy?

maybe it should just be any line starting with ``` and anything after it is ignored, then people can shove syntax highlighting hints in there like github does

I've had hell with the import of DER certs, because of a trailing space somewhere. It might be good to be somewhat lenient.

yah, makes sense

(then again, I'm leaning towards dropping all of this weird complexity by dropping blocks from the xep completely)

two xeps? Styled spans, Styles blocks?

well, I'm going to pour myself a drink and call it a night :)

will lurk on mobile

g'dnight!

I suppose they don't all have to be a must; if the ``` blocks don't provide value for you, it's not like they'll look terrible if someone else sends you one and your client doesn't style it

Can we have a language identifier right after the initial ``` ?

I don't think I'd want to call it a language identifier specifically, but maybe just say that the start of preformatted blocks is any line that matches ```.*\n and then clients that want to could assume it was a language thing

SamWhited: call it a syntax hint, then it's sufficiently free form

it rages on

Arc: It's all part of my secret plan to not be re-elected next term.

We'll punish you by reelecting you anyways.

its true.

idk tho, 5 people must be elected to council.

you're easily one of the most qualified

heh, thanks… drat though, I guess I'll have to think up more controversial proposals to create right before the election

I don't *think*, although I might misremember, that all the slots have to be filled.