XSF Discussion - 2020-03-31


  1. Guus

    Assume a scenario in which a user is online with a single resource, stream management enabled, then gets disconnected abruptly, leaving the SM session in a resumable state, and a stanza arrives. What now is the expected behavior if the same user establishes a new stream, but does not resume the session but performs resource binding instead?

  2. Daniel

    The sm session 'times out' all stanzas get bounced (or what ever your server is doing)

  3. Daniel

    What would the alternative be?

  4. Zash

    Like, they closed their laptop, woke up their phone and left the office?

  5. Guus

    Well, for stanzas that were addressed to a bare JID, it might be desirable to re-evaluate the routing logic, delivering it to the newly established session.

  6. Zash

    I suspect this is a full week topic for a summit

  7. Guus

    and in case the new session rebinds using the same resource... maybe deliver all stanzas to that session?

  8. Daniel

    > and in case the new session rebinds using the same resource... maybe deliver all stanzas to that session? That would maybe work for some messages. But nothing else

  9. Zash

    And messages usually go to the bare jid now, and you can get it from MAM

  10. Daniel

    Yes. So anything that is delivered to mam you might not want to actually bounce. I was just saying do what ever you do when you time out

  11. Guus

    ejabberd has an option that can be used to have all queued messages to be resend after SM times out (resend_on_timeout)

  12. Ge0rG

    Guus: that's bad if you have multiple clients.

  13. Ge0rG

    Guus: the existing implementations all suck

  14. flow

    and potentially breaks the stable order guarantee of XMPP (depending on your PoV)

  15. Ge0rG

    the right thing to do would be to do server-side tracking of individual clients, based on their hopefully constant-over-time resource string

  16. Guus

    That's basically what I suggested, right? When resource binding on the same resource... do magic.

  17. Ge0rG

    Guus: indeed, yes. But you can't know how much of the old session actually already arrived at that device, unless it attempts to resume

  18. Ge0rG

    my client won't honor the resume timeout value and just attempt to resume always, if it has a previous session

  19. Guus

    Ge0rG That's very true.

  20. Guus

    problem here is that this client doesn't keep track of the old session metadata if it crashes unexpectedly.

  21. Guus

    (unsure if that's fixable on their end - that seems to be the preferred approach to me)

  22. Ge0rG

    Guus: that's exactly what remains unsolved. Or you use MAM

  23. jonas’

    use MAM

  24. jonas’

    better than guessing

  25. Daniel

    I use MAM

  26. jonas’

    or churning the disk by persisting the entire stream state to disk on every. single. stanza.

  27. Ge0rG

    Guus: with MAM, as Daniel said, the server should drop all message stanzas from the old session when destroying it, and not bounce them

  28. Daniel

    > or churning the disk by persisting the entire stream state to disk on every. single. stanza. I always wanted to write an iOS client that does that

  29. Ge0rG

    (unfortunately, not all servers do that yet)

  30. Daniel

    I don't think that's too unreasonable if you plan it from the beginning and design the app around it

  31. Ge0rG

    Daniel: yes

  32. Ge0rG

    Daniel: all we need is a full redesign of the complete xmpp client stack

  33. Ge0rG

    it needs to be serializable in an efficient way, ideally with some kind of journal

  34. Ge0rG

    Android could also profit from that.

  35. Guus

    flow I'm getting this from the client developers. Do you know if that's true? > Another possible solution to the problem is to persist the stream id, session id and the number of acknowledged messages from the server and the client. This is not supported by SMACK by default,

  36. Guus

    ah, wait, I read that as "smack can't resume" but maybe they're saying "smack doesn't persist to disk"

  37. Daniel

    Well it's not as easy as storing those three values

  38. Ge0rG

    Guus: yes, smack can resume, but not from disk

  39. jonas’

    you also need to store all presence state

  40. Ge0rG

    Guus: you'd need to serialize the XMPPTCPConnection and everything related to it to disk as well

  41. flow

    depends, no?

  42. flow

    but yes, you usually want to resurrect the XMPPTCPConnection with the same listeners setup as before it was suspended to persistent storage

  43. flow

    but that does not necessarily require to serialize XMPPTCPConnection

  44. Ge0rG

    no... just most of its members.

  45. Daniel

    Well all pending stanza, all pending callbacks to iqs

  46. Daniel

    All state

  47. Daniel

    Like presence, mucs etc

  48. Ge0rG

    Guus: so you can't easily hibernate smack to disk and reload afterwards.

  49. Ge0rG

    Guus: but you can hope that your app won't be killed

  50. Guus

    and if you could, you'd have to do that preemptively on ever.single.stanza (or how did Jonas' put it?)

  51. flow

    Guus, what's the problem you are trying to solve (couldn't find it in the backlog)

  52. Ge0rG

    Guus: yes, after each change of the internal state (e.g. receiving or sending a stanza) you'd have to persist everything

  53. Guus

    flow just a question I received over email: client gets killed, the restart it, but won't get messages that have been delivered while offline (unless they do MAM).

  54. Daniel

    Ge0rG: well you have to persist the delta

  55. Ge0rG

    Daniel: but with smack, you need to manually extract the delta from the state of dozens of weakly linked objects

  56. Daniel

    Yeah don't use smack for that

  57. flow

    Guus, use MAM ;)

  58. Guus

    Yeah, that's been my conclusion too. Still, I'm wondering if it makes sense to have some kind of option like ejabberd's 'resend' - but instead, I think I'd prefer to send certain messages to a new session with the same resource - something like that.

  59. Guus

    probably bad for MUC though

  60. jonas’

    bad for a lot of things assuming state

  61. flow

    I also think it would violate the stable order requirement of the RFC (but that may not be an issue for your use-case)

  62. Guus

    I'd at the very least not enable this by default.

  63. Guus

    just trying to think of a solution that'd be helpful for certain use-cases.

  64. Ge0rG

    Guus: you can't do that generally because you would end up re-sending all the stanzas that already were delivered but not acked

  65. Ge0rG

    Guus: use MAM.

  66. Ge0rG

    Guus: or, use eternal 0198 sessions ;)

  67. Ge0rG

    (no, that doesn't solve the client crash problem)

  68. Guus

    You're right - but not every user is as obsessed with being 100.0% right all of the time as we are. 🙂

  69. Guus

    some duplication might be acceptable.

  70. Guus

    (to them)

  71. Guus

    And yes, MAM is the proper way to go - but that would probably make them spend more development resources than what they have available.

  72. Guus

    (afk - feeding the offspring)

  73. jonas’

    Guus, some SM implementations will also feed the unacked messages to offline store when the SM session gets terminated.

  74. jonas’

    that may be a viable alternative?

  75. Ge0rG

    yes, if you are guaranteed to only have one client per user, you can use something like prosody's mod_smacks_offline

  76. edhelas

    https://theintercept.com/2020/03/31/zoom-meeting-encryption/

  77. jonas’

    ah that

  78. jonas’

    it’s obvious from the UI when you know what to look out for

  79. jonas’

    (also, I don’t know of any end-to-end encrypted video conferencing software)

  80. edhelas

    when you're calling yourself locally it's end to end encryted 🤔 ?

  81. Ge0rG

    jonas’: that would be... interesting.

  82. pep.

    I'd be interested to know how expensive that is resource-wise

  83. pep.

    jitsi-meet is already getting complaints that they're not doing e2ee fwiw..

  84. jonas’

    essentially you’d degrade the videobridge to a stupid TURN server

  85. jonas’

    then you’re back to E2EE again

  86. jonas’

    if your webrtc session does it

  87. Ge0rG

    you could do homomorphic encryption!

  88. Ge0rG

    but I suppose the more practical approach would be to encrypt the stream payloads and to let videobridge route at the stream level.

  89. Ge0rG

    and to have multi-recipient keys for each stream

  90. Ge0rG

    you are typically using symmetric encryption for the data stream anyway, so just send the decryption key to all parties

  91. Ge0rG

    it's not complex, just requires effort.

  92. jonas’

    right, recipient keys

  93. Ge0rG

    also probably won't work with WebRTC.

  94. jonas’

    it should be possible on the protocol level, but I wouldn’t be surprised if javascript APIs don’t expose this

  95. Ge0rG

    jonas’: it depends on how you derive the session key

  96. flow

    also downscaling become

  97. flow

    also downscaling by the bridge becomes impossible with e2ee

  98. Ge0rG

    which jitsi meet doesn't do AFAIK

  99. Ge0rG

    the right thing would be to create multiple progressive streams, where you get the lowest res with stream 0, the medium res with stream 0+1 and the highest res with 0+1+2

  100. Ge0rG

    but that would require a progressive video codec of sorts.

  101. flow

    do those exists in practice?

  102. jonas’

    jitsi-videobridge (the software) does not do recoding, but there’s allegedly a hardware thing which does

  103. Neustradamus

    What is the solution about XMPP TLS S2S problems for XMPP clients? Example: When an user@xmpp1.tld tries to join a mucroom@conference.xmpp2.tld, it is not possible and the XMPP client has not an error.

  104. MattJ

    Neustradamus, the solution is to switch to Matrix

  105. Neustradamus

    :D

  106. Neustradamus

    Prosody will be a Matrix server?

  107. MattJ

    Who knows

  108. Holger

    https://jabber.fu-berlin.de/share/holger/xczTzkOs6Bduvkve/Awe5-jk3SCOXiFasIOrOag.jpg

  109. Holger

    Conversations says "remote server not found" if I try to join mucroom@conference.xmpp2.tld.

  110. MattJ

    Holger, in case you missed the previous discussion on this topic, you probably don't want to reopen this can of worms

  111. Holger

    😂

  112. Holger shuts up.

  113. Neustradamus

    Holger: The log on muc.xmpp.org: - User has joined - User has left Client has not error and the client always tries but it has already failed.

  114. Ge0rG

    https://i.imgflip.com/3usu50.jpg

  115. Neustradamus

    Ge0rG: example jabber.org (not only) -> xmpp.org is broken.

  116. MattJ

    New draft MAM revision currently here: https://github.com/mwild1/xeps/tree/mam-r7

  117. MattJ

    I'll post to the list about it soon (probably tomorrow)

  118. MattJ

    I have a few things to do before I PR (such as finishing off the other documents I split stuff out to)

  119. Zash

    https://cerdale.zash.se/upload/DCzM-vgHHb2_CbHA/diff-mam-r7.html

  120. lovetox

    nice MattJ

  121. lovetox

    does it make sense to flip the rsm page, and not the whole mam filter result?

  122. lovetox

    notice this is not the same outcome

  123. lovetox

    i fail to see the use case for flipping the page

  124. lovetox

    i does not get you the filter result in the reverse order

  125. lovetox

    it does only get you the first page of the filter result, which you dont actually want, we want the last page, in reverse order

  126. jonas’

    MattJ, the "Client uses two discovered query fields in a query" example differs from the previous example in the value of the @var attributes, is that intentional?

  127. pep.

    MattJ, does that mean pubsub mam is going to be defined somewhere else?

  128. Zash

    Maybe randomize the subdomain in `<iq to='pubsub.shakespeare.lit' type='set' id='juliet1'>` a bit more?

  129. flow

    pep does it matter where it will potentially be defined?

  130. pep.

    flow, it matters that it's defined, as with this PR it doesn't seem to be defined anywhere anymore

  131. Zash

    > I have a few things to do before I PR (such as finishing off the other documents I split stuff out to) pep. ↑

  132. pep.

    ok

  133. pep.

    waiting for updates then

  134. flow

    pep., was it defined before in xep313? IIRC it was just something like "ya'll can do MAM on PubSub, but I don't tell you exactly how<period>"

  135. Zash

    There's some precedent in splitting a XEP since at least MIX

  136. Zash

    flow, didn't say a lot about it, but there was a few lines

  137. pep.

    flow, not saying it was perfect but at least it was a thing :P

  138. pep.

    I'm sure it could be defined a lot better

  139. flow

    I think I would prefer if xep313 simply stated that MAM on PubSub is a possiblity but the exact specification is outside the scope if this XEP

  140. flow

    hmm, not sure about that <flip-page/> thing…

  141. flow

    hope it's optional

  142. lovetox

    i think i understand now the flip page thing, you are supposed to request the last page with rsm via </before> then flip that page

  143. lovetox

    and why do you hope flow its optional? are you a server developer that needs to implement that ?

  144. lovetox

    MattJ, what is the reason instead of namespace bumping this to mam:3, making it a disco feature?

  145. flow

    lovetox, I consider a minimal mandatory-to-implement feature set to be benefical, as it allows to ramp up a new implementation fast

  146. flow

    sure there are counterarguments, and one has to carefully select which feature to make optional

  147. flow

    but <flip-page/> appears to be a good candidate

  148. Zash

    So that's mam:2, the new stuff is mam:2#extended

  149. pep.

    Zash, but it's essentially the same

  150. pep.

    mam:3 or mam:2 + mam:2#extended

  151. flow

    +A client that wishes to use flipped pages MUST ensure that the server +advertises the \'urn:xmpp:mam:2\#extended\' feature.

  152. pep.

    mam:2#extended is just the new mam:3

  153. Zash

    pep., adding support doesn't break all existing clients

  154. flow

    pep I don't think it is

  155. Zash

    to the server, that is

  156. flow

    #extended sounds like an optional extension to mam:2

  157. lovetox

    Zash adding the extended things does not brak clients

  158. lovetox

    as it says it EXTENDS the spec

  159. pep.

    It wouldn't break all clients indeed, just continue supporting mam:2 just like you're going to do anyway

  160. lovetox

    there is no change to existing functionality

  161. Zash

    lovetox, that's what I said. bumping the namespace to :3 breaks everything, unless you do both

  162. Zash

    If you have a mam:2 implementation, adding mam:2#extended doesn't affect anyone

  163. pep.

    Zash, because you're still advertizing for mam:2. Which you can continue doing

  164. lovetox

    it also affects no one if you just announce mam:3

  165. flow

    well, it hopefully affects the counterparty that could talk #extended with you

  166. MattJ

    Doing both has turned out to be a pain i n pretty much every implementation I've seen (when we bumped other namespaces)

  167. flow

    lovetox, as long as you still support mam:2

  168. pep.

    MattJ, I genuinely don't get the difference

  169. lovetox

    flow its just a namespace there is nothing the server needs to do different

  170. pep.

    Just that it's not explicit it's a new thing, you're just adding a new feature and now I've got to check both

  171. lovetox

    its just, if i get a IQ with mam:3 just treat it like mam:2

  172. lovetox

    finished

  173. MattJ

    pep.: you don't have to check both

  174. MattJ

    Just one

  175. pep.

    Yeah so it's just mam:3

  176. MattJ

    No

  177. flow

    honestly, and I haven't read that diff completely so I may not seeing the whole picture, but I am surprised that the #extended thing causes any discussion

  178. pep.

    Or undercovered mam:3 :P

  179. pep.

    flow, to me it's not about mam, it's about how things are done in general

  180. lovetox

    let me guess flow you never implemented mam?

  181. flow

    If the #extended thing is that I think it is, an optional extension to the mam we have, than that appears very sensible to me

  182. flow

    instead of doing mam:3

  183. flow

    lovetox, I did the MAM implementation for Smack

  184. pep.

    Feels like people are just afraid to increase a number

  185. flow

    and wrote the unit and integration tests

  186. flow

    pep., of course we are afraid

  187. lovetox

    then i really dont get how you dont understand how this is bad

  188. pep.

    Why? It's the exact same thing

  189. lovetox

    but let me tell you why

  190. flow

    namespace bumps are not for free

  191. flow

    smack is still on mam:1 fwiw

  192. pep.

    flow, breaking changes are not free

  193. lovetox

    this is not a simple syntax change in the xep, this extended functionality allows clients to do mam in a totally different way

  194. flow

    pep., right that is why they have to be avoided when sensible

  195. lovetox

    its a change how archiving is done on client side in fundamental way

  196. pep.

    namespace bump doesn't equal breaking changes

  197. lovetox

    to say its optional on server side

  198. lovetox

    means that server dont have to adopt it

  199. lovetox

    so that means i have to support mam:2 without extended

  200. pep.

    Right that also..

  201. lovetox

    which is now not just a simple syntax change

  202. lovetox

    no i have to maintain a totally different way of doing mam

  203. Zash

    Has everyone forgotten the pain of mam:0 vs mam:1 vs mam:2 so soon?

  204. lovetox

    what for?, these changes are trivial for servers

  205. lovetox

    this is just some Mysql querys added differently

  206. Zash

    lovetox: haha no

  207. flow

    pep, I am sorry I fail to see how a namespace bump von mam:2 to mam:3 is the exact same thing as an optional extension to mam:2

  208. pep.

    one could say mam:3 is an optional extension over mam:2 :)

  209. flow

    mam:3 would be by definition a breaking change, as it requires a namespace bump

  210. lovetox

    flow the changes here proposed are long wished things of client developers

  211. lovetox

    this is not some optional thing that is nice

  212. lovetox

    these are changes the community deems necessary for an archiving xep

  213. lovetox

    there is really no reason to make this optional

  214. lovetox

    especially for a experimental xep

  215. flow

    there is also no reason to make it not optional?

  216. lovetox

    the only reason something like this would be optional, if there are reasons like we believe there are implementations who simply cant implement the changes because of tecnical problems

  217. MattJ

    Only that it is good features that people want to use

  218. flow

    lovetox, I mean if what you and pep want is that servers are going to announce mam:2 *and* mam:3 simultanously, then I still think that this is far more effort to support than annoucning mam:2 and mam:2#extensions

  219. flow

    because some protocol operations now need to be available under them mam:2 and mam:3 namespace

  220. lovetox

    no flow same operations can be available under both

  221. lovetox

    its no difference

  222. lovetox

    its a subset please

  223. flow

    that's what I said, some operations need to be avaialble under both namespace

  224. lovetox

    its the same operation

  225. lovetox

    do you really think they duplicate the code because of a mam:3 string in an iq

  226. flow

    no, but that does mean that it will become less ugly

  227. flow

    no, but that doesn't mean that it will become less ugly

  228. Zash

    lovetox, yes, bunch of duplication and more complex code

  229. lovetox

    ok but thats of no concern, this is the XMPP Archving XEP this is not some sideshow where we make concessions, these are essential changes

  230. lovetox

    every client needs that

  231. flow

    then every client will implement that

  232. lovetox

    its nothing that some weird use cases need and so we make it optional

  233. Zash

    seems to me you're making very broad assumptions

  234. lovetox

    if you tell someone XMPP has a archiving xep where you cant even download a single specific message

  235. lovetox

    and thats an OPTIONAL feature, some servers implement

  236. lovetox

    thats insane

  237. MattJ

    We're still in a world where some servers don't support it at all :)

  238. lovetox

    we dont need to get more fragmented, we need to move faster and decisive

  239. MattJ

    As far as I'm concerned, servers would be stupid not to implement the #extended stuff, but we can't force them to any more than we can force them to implement any XEP

  240. flow

    lovetox, specifying something as mandatory does not mean that implementations will suddenly implement it. In fact, it will cause implementations that only implement a subset of the mandatory to implement features, which causes much more main. Features get implemented because someone decides that it is worth the effort.

  241. flow

    lovetox, specifying something as mandatory does not mean that implementations will suddenly implement it. In fact, it will cause implementations that only implement a subset of the mandatory to implement features, which causes much more pain. Features get implemented because someone decides that it is worth the effort.

  242. MattJ

    lovetox: btw, I added page flipping for you... if you don't want it I can take it back out ;)

  243. MattJ

    You and a couple of people who complained anyway

  244. lovetox

    no its good, i just wondered if its not to complicated to do the <before> and <flip-page> together

  245. flow

    I'd always assume that simply requesting a small page size would be sufficient

  246. lovetox

    instead of just reverse the filter query

  247. flow

    but I am also always in favor of experimenting with new features

  248. MattJ

    There was a reason I did it on the page rather the results, I can't remember why... might be in my notes from last year somewhere

  249. MattJ

    There was a reason I did it on the page rather than the results, I can't remember why... might be in my notes from last year somewhere

  250. lovetox

    probably because of </before> in the rsm spec

  251. lovetox

    you can already request the last page of a query

  252. MattJ

    Yeah

  253. lovetox

    so you just have to flip that page to finish it

  254. MattJ

    I think that is logically simpler anyway

  255. lovetox

    but i guess we should mention that in the XEP

  256. lovetox

    because nobody will get this on their own

  257. lovetox

    it would be simpler if people would now the </before> thing in RSM

  258. MattJ

    There is an example for that

  259. lovetox

    in your mam change?

  260. lovetox

    ok thats nice then

  261. MattJ

    Yes, unless it got lost

  262. lovetox

    too much changes, i probably missed it

  263. MattJ

    I'm planning a separate "How to MAM" document anyway

  264. lovetox

    what i want to tell is, that this is a "additional" thing on the server, you just add some different sql querys if you encounter different filters

  265. lovetox

    but for clients its not just additional

  266. lovetox

    its either you write your impl with these futures, or without it

  267. MattJ

    I agree, the sensible thing is for clients to depend on #extended

  268. lovetox

    at least i believe that, have to do it :)

  269. lovetox

    ok correct MattJ so from a client perspective this is the same as depending on mam:3

  270. lovetox

    so from a client perspective this is the same, and optional not useful here

  271. lovetox

    so the question remains, is it useful for the server?

  272. MattJ

    Not really, no

  273. MattJ

    I don't see any reason for people to only implement 80% of the XEP

  274. Zash

    We already implement 80% of the XEP, because those 80% was 100% of the previous version of the XEP.

  275. MattJ

    Obviously

  276. MattJ

    But whether it is called #extended or :3 it makes no difference - people need to upgrade

  277. jonas’

    the difference is that you can re-use your code from :2

  278. MattJ

    I mean it makes no difference to whether people implement it or not

  279. lovetox

    i dont know the process but is that code discussion really something the XSF should care about?

  280. Guus

    Skipping over a lot of the conversation here: but is the flip-page directive something that adds real value? To me, it seems like a convenience for clients to not have to revert element orders if they want to. I wonder if that warrants added complexity to the protocol.

  281. lovetox

    Guus you cant invert the order

  282. MattJ

    Guus: that's a debate to have with lovetox and some others... you can bring it up on the list when I post it I guess

  283. jonas’

    you can, you just need to buffer the (MAM) stanzas first.

  284. jonas’

    but on-list is a better place for this indeed

  285. lovetox

    thats a fundamental change to how clients work jonas’

  286. lovetox

    we dont do that for literally anything

  287. Zash

    Do you know how <before/> is implemented in Prosody? ... by buffering the results and then flipping them.

  288. MattJ

    To how your client works :)

  289. lovetox

    stanzas are processed when they arrive

  290. Guus

    flip-page is only about order of elements in one RSM result, right?

  291. MattJ

    Guus: yes

  292. lovetox

    Guus a RSM page has usually 100 stanzas

  293. flow

    Hmm, then shouldn't something like flip-page be part of RSM instead?

  294. Guus

    ... not seeing the problem - unless the RSM pages are ungodly huge.

  295. Guus

    so - reduce the RSM size?

  296. lovetox

    then mam catchup is much slower ?

  297. flow

    Guus, I think something like flip-page really adds value over low latency connections

  298. MattJ

    flow: I considered that, but I don't want to bump RSM ;)

  299. flow

    MattJ, optional extension?

  300. Zash

    If you're doing infinite scroll and scroll up?

  301. Guus

    Okay, if it has real world benefits I'm happy to include it. Seems far-fetched to me, but then again, I'm no client builder 🙂

  302. lovetox

    also this means i have to download a 100 stanzas, before i can show the user the first

  303. lovetox

    seems like just not a good protocol

  304. jonas’

    slow connections is a valid point

  305. Guus

    Nah, just limit the max result set page size to 20 or somesuch?

  306. lovetox

    then you wait for 20 ..

  307. jonas’

    in other RSM cases it’s not as relevant (cc @ MattJ) because normally you get an RSM result page in a single stanza

  308. flow

    err, I meant high latency connections obviously

  309. Guus

    The entire point of having a page is that it offers a manageable bite size of data.

  310. jonas’

    Guus, then you have expensive round-trips. Flipping the result makes a lot of sense here.

  311. MattJ

    jonas’: yeah

  312. jonas’

    MAM is a splendid bulk operation from the client side

  313. flow

    but thinking about it a little more, I am actually not that sure if it adds value

  314. flow

    those 20 stanzas are all bundled

  315. jonas’

    Guus, especially on long-fat-links (high latency, lots of throughput) you want few roundtrips and lots of data. quite a bit of mobile links these days are like that, especially when you’re on the road: your packets are buffered somewhere and then you get a bunch of them back. roundtrips are expensive.

  316. flow

    and what's typical stanzas size? how long does it really take to receive 20 stanzas?

  317. jonas’

    flow, they don’t fit in a single TCP segment, so it can take arbitrarily long for the last (first) stanza to be delayed while you already have 19 others

  318. flow

    true, if you not only have high latency but also packet loss

  319. jonas’

    or irregular high latency

  320. jonas’

    as you have on mobile links

  321. Guus

    I'm not dead-set against this - but how is this now a problem, and not in the past 10 years? Connectivity has improved, generally...

  322. jonas’

    you sometimes see sudden RTTs of 60s!

  323. jonas’

    Guus, it’s always been a problem

  324. flow

    as I said, I think <flip-page/> is a prime candidate of an optional feature. Not everyone may want or needs to implement it

  325. jonas’

    clients are just "crap" and sync from oldest messages first and not from newest first

  326. jonas’

    probably also because of stuff like this

  327. flow

    Guus, I'd argue bad connectiviy is probably more widespread

  328. jonas’

    when you sync from oldest, it doesn’t matter, but it’s also terrible UX

  329. flow

    if you think about all those smartphones in africe

  330. flow

    if you think about all those smartphones in africa

  331. jonas’

    or germany

  332. Guus

    oh well. I'll take your word for it 🙂

  333. jonas’

    once you’re in an intercity train

  334. Guus

    #stayhome

  335. Guus

    (problem solved)

  336. Guus

    no wait, my parents' wifi.

  337. MattJ

    As far as I'm concerned it adds minimal value, but it makes lives for some people easier, so I'm fine with including it

  338. lovetox

    Sorry this is a messaging protocol and we discuss if its too much to ask from a archive to get the messages in the order you want them

  339. lovetox

    seriously lol

  340. lovetox

    download the archive and reverse them yourself

  341. lovetox

    ok

  342. MattJ

    lovetox: you just want SQL replication over XMPP ;)

  343. Guus

    no, we're discussing if adding a feature that I thought was trivial to implement in code warrants added complexity in the protocol

  344. jonas’

    MattJ, don’t confuse lovetox with zinid

  345. Guus

    that is a relevant discussion, especially in a standards body.

  346. Zash

    MattJ: You mean XEP-0136

  347. lovetox

    Guus, its the simple use case, of loading messages while you scroll upwards in your messenger

  348. lovetox

    just think from a client point of view how you want to implement that

  349. jonas’

    MattJ, is the auto-pull of xeps working again?

  350. lovetox

    this is not someting exotic, ANY user expect the client to do this

  351. lovetox

    in a efficient fashion

  352. Guus

    lovetox as I already said: I'm happy to accept that this is less trivial as what I thought it was, going into this discussion.

  353. MattJ

    Most XMPP alternatives will be using HTTP and JSON. Trust me, they don't start displaying results until they receive the full result set from the server

  354. jonas’

    MattJ, but that also means that they can handle latency spikes much better, since they have regular TCP restarts instead of having to deal with a TCP recovering from a minute of packet loss

  355. Zash

    Did someone say BOSH?

  356. MattJ

    jonas’: I'd be surprised to see anyone using a TCP connection per request these days

  357. jonas’

    MattJ, I wouldn’t be surprised for them restarting a fresh TCP connection when the other one runs in a timeout

  358. jonas’

    when you do that with XMPP, you’re in a world of massive pain

  359. jonas’

    unless you’re very clever, but nobody wants to be that these das

  360. jonas’

    unless you’re very clever, but nobody wants to be that these days

  361. jonas’

    (start a new session, SM-resume your other, suppesedly timed-out stream with your current local counters, discard the other stream once you got the resumption ACK)

  362. flow

    ahh muc-presence-versioning now in html, nice

  363. flow

    hmm, or not?

  364. jonas’

    I pushed the docker image, no idea if the pull is working

  365. jonas’

    hence 18:36:31 jonas’> MattJ, is the auto-pull of xeps working again?

  366. MattJ

    It's not

  367. pep.

    flow, "specifying something as mandatory does not mean that implementations will suddenly implement it" I totally agree. And I don't think this applies "we shall then make features optional". At least making something mandatory would tell implementors that these features are important

  368. jonas’

    MattJ, can you issue a manual pull then please?

  369. jonas’

    or, has board already decided about my iteam membership? ;)

  370. MattJ

    When I get back to my laptop, in an hour or however long it takes children to go to bed

  371. jonas’

    pep., I’m more in favour of having documents which give a rationale for the importance of a feature, instead of just relying on the MUST hammer

  372. jonas’

    MattJ, kthx

  373. jonas’

    say hello from the strange internet parrot people

  374. MattJ

    :)

  375. flow

    pep., why not simply tell the implementors that these features are important instead?

  376. pep.

    Well that's how you tell them it's important

  377. pep.

    "Ah btw that's what 90% of clients are going to use nowadays, but if you don't implement it it's fine don't worry"

  378. pep.

    Is how I see the optional thing

  379. flow

    pep., again, then why not simply tell the implementors that these feature are important to preven this?

  380. flow

    pep., again, then why not simply tell the implementors that these feature are important to prevent them from getting that impression?

  381. pep.

    Suggestion for this year's CS, add namespaces to be supported. So that people don't claim they support mam:0 (or whatever NS that nobody uses anymore) and be done with it

  382. lovetox

    and then add it to the compliance suite :D

  383. lovetox

    if i think about thats actually what i care for

  384. lovetox

    i want the server to know what they should implement

  385. lovetox

    and thats my fear that optional things get only implemented if i personally bug every server dev

  386. pep.

    yep

  387. lovetox

    so yes if we have a document that tells the server dev what he should actually implement to have a relevant impl, then i guess im fine with the XEP not mandating it

  388. jonas’

    in contrast to that, I bet you’ll find every mandatory thing of '45 or '60 implemented in all servers

  389. pep.

    hah

  390. flow

    otherwhise your fear would be that that big monohilitc everything-is-mandatory spec does not get implemented at all, or only partly (which would cause a lot of "fun")

  391. pep.

    Well quite a lot of MUSTs or SHOULDs are behind optional features

  392. jonas’

    discoverable partial support is better than only finding out about lack of support the hard way

  393. pep.

    flow, it's fine if the thing is still usable

  394. pep.

    But it's useless if it isn't

  395. jonas’

    which can either be a <service-unavailable/> / <feature-not-implemented/> (if you’re lucky), or different behaviour because an element was ignored.

  396. flow

    pep., I am sorry pep, but I can't follow

  397. pep.

    "I implemented all the mandatory bits! No clients can use my implementation!"

  398. pep.

    (all and only*)

  399. jonas’

    MattJ, poke

  400. Neustradamus

    Two "Version 1.0.0 of XEP-0363" in next Newsletter

  401. MattJ

    jonas’, done

  402. !XSF_Martin

    k