XSF Discussion - 2018-11-30

  1. moparisthebest

    edhelas: wasn't it Dutch police that literally just did that

  2. daniel

    btw I think it was a good thing to split up the MIX specs

  3. daniel

    makes reading and understanding the important parts easier

  4. Kev


  5. Kev

    daniel: I think that repeater JID (I forget what we call it) in MIX can actually fully repeat PEP if it chooses to, can't it?

  6. Kev

    Ah, except the MIX room isn't 'both' in the user's roster, so won't be triggering +notify. Hrm.

  7. Kev

    Maybe they should be 'both', then?

  8. daniel

    there is a repeater jid?

  9. daniel

    the presence subscription will go to the channel jid

  10. daniel

    and then the channel could do something with it

  11. daniel

    however i think it might be better if my own account deals with the subscriptions. because my account (by looking at the participant node) knows what people i already have in my roster and with what other people i might be in two different rooms with

  12. Kev

    I don't remember where the JIDs are specced since the split, hang on.

  13. Ge0rG

    Proxy JID

  14. Kev

    Where the rooms are JID visible and you have each other in your rosters, this is all straightforward.

  15. daniel

    what about room jids visible and not in each others roster

  16. Ge0rG

    What about restricting which PEP nodes you want to make accessible to other MIX participants?

  17. daniel

    isn’t the access model we already have for pep enough?

  18. daniel

    also i'd be happy if we can get that subscription managment mess sorted out before i think about acl

  19. Zash

    PEP+ has everything you could ever want

  20. pep.

    At your service

  21. Ge0rG

    Are there problems that are not solved by forwarding all PEP request sent to the proxy JID to the real JID?

  22. Zash

    Prosody 0.11 does that trough MUC now πŸ˜‰

  23. flow

    reads like a fantanstic sprint you had, congrats everyone :)

  24. daniel

    Ge0rG, my problem is not about 'reaching the jid' but about managing subscriptions to it

  25. pep.

    Lots of ways to improve as always but it was great yeah. Thanks jc for organizing it

  26. Ge0rG didn't write a single line of code at the sprint

  27. pep.

    Here you go, we always need a percentage of people slacking off.

  28. Ge0rG

    So I'm the bad guy, as always.

  29. pep.

    Thanks for volunteering

  30. Ge0rG

    It's my favorite task assignment. Can I have it in writing please, in case anybody complains about me being rude again.

  31. daniel

    We have a xep that allows muc clients to join a mix channel. Wouldn't it be cool if the mix account thing could also join us in a muc? So from a client perspective we only ever speak mix?

  32. daniel

    This could then be merged with the account joins muc concept that some people have been thinking about

  33. Zash

    An upgrade path with smaller steps might be easier to get done, yeah

  34. Zash

    In theory the account-based-muc thing could transparently translate to MIX

  35. Zash

    Probably with some painful tradeoffs, but smaller steps are easier to take πŸ™‚

  36. lovetox

    daniel are you working on implementing mix?

  37. daniel

    I'm working on *reading* mix

  38. daniel

    It's only been a couple of hours

  39. lovetox

    i would be interested to develop against some server that has maybe even some basics of mix implemented

  40. lovetox

    i remember ejabberd once had a module or not?

  41. Zash

    Has the rate of change slowed down enough that MIX won't change under your feet while you're implementing?

  42. daniel


  43. lovetox

    with the rate of xeps that make it to draft these days, i guess this is as far as it will ever get

  44. Ge0rG

    > Wouldn't it be cool if the mix account thing could also join us in a muc? Awesome idea!

  45. edhelas

    I have a question regarding https://xmpp.org/extensions/xep-0085.html#bizrules-gen

  46. edhelas

    this says that you should not send chatstate if the other client doesn't supports it in his capabilities

  47. edhelas

    what about sending messages to the bare jid ?

  48. Link Mauve

    You can’t know. Before, we implemented resource locking, but it’s been considered deprecated for a while so we switched to ignoring this text in 0085.

  49. edhelas

    so basically I can simply close https://github.com/movim/movim/issues/158 as a wontfix :p

  50. Ge0rG

    edhelas: yes. Burn resource locking with fire

  51. daniel

    yeah i mean at least in mucs it breaks apart anyway

  52. Ge0rG

    edhelas: because Carbons will be emitted to other clients which well might support it (or vice versa)

  53. edhelas

    happy to close a 2 years bug with a wontfix \o/

  54. Ge0rG just today wontfixed a yaxim issue from 2011.

  55. Guus

    dwd, you around? a one-on-one with you gives me errors

  56. Guus

    nor are you in open_chat, where our weekly festivities are about to commence πŸ™‚

  57. Neustradamus

    New ticket about jabber.org dh key too small: https://github.com/stpeter/jabberdotorg/issues/6

  58. Ge0rG

    Stop the presses! Inform the government! 😁

  59. Neustradamus

    Ge0rG: the main XMPP server of the World must to be an example ;)

  60. Zash

    Neustradamus: Conversations.im ? :P

  61. moparisthebest

    Neustradamus, hmm doesn't say how long it was though...

  62. Zash

    It's using 1024 bit DH parameters

  63. Zash

    Recent OpenSSL is rejecting that

  64. moparisthebest


  65. Zash

    ECDHE should work fine, if you trust that kind of dark elliptic magic.

  66. Ge0rG

    Reminds me of my gradle refusing to download dependencies when running under Java 7

  67. Neustradamus

    Guus: https://mail.jabber.org/pipermail/operators/2018-November/thread.html -> A guy speak about my tickets of XMPP.net Have you looked the problem since this moment?

  68. guusdk

    Neustradamus: yes, part of the problem was solved, the others are being looked at by iteam.

  69. Guus

    (what my alterego said)

  70. Neustradamus

    Guus: guusdk Nice, do not hesitated to update all the tickets...

  71. Neustradamus

    xmpp.net has last xmppoke version?