XSF Discussion - 2017-09-15


  1. Guus

    Link Mauve: to late šŸ˜‰

  2. Guus

    who can set me up with access to the XMPP Twitter account?

  3. tux

    moparisthebest: I wondered because when I looked up nick hash coloring recently I saw that SHA1 was used to calculate the hash.

  4. jonasw

    tux: sha was my first choice indeed, but it doesn't really matter

  5. tux

    are there other implementations which use crc?

  6. jonasw

    tux: I haven't checked

  7. dwd

    jonasw, I wondered about CRC32. It feels like it's more prone to accidental collisions. Adler32 is less so, and faster. And MD5 even less so and fast enough these days.

  8. jonasw

    dwd: Adler doesn't work at all in those input sizes

  9. tux

    If we could come up with a hint that one of the algorithms is most common for nick hashing I'd vote for that most common algorithm.

  10. jonasw

    dwd, it doesnā€™t matter a lot (except that Adler32 needs much more input to be effective) since we fold the output to 16 bits anyways

  11. jonasw

    tux, interesting idea; however, my intention was to go with something which is easily available on all platforms and implementations; the zlib crc32 should be such a thing

  12. jonasw

    with MD5, we had the concern that it might vanish from crypto libraries at some point

  13. tux

    For C/C++ that's true. I'm not so sure about other languages.

  14. tux

    IMHO it would be sensible to have a scheme that is viable to as many (modern) programming languages as possible. We want people to use this.

  15. jonasw

    most languages have some kind of zlib support, because the zlib is everywhree

  16. jonasw

    I agree

  17. jonasw

    I can check how well Adler16 performs. we might be able to seed it properly so that it randomizes, but Iā€™m not too confident in that. the adler concept is a bit weak on the mixing side

  18. dwd

    jonasw, I think CRC32 predates zlib, actually.

  19. jonasw

    dwd, sure

  20. tux

    The fine thing about CRC ist that it is easy to implement

  21. jonasw

    is it? I never managed to :)

  22. dwd

    Huh. CRC is 1961, CRC32 is 1975.

  23. jonasw

    dwd, Iā€™m referring to zlib crc32 because of the specific zlib polynomial used

  24. tux

    At least I did some working implementations. ;)

  25. jonasw

    tux, in my defense, the platform I tried it on was VHDL ... soo ... ;-) but given that there exist libre implementation of the zlib CRC32, it would be easy to port to any language, if there are really any which donā€™t have access to a CRC32 implementation with that polynomial

  26. tux

    jonasw: yes, it is. Maybe it makes sense to link to a normative description for CRC32. I'll have a look during the weekend.

  27. edhelas

    do you guys know XMPP clients that are doing Jingle with WebRTC ?

  28. jonasw

    yes, I hadnā€™t found one

  29. jonasw

    edhelas, jitsi maybe?

  30. jonasw

    tux, if you could find a nice normative reference for the zlib CRC32 or CRC32 in general and the zlib polynomial, that would be of great help

  31. dwd

    jonasw, No, Jitsi-the-desktop-client doesn't interop with JitsiMeet.

  32. jonasw

    dwd, aw, pity

  33. jonasw

    put them on a stake and burn them with flames

  34. jonasw

    :)

  35. dwd

    edhelas, The only ones I know of are bespoke Web ones.

  36. jonasw

    (just kidding)

  37. edhelas

    dwd, that's what I thought

  38. intosi

    The benefit of MD5, is that every XMPP implementation already knows how to do that.

  39. dwd

    jonasw, "Classic" Jingle VOIP doesn't interop with WebRTC Jingle VOIP.

  40. edhelas

    so we don't have any client, except Movim, that implement Jingle using WebRTC

  41. jonasw

    intosi, isnā€™t it a MUST NOT by now? :)

  42. dwd

    intosi, True. Also there are loads of implementations everywhere.

  43. intosi

    jonasw: sure, but legacy.

  44. jonasw

    intosi, will legacy implement new things?

  45. dwd

    jonasw, In security cases.

  46. intosi

    Fine, then propose SHA-1, which is definitely required, for things like CAPS.

  47. jonasw

    and Iā€™m sure those implementations depend on lib*ssl for those; will lib$whateverssl support MD5 in the future?

  48. jonasw

    (SHA1 will probably work better, indeed)

  49. jonasw

    (support-wise)

  50. dwd

    jonasw, There's a number of issues with MD5, but the worst one now is speed. MD5 is so fast that brute-forcing is practical. At the same time, and increasing number of people are using it in this kind of thing because of that.

  51. jonasw

    dwd, fun fact: sha1 is faster than md5

  52. Tobias

    fun fact: BLAKE2 is faster than SHA1 :)

  53. jonasw

    dwd, https://sotecware.net/images/dont-puush-me/9n701UwrIuU2NFuTexy7rFpu3Auf7zbQlVsEyFTVqAM.png

  54. intosi

    If speed of nickname colour hashing is going to be your issue, I wonder how your client is to keep up in such a room with all the messages ;)

  55. jonasw

    intosi, frankly, *I* do not care much about it; my client will cache the colors anyways.

  56. jonasw

    but I heard that itā€™s not that trivial for other implementations.

  57. dwd

    jonasw, I thought it was only faster where the silicon supports it? But in any case, SHA-1 sounds good then.

  58. jonasw

    dwd, the difference seems to small for silicon support to be the reason in this graph, I think. so yeah, seems to be faster

  59. jonasw

    (not that itā€™d matter on our input sizes)

  60. intosi

    I like hashing methods that are already in use in code ;)

  61. dwd

    intosi, To be honest, I'd go for SHA-1 ver CRC32-with-some-polynomial just for the ease of specification.

  62. intosi

    Yeah

  63. dwd

    intosi, To be honest, I'd go for SHA-1 over CRC32-with-some-polynomial just for the ease of specification.

  64. intosi

    I tried to calculate my nick colour yesterday evening, and wasn't sure whether I was using the correct polynomial.

  65. jonasw

    Iā€™m all in for that

  66. intosi

    As in some environments, folks just mention it's a crc32, and never bother telling you which one it actually is ;)

  67. jonasw

    the question is: shall I update the protoxep or update it when it goes experimental?

  68. dwd

    intosi, On this client, it is, rather fittingly, orange.

  69. daniel

    šŸ‘for sha1

  70. intosi

    Orange is good.

  71. dwd

    intosi, You say that, but it's not working out well for the US.

  72. intosi

    dwd: yeah, but they're holding it wrong.

  73. jonasw

    lol

  74. dwd

    jonasw, Just wait.

  75. jonasw

    dwd, great, that fits my schedule better

  76. tux

    Yeah, we should provide a sample set for software testing. With hashing methods it's always kind of a guess whether the results are correct.

  77. jonasw

    tux, there are test vectors

  78. tux

    Ah, okay.

  79. tux

    jonasw: hm.. You mean test vectors for CRC32 or for the Nick coloring?

  80. jonasw

    the latter

  81. tux

    Ack

  82. Link Mauve

    edhelas, Jitsi Meet is a Jingle client, just like Movim.

  83. jonasw

    'p

  84. Guus

    Link Mauve - do you think Jitsi Meet will do interop Jingle? I know that they recently added p2p support, but otherwise, everything typically flows through the videobridge. Jingle is involved there, but is it functional outside of their own solution?

  85. Guus

    It'd be great if they do though

  86. edhelas

    does the visioconference part of Jitsi do even pass by Jingle ?

  87. edhelas

    looks like their solution is not a full XMPP based solution

  88. Holger

    edhelas: The Videobridge is XEP-0340.

  89. edhelas

    Holger, okay

  90. Guus

    oh, there's definately a lot of XMPP in there. I'm not sure if it's interoperable, though, with non-Jitsi clients

  91. dwd

    Guus, I believe that Talky uses it well enough.

  92. jonasw

    dwd,

  93. jonasw

    (sorry, wrong window and tab completion fubar)

  94. Guus

    (he's talking about you in another window, Dave)

  95. fippo

    talky is now based on a bunch of deferred standards :-)

  96. MattJ is currently in a call on Talky

  97. MattJ

    I might have to end it now I know this

  98. SouL

    Haha

  99. fippo

    mattj: there is also a proprietary namespace used. nothing critical at least :-p

  100. moparisthebest

    fippo: isn't everything based on deferred standards? :'(

  101. moparisthebest

    even the 2017 compliance suite specifies deferred standards, or at least ones that have been in last call for months and should be deferred

  102. fippo

    the internet runs on drafts

  103. mimi89999

    fippo: šŸ‘

  104. jonasw

    regarding the coloring thing, Iā€™m still uncertain whether using the roster name or the JID is preferable. using the roster name has the advantage that multiple JIDs to the same contact can have the same color. using the JID has the advantage that the color is stable even if I change the name.

  105. jonasw

    opinions?

  106. jonasw

    using the JID also has the advantage that the three different Martins in my roster could have different colours

  107. jonasw

    and I wonder how relevant the "I have the same person with multiple different JIDs in my roster" use-case really is

  108. SamWhited

    I'm a fan of the JID. Although it would be a bit weird because toys have to do the bare for 1:1s and the resourcepart only for mucs probably.

  109. jonasw

    "toys"?

  110. Zash

    Weren't public semi-anon MUCs an edge case only used by nerds who nobody cares about (ie us)?

  111. jonasw

    for MUC the situation is indeed so that the nickname is used if the muc is anonymous, otherwise roster name or JID, depending on what we decide on

  112. SouL

    JID sounds really nice to me.

  113. jonasw

    I also tend to JID by now, even though I first thought that roster name would be nice

  114. Ge0rG

    No opinion from me

  115. SamWhited

    *sigh* phones

  116. SamWhited

    I think that was supposed to be "you would have to useā€¦"

  117. SamWhited

    Also what Zash said though; probably best to just ignore MUC to keep things simple. The XEP already *looks* too long for such a simple client feature (I read through it, it seems fine, but initial impressions are everything and I'm already concerned that it looks complicated enough that clients won't bother trying to implement it)

  118. jonasw

    SamWhited, I thnik on the other hand that many XEPs are way too short because they lack detail.

  119. jonasw

    the part on MUC is literally three short paragraphs, I wouldnā€™t omit that

  120. Ge0rG

    SamWhited: MUC nick coloring was the actual reason for inventing that XEP

  121. jonasw

    we can move the test vectors to some appendix or so and not put each case in its own section, thatā€™ll shorten the TOC a bit

  122. SamWhited

    jonasw: It's not a big deal, it looks like a really good XEP overall, I just worry about these things.

  123. jonasw

    thanks, and ok

  124. jonasw

    (also the thing isnā€™t that simple anymore once you consider color vision deficiencies and such)

  125. Ge0rG

    Maybe I should read the XEP as well, instead of just relying on what I think it contains.

  126. SouL

    Ge0rG, haha :)

  127. jonasw

    :D

  128. Zash

    Ge0rG: Blasphemy!

  129. Ge0rG

    SouL: something I had to explain to a customer today: as a Ph.D., you learn to make confident statements about something you have no idea of.

  130. Zash

    Ge0rG: You better only look at the examples!

  131. Zash

    -xkcd 793

  132. Bunneh

    Physicists https://xkcd.com/793/

    Physicists
    Physicists
  133. Ge0rG

    actually, I just rely on jonasw writing down what we discussed at length multiple times ;)

  134. SamWhited

    I pretty much do only look at the examples the first time I "read" an XEP. I figure that's what client devs are going to do, so if they're confusing or lead to the wrong behavior it's probably something that should be fixed

  135. jonasw

    what hurt most while writing the XEP was trying to stick to en_US ;-)

  136. Ge0rG

    Yeah, blaming client devs for (even major) failures is very disappointing and surprisingly hard work. BTDT.

  137. SamWhited

    I'm not actually sure how to read that; if it sounded like I was blaming them, I'm not. I think that it's fine for them to only glance at the examples and it's our (XEP authors') fault if we don't communicate clearly with our examples.

  138. SouL

    Ge0rG, super good one :)

  139. Ge0rG

    SamWhited: you are absolutely right, my remark was rather tangentially related than a direct answer to yours

  140. SamWhited

    *nods* I think we're on the same page

  141. Ge0rG

    It just made me remember the Carbons attribution issue from earlier this year, and I think the Carbons spec is rather clear.

  142. Ge0rG

    At least in that regard.

  143. SamWhited

    ah yah, that one was bad

  144. Ge0rG

    And so were the reactions from developers.

  145. Ge0rG

    And so were the reactions from many developers.

  146. SamWhited

    Were they? The one or two issues I submitted (Mcabber and Jitsi, I think) were pretty good

  147. Ge0rG

    SamWhited: some developers just didn't care

  148. SamWhited

    figures

  149. SamWhited

    *sigh* oh well.

  150. jonasw

    Ge0rG, did you send them carbons claiming to be from themselves to confuse them? :)

  151. Ge0rG

    jonasw: I sent some, but not to the devs

  152. Ge0rG

    Or at least not claiming their identities

  153. jonasw

    why not? :( ;-)

  154. Ge0rG

    It didn't appear to me, back then

  155. Ge0rG

    Instead I claimed to be an unpopular political character.

  156. Ge0rG

    What would be the least inelegant way to implement a self-ping feature on MUC JIDs? It needs to be discoverable via caps info, and it needs to be something that doesn't have meaning yet. Maybe a certain IQ to the bare JID?

  157. dwd

    Discoverable by caps? That's hard.

  158. jonasw

    Ge0rG, make a feature var which defines a ping to the bare MUC jid to only succeed iff the requesting resource is joined and return <item-not-found/> or somtehing otherwise

  159. jonasw

    Ge0rG, make a feature var which defines a ping to the bare MUC jid to only succeed iff the requesting resource is joined and return <item-not-found/> or some other error if the user is not joined

  160. Ge0rG

    jonasw: that would probably make sense.

  161. jonasw

    currently how that ping behaves is undefined-ish I think

  162. Ge0rG

    we need to feature-check it anyway.

  163. jonasw

    yupp

  164. Ge0rG

    jonasw: currently I'm pinging my own participant JID, which is a double-RTT va banque game.

  165. jonasw

    I know

  166. Ge0rG

    jonasw: I think that ping IQ semantics are defined already, and changing them is actually incompatible. Maybe a dedicated IQ makes more sense?

  167. jonasw

    Ge0rG, is the ping to a bare MUC jid really defined?

  168. jonasw

    daniel, you have some insight in the OMEMO topic, right? can you confirm that this is the result of the recent discussion which should be merged? https://github.com/xsf/xeps/pull/482

  169. dwd

    Ge0rG, What are you doing to do with this ping?

  170. Ge0rG

    jonasw: Oh, right. IQs must go to a full JID

  171. dwd

    Ge0rG, Erm, no.

  172. Ge0rG

    dwd: I need to figure out if I'm still joined to a MUC

  173. dwd

    Ge0rG, OK. And if you're joined, you'll do nothing, and if not, you'll rejoin?

  174. Ge0rG

    dwd: exactly

  175. dwd

    Ge0rG, So - and I admit this has inefficiencies - as a first step, could you not just send presence?

  176. jonasw

    Ge0rG, the ping to the MUC component domain makes sense, the ping to the occupant JID does too, the ping to the bare MUC jid doesnā€™t really

  177. Ge0rG

    dwd: no.

  178. dwd

    Ge0rG, Why not?

  179. Ge0rG

    dwd: sending presence is a "groupchat 1.0 leagacy" join

  180. Ge0rG

    dwd: sending presence is a "groupchat 1.0 legacy" join

  181. Ge0rG

    jonasw: not practically, but technically.

  182. jonasw

    Ge0rG, sure

  183. dwd

    Ge0rG, Well, yes, you'd get unwanted history potentially. But if that's *quite* close, is it somewhere to build from?

  184. jonasw

    and if the behaviour is practically undefined, you can re-define it to be something useful with a feature var

  185. Ge0rG

    dwd: the MUC implementation might mark me as a legacy client.

  186. jonasw

    Ge0rG, and sending presence with <x/>?

  187. Ge0rG

    jonasw: would do a full rejoin every time.

  188. jonasw

    ugh

  189. jonasw

    even for a joined client?

  190. Ge0rG

    jonasw: you remember my last PR? ;)

  191. jonasw

    yeah

  192. Ge0rG

    it was exactly about that.

  193. jonasw

    do implementations behave that way?

  194. Ge0rG

    I have no idea. I think prosody trunk might.

  195. dwd

    jonasw, Rejoin handling? M-Link, Openfire, possibly ejabberd.

  196. dwd

    Ge0rG, When you say "might mark me as a legacy client", what do you think this would do? No servers I'm aware of do this.

  197. Ge0rG

    dwd: I have no idea. I consider "legacy groupchat" to be something to burn with fire, or at least to avoid.

  198. Ge0rG

    dwd: if I were God of XSF, I'd completely remove legacy groupchat from 45.

  199. Zash

    I sorta wanna remove it from Prosody. IIRC it'd simplify somewhat.

  200. Ge0rG

    dwd: I have no idea if anybody is still using it, or if there are dragons inside the implementations.

  201. Ge0rG

    MUC got enough hairy corner cases without groupchat legacy.

  202. SamWhited

    What is "legacy groupchat"? I don't see any mention of that grepping for "legacy" in 0045

  203. Ge0rG

    Though I must admit, "Groupchat Legacy" would make for an awesome title for an XSF-themed movie. Or computer game. Or rock band.

  204. jonasw

    SamWhited, search for Groupchat 1.0 Protocol

  205. Ge0rG

    SamWhited: https://xmpp.org/extensions/xep-0045.html#enter-gc

  206. SamWhited

    ahh, yes, thanks. Kill it with fire.

  207. dwd

    Ge0rG, The only difference is the join, though. Once you're joined, its exactly the same.

  208. Ge0rG

    SamWhited: I volunteer to make the diff to 45, provided that council will signal pre-approval.

  209. dwd

    Ge0rG, So by periodically reflashing presence, you're just risking getting the wrong history.

  210. Zash

    dwd: Like gmail did?

  211. Ge0rG

    dwd: will my presence get forwarded to all participants?

  212. Ge0rG

    dwd: I have a MUC with histsize=500.

  213. dwd

    Zash, Ah, gmail re-sent a '45 join periodically as well. That was mega-annoying.

  214. Zash

    Rebroadcasted all directed presence too iirc

  215. dwd

    Ge0rG, Yes, and also erk. But I think it's an interesting place to start.

  216. jonasw

    I think a ping is a cleaner solution. nothing wrong if itā€™s with a feature var, is there?

  217. Zash

    In such a way that if they changed nickname, they'd periodically switch back and forth

  218. dwd

    Ge0rG, If your server both maintains, and always sends by default, 500 lines of history there's something badly wrong somewhere.

  219. dwd

    Zash, Indeed. I'm not suggesting that.

  220. Ge0rG

    dwd: I totally could live with a <presence><limited history><I'mtherealready></p>

  221. dwd

    Ge0rG, In principle, a server could/should not rebroadcast presence where its identical anyway. But that's a small point.

  222. Ge0rG

    dwd: I think that having 500 lines of history in the default buffer beats MUC-MAM.

  223. SamWhited

    Ge0rG: I can't speak for anyone else, but I'd be all for that.

  224. Ge0rG

    dwd: it's a small O(NĀ²) point.

  225. SamWhited

    Others are probably more conservative since it is in draft, after all.

  226. Ge0rG

    Eternal draft.

  227. Zash

    <presence><{muc}x><{mam}history plz/><//

  228. SamWhited

    Ge0rG: Is there some reason to move it on past draft?

  229. dwd

    SamWhited, The fallback is it's a rejoin/rebroadcast.

  230. Ge0rG

    dwd: there is another problem with the presence approach: if you lost sync, you'll get the history (mkay), and you'll get a full participant list. But you need to know in advance that you are receiving a full list so you can clear your previous list.

  231. Ge0rG

    dwd: otherwise you'll end up with stale participants in your cache

  232. Ge0rG

    and race conditions will prevent any sensible workaround

  233. jonasw

    right

  234. Ge0rG

    Besides of all that, some client (library) implementations don't expect to receive a join from a MUC they are already joined into. So they might lose sync anyway.

  235. dwd

    Ge0rG, Well a library written to use a periodic presence as a ping-or-rejoin will work fine, surely?

  236. Ge0rG

    dwd: yes, unless you hacked the ping-or-rejoin code on top of an old library. ;)

  237. Ge0rG

    Maybe it would be cleaner to respond to a non-x-ed <presence> with an error, so the client can rejoin?

  238. Ge0rG

    But still, we have the O(NĀ²) problem that every client, sending a periodic presence, will flood everybody else.

  239. Ge0rG

    Can anybody gather stats on "groupchat 1.0" usage?

  240. MattJ

    https://matthewwild.co.uk/uploads/gc_pinger.html

  241. MattJ

    (not an answer to your question about usage stats)

  242. dwd

    Ge0rG, "If I write my code badly it might be written badly" is not a tremendous argument.

  243. dwd

    MattJ, You're suggesting that this be done server-side instead?

  244. MattJ

    I'm merely dropping a historical anecdote :)

  245. Ge0rG

    dwd: it's not a tremendous argument indeed. Please focus on my two material arguments instead.

  246. dwd

    Ge0rG, Excellent. So if the client is dropped from the MUC without its knowledge, and simply sends an updated presence, then you'll be inadvertantly getting the same problem but this time it's unavoidable.

  247. Ge0rG

    dwd: right. But this is another argument.

  248. MattJ

    Server-side doesn't tell the client that they are disconnected, does it even help? It helps them not be de-synced when they rejoin, but only if the server happened to ping them in that time period

  249. dwd

    Ge0rG, The only solution would be to, before updating presence, send your IQ-based ping beforehand. But then there's a minute race condition, which you'll no doubt be disproportionally upset about.

  250. Ge0rG

    dwd: I don't think it is wrong to focus on corner cases when aiming to design robust protocols.

  251. Ge0rG

    dwd: if we design a 90% protocol, we'll end up in the place we are in today.

  252. MattJ

    +1, corner cases matter

  253. Ge0rG

    where my desktop client at home disconnects from a MUC because I'm joined to the same MUC with the same nickname from my mobile device when on the go.

  254. Zash

    If we design a 100% protocol, we'll be done in the year 3000?

  255. MattJ

    Zash, then we can release 0.10

  256. dwd

    Ge0rG, Excellent. So I've given you a corner case which your design fails to address, and my (sketched) design does.

  257. Ge0rG

    Zash: fixing MUC isn't _that_ complicated. If we can get rid of legacy.

  258. dwd

    Ge0rG, Legacy meaning gc?

  259. jonasw

    dwd, and how to solve the issue with inconsistent occupant state?

  260. MattJ

    I'm inclined to agree with finally dropping GC 1.0 support

  261. jonasw

    when Iā€™m re-sending presence and in fact Iā€™m doing a join, I donā€™t get presence notifications for occupants which left in the meantime

  262. Ge0rG

    dwd: I'm not saying your design is bad, or that it's wrong to follow that approach. I'm just pointing out that your sketch won't work.

  263. jonasw

    I think both designs donā€™t work

  264. Ge0rG

    dwd: in the current context, legacy means GC. But I'd be glad to kick out more legacy when appropriate.

  265. jonasw

    and ideally there would be an IQ based join which either fails or succeeds and only after the IQ returns you get the presence updates, so that itā€™s fully synchronous

  266. dwd

    jonasw, Sure, but that's MIX.

  267. Ge0rG

    jonasw: I'm okay with a presence based join that succeeds as soon as you get a presence reflection.

  268. Ge0rG

    Which is MUC.

  269. Ge0rG

    dwd: I could imagine a periodic presence with yet another additional element, where the server would respond with a presence-unavailable, followed by a full rejoin.

  270. Ge0rG

    dwd: and all of this would depend on a feature flag.

  271. Ge0rG

    dwd: and the server wouldn't forward such a presence to other participants, unless it contains a delta.

  272. Ge0rG

    dwd: the presence-unavailable (or any other response marker) is needed to make the client flush the cached data.

  273. jonasw

    Ge0rG, "succeeds as soon as you get a presence reflection"? I donā€™t understand that part

  274. Ge0rG

    jonasw: a MUC always reflects presence to you. So once you get that reflected presence from the MUC, you know you are inside.

  275. Ge0rG

    reflects your own presence, that is.

  276. jonasw

    sure, but ... how do you know the occupants list when you didnā€™t know that you re-joined?

  277. Ge0rG

    jonasw: "the presence-unavailable (or any other response marker) is needed to make the client flush the cached data."

  278. jonasw

    ahh

  279. dwd

    (Or: The occupant data could have a delay tag in)

  280. jonasw

    dwd, does that help you to identify which occupants have left in the mean time?

  281. Ge0rG

    1. MUC advertises "smart-resync" 2. you join, normally. 3. you send a <presence><smart-resync> 4a. you get a presence reflection 4b. you get a presence-unavailable followed by a full resync

  282. dwd

    No, but you know when the end of the occupant list is, so that should be OK.

  283. Ge0rG

    dwd: you need to know the beginning of the occupant list.

  284. Ge0rG

    dwd: so essentially you must strip <delay> from inbound client presences

  285. dwd

    Ge0rG, What?

  286. Ge0rG

    and if the client receives a presence with a delay, it knows that it's at the beginning of a rejoin.

  287. Zash

    Was there a status code for 'this means you just joined'

  288. dwd

    Ge0rG, I suppose you could do it that way. Or spot your own afterward and clear any untainted. Or ...

  289. Ge0rG

    Zash: yes, it will be in your own reflected presence at the end of the occupant list

  290. Ge0rG

    dwd: RACE CONDITIONS!!1!!

  291. Ge0rG

    Sorry, I just couldn't resist.

  292. dwd

    Ge0rG, I don't think there are any there.

  293. dwd

    Ge0rG, Unless you're getting stanzas out of order.

  294. Ge0rG

    dwd: any participant presence you receive after sending your smart-resync-presence might be either old presence from your previous MUC session or the beginning of the occupant list. No way to know.

  295. Ge0rG

    So what you could do is to put all the presences into a queue until you get your own reflection. Or the subject.

  296. Ge0rG

    I think it's your own with the appropriate status code

  297. dwd

    Ge0rG, You'd get your own afterward, certainly. And any presence you get after a smart-resync is either un-delayed, in which case it's the first stanza(s) you'll get and it potentially stale but who cares because you'll notice this later - or else is delay marked, and therefore part of a resync.

  298. Ge0rG

    dwd: unless it is a delayed presence because the sending client added a delay element.

  299. dwd

    Ge0rG, The only pattern, in other words is: *non-delay [ *delay ] your-reflection

  300. dwd

    Ge0rG, Yes, but there's a thing in delays to tell you who is delaying.

  301. Ge0rG

    dwd: and I need to put all the non-delayed presences into a queue and unwind them once I realize it's a resync.

  302. Ge0rG

    dwd: that's not how you design a robust protocol.

  303. Ge0rG

    dwd: and really, what's wrong with injecting a presence-unavailable?

  304. dwd

    Ge0rG, No you don't.

  305. MattJ

    So what isn't solved by <presence type="error"> if the client isn't in the room and they send presence with no <x>?

  306. dwd

    Ge0rG, The moment you see a presence delayed by the MUC, you're rejoining. You weren't before, you now are.

  307. Ge0rG

    dwd: okay, you try to make it work in a backward compatible way. I appreciate that. But it's not easy.

  308. Ge0rG

    MattJ: groupchat 1.0

  309. MattJ

    and apart from that?

  310. dwd

    MattJ, Breaks compatibility with gc, of course. Whether that's now safe to do I'm not sure, though it feels dangerous.

  311. Zash

    What clients do gc?

  312. MattJ

    I'm willing to do it

  313. Zash

    What *clients* do it, not counting advanced users manually typing XML in netcat (like I do sometimes)?

  314. MattJ

    I don't mind if 20 year-old clients break, and probably some bots. Any actively maintained clients likely do the right thing already or will be fixed promptly

  315. Ge0rG

    MattJ: you could create stats on GC1 clients.

  316. Ge0rG

    MattJ: presence-error would also be a nice way to make GC1 client devs care.

  317. Zash

    Prosody trunk MUC logs such conditions already

  318. Zash

    Debug level, but still

  319. Ge0rG

    most of it will probably be resync problems.

  320. dwd

    Does/did gc have any discovery? I suspect not.

  321. Zash

    Ge0rG: It logs joins without <x> and presence with <x>

  322. Ge0rG

    Okay, I'm late for my weekend already. Thanks very much for the productive discussion. Maybe you can bring up killing GC in the next council meeting?

  323. MattJ

    I think that's the best solution, and I'm willing to move forwards on it as a server dev

  324. Ge0rG

    I think that would be a good first step, with the second step being an explicit smart-resync presence feature

  325. Ge0rG &

  326. MattJ

    fg

  327. SamWhited

    I'll add it to the agenda when I get back to my desk if someone else hasn't already (leaving this here as a note to myself)

  328. dwd

    kill -STOP %1

  329. MattJ

    Now he'll never get home

  330. dwd

    MattJ, "SIGSTOP cannot be caught or ignored."

  331. jonasw

    SamWhited, did it for you

  332. SamWhited

    Thanks

  333. jonasw

    who has power over https://hub.docker.com/r/xmppxsf/xeps/builds/ ?

  334. jonasw

    I could use someone hitting a retry button.

  335. jonasw

    that build failed due to some remote network issue

  336. dwd

    jonasw, Randomly update the README?

  337. jonasw

    good point, I wanted to merge my readme stuff anyways

  338. moparisthebest

    woah jonasw warning: failed to load external entity "http://xsltsl.sourceforge.net/modules/node.xsl" the xep build depends on sourceforge being up? that sounds like a bad bet

  339. moparisthebest

    can it be fixed to not depend on any remote entities?

  340. Guus

    Hey, did Thiago become active again?

  341. fippo

    nice change @ jingle relay nodes.

  342. fippo

    mattj: remember that xep-0215 is much better though!

  343. pep.

    edhelas, DNS resolution failed on movim.eu

  344. edhelas

    which DNS ?

  345. pep.

    movim@conference.movim.eu/pep.: cancel: Server-to-server connection failed: DNS resolution failed

  346. pep.

    I can dig it from here actually :/

  347. pep.

    And from my server

  348. edhelas

    IPv6 maybe ?

  349. pep.

    works as well