-
Guus
Any webrtc aficionado here?
-
edhelas
o/
-
marc
\o
-
jonasw
possibly in the future
-
edhelas
I'm still waiting for clients that are proposing native WebRTC + native Jingle to do tests with Movim :)
-
Guus
(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).
-
Guus
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?
-
Guus
</questions>
-
jonasw
Guus, https://tools.ietf.org/html/rfc5766
-
jonasw
that mentions "turns"
-
jonasw
(including the quotes)
-
jonasw
so maybe "TURN over TLS" is a good search term
-
jonasw
(that term at least works for me with google, but my google is well-trained on RFCs etc.)
-
Guus
tx
-
jonasw
a quick google suggests that ssltcp is propretary
-
jonasw
*proprietary
-
jonasw
so aside from reverse engineering google hangouts, it could be tricky to find out how it works
-
Guus
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
-
Guus
"Pseudo-TLS over TCP"
-
Guus
so, yeah, the SSLTCP ICE pseudo clienthello is a SSL v2.0 clienthello with a specific challenge (yey for wireshark)
-
jonasw
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 :-)
-
Guus
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 :)
-
moparisthebest
Guus: also stun and turn alpn IDs here https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids
-
zinid
still no our ALPNs in the list
-
zinid
xmpp-server and xmpp-client
-
moparisthebest
zinid: supposedly iana approved and they will be there next update
-
moparisthebest
I want to guess and say that was a month ago
-
SamWhited
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
-
daniel
SamWhited, yes. wording this is the only downside of this otherwise useful change... I think you did a good job though.
-
SamWhited
It may be better to rewrite that chunk as a list of rules in the order you should apply them when parsing
-
daniel
should probably contain a few 'negative' examples as well. like `*foo *bar` (indicate that this wont be styled)
-
daniel
but we can finish the XEP first before we add more examples
-
SamWhited
Good call, I should add some for this rule to that list (there is a list of things that aren't styled)
-
SamWhited
(added that one)
-
daniel
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
-
daniel
Will be interesting to see where the broader 'leave keywords in' discussion leads
-
SamWhited
I still don't have the regular release for whatever reason
-
daniel
If people really end up hating the keywords we will have to think about and opt in annotations or what ever
-
SamWhited
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
-
daniel
I just promoted from beta to stable an hour ago
-
daniel
Guess you are not on the beta channel
-
SamWhited
oh, I thought it was already out, nevermind then
-
SamWhited
yah, I think the beta group didn't like my Google Apps account or something? I can't remember
-
daniel
> oh, I thought it was already out, nevermind then So did I 😀
-
SamWhited
hah, that explains it
-
Guus
has that / _ italics vs underline discussion come to an end?
-
moparisthebest
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
-
SamWhited
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.
-
moparisthebest
Guus, never
-
SamWhited
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
-
Guus
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."
-
SamWhited
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.
-
Guus
is it an idea to simply define both as "emphasis" and let the client use whatever they prefer?
-
SamWhited
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.
-
moparisthebest
so do you support /this/ for italics too?
-
SamWhited
I just thought it made more sense to strive for consistency.
-
Guus
I personally prefer _ for italics - but most historical usage implies underline.
-
moparisthebest
I'm not actually sure where that comes from
-
SamWhited
There is of course nothing stopping clients from also supporting /this/, it just won't be as consistent
-
SamWhited
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!
-
moparisthebest
does the XEP say both or not though
-
SamWhited
The XEP doesn't mention /
-
moparisthebest
I don't know the answer as to whether it should or not
-
SamWhited
I also thought it was likely that / would collide with paths
-
Guus
using / for markup is annoying, if your text has URLs (the stuff that ironically, requires an underline in rendering...)
-
SamWhited
/this/is/a/path/ would be italisized under the current rules
-
SamWhited
or "this" and "a" would anyways
-
moparisthebest
URLs wouldn't
-
SamWhited
just "this", rather.
-
moparisthebest
a folder file path would and a file path would not
-
Guus
meh, perhaps it's best to just go with something and stop discussing :)
-
moparisthebest
at least for me that falls under who cares territory
-
SamWhited
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
-
SamWhited
Although, at this point I'm not even sure if this will be accepted so ¯\_(ツ)_/¯
-
moparisthebest
I have nothing compelling :) just that I've always done /italics/ and gajim does it too
-
moparisthebest
it doesn't matter
-
SamWhited
yah, I like /italics/ pretty well too
-
Guus
yeah, hence my suggestion to define _ as well as / as 'emphasis' and throw consistency out of the window.
-
Guus
not sure if it's a fair tradeoff though
-
SamWhited
It doesn't seem worth it to me
-
moparisthebest
what's 'emphasis' ? bold or italics?
-
Guus
emphasis is typically expresses with underline or italics
-
Guus
... but your quesion alone proves that it's a bad idea :)
-
SamWhited
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)
-
moparisthebest
to me, obviously, 'emphasis' is unclear so I'd say bold/italics etc
-
moparisthebest
if the only argument is 'accessible' clients well they have to decide the difference anyway so
-
moparisthebest
there isn't a XEP police going you translated that to voice wrong
-
daniel
/this/is/a/path/ would emphasize the whole thing
-
daniel
Because the inner / will be ignored
-
Ge0rG
paths are important, they need emphasis.
-
daniel
With the PR SamWhited just made
-
daniel
Not with the published rules
-
moparisthebest
but I think /this/is/a/path/to/a/file would not emphasize anything right?
-
moparisthebest
because only folders are important, not files
-
daniel
moparisthebest: yes
-
moparisthebest
:)
-
Ge0rG
so directories are more important than files.
-
moparisthebest
yep
-
SamWhited
daniel: I don't think the change I made affects that one will it?
-
daniel
oh you are right
-
daniel
it will emphasize /this/
-
daniel
with both the old and the new rules
-
daniel
still not cool though. and a reason not to use / as a keyword
-
moparisthebest
what if my OS uses _ as a path seperator, then I'm back to the same problem
-
moparisthebest
all of these messenger silently changes my send text is a problem I've always had in every client
-
moparisthebest
I wish they followed these rules where at least the characters were left in
-
moparisthebest
that fixes everything, so in my opinion what actually gets bolded/etc doesn't really matter
-
moparisthebest
try pasting code in 'lync' or 'skype for business' for example, it's a nightmare
-
Guus
whatsapp nicely fades the keywords a little, but keeps them in place
-
moparisthebest
perfect imho
-
Guus
SamWhited: what about nested formatting? formatting in code blocks is likely unwanted, but what about in quotations?
-
SamWhited
Guus: It's allowed by the spec
-
Guus
"Block quotes may contain any child block, including other quotations"
-
Guus
I misread that as "may contain other quotations"
-
SamWhited
I probably also need to define the block/span thing better
-
Guus
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?
-
SamWhited
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
-
SamWhited
Maybe just a quick mention to note that most clients probably will want to also auto-link hyperlinks
-
Guus
SamWhited: links shouldn't be rendered in preformatted blocks though.
-
SamWhited
and that lists were left off because users can type "1." easily enough
-
Guus
I'd not mention lists at all, I think.
-
SamWhited
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.
-
SamWhited
Even if it's just to say "clients may want to consider this and whether they want it or not"
-
SamWhited
Thanks!
-
Guus
... 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.
-
Guus
(that's an elaborate way to admit that I'm a lazy client dev)
-
SamWhited
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?
-
Guus
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.
-
Guus
I quite dislike implementing stuff that has all kind of exceptional cases "if then do that except for when this is that"
-
Guus
the spans are already complex. Having to think of nesting spans or blocks in other blocks - meh, I'd rather fix another bug. :)
-
Guus
as I said, lazy.
-
Guus
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)
-
Guus
blockquotes could be useful to an extend, but the XEP would be interesting in itself without it.
-
Guus
also: people in open_chat now are experimenting with cowsay in the muc.
-
SamWhited
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
-
Guus
shouldn't block text be mono-spaced?
-
SamWhited
That was the idea
-
Guus
I don't think it mentions that explicitly
-
SamWhited
oops, thanks, I'll add that to my todo as well
-
SamWhited
It mentions it in one of the examples!
-
SamWhited
> This should show up as monospace, preformatted text ⤴
-
SamWhited
Probably need some normative language there
-
Guus
is this valued: ``` hello ```
-
Guus
also, lines with ``` could easily by accident end with some random whitespace - might be good to explicitly allow for that?
-
SamWhited
hmm, no, I just didn't expand that section as much as I thought I did
-
SamWhited
It should only be the sequence "```\n" at the beginning of a line followed by "\n```"
-
SamWhited
I think; I'm not sure how likely accidental use of it would be without that
-
Guus
```<space>\n
-
SamWhited
why the space?
-
Guus
because people copy/paste stuff sloppy?
-
SamWhited
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
-
Guus
I've had hell with the import of DER certs, because of a trailing space somewhere. It might be good to be somewhat lenient.
-
SamWhited
yah, makes sense
-
Guus
(then again, I'm leaning towards dropping all of this weird complexity by dropping blocks from the xep completely)
-
Guus
two xeps? Styled spans, Styles blocks?
-
Guus
well, I'm going to pour myself a drink and call it a night :)
-
Guus
will lurk on mobile
-
Guus
g'dnight!
-
SamWhited
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
-
Ge0rG
Can we have a language identifier right after the initial ``` ?
-
SamWhited
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
-
Ge0rG
SamWhited: call it a syntax hint, then it's sufficiently free form
-
Arc
it rages on
-
SamWhited
Arc: It's all part of my secret plan to not be re-elected next term.
-
Guus
We'll punish you by reelecting you anyways.
-
Arc
its true.
-
Arc
idk tho, 5 people must be elected to council.
-
Arc
you're easily one of the most qualified
-
SamWhited
heh, thanks… drat though, I guess I'll have to think up more controversial proposals to create right before the election
-
Kev
I don't *think*, although I might misremember, that all the slots have to be filled.