XSF Discussion - 2020-02-13


  1. jubalh

    I just saw in Profanitys code that it actually only sends request receipts if the capabilities of the other client support this. We had a similar discussion about LMC yesterday. So I think this is wrong and should actually always send them (if enabled) because we dont know which client the other user uses. Correct?

  2. Holger

    +1

  3. jubalh

    I will look out for more such cases now :)

  4. pep.

    I'm quite torn with this "send everything anyway" policy tbh. I understand why, but then I feel that forces us to come with ugly "fallback" things that I don't like, "because some clients don't support what we send"

  5. jubalh

    hmm but it wont hurt them?

  6. jubalh

    It will just be some more data send and they wont parse it. and if they are connected with another client they still get the + there

  7. pep.

    I'm not happy about the fallback things, not about the "too much" :P

  8. pep.

    But that's also an argument for some I guess, "too much"

  9. jubalh

    what do you mean by fallback?

  10. Zash

    Having this feature negotiation was one of the big things that makes XMPP better than email. And now we apparently don't have it anymore :(

  11. MattJ

    I know some kind of "user capabilities" was discussed at the summit (some kind of merging of device capabilities)

  12. MattJ

    I'm not really a fan of that idea though

  13. Ge0rG

    It would be great to be able to loudly proclaim that I'm incapable of OMEMO, no matter what some clients of me claim.

  14. MattJ

    That's easily done today

  15. jonas’

    is it?

  16. jonas’

    because I want that

  17. jonas’

    but LTIC it wasn’t possible because Conversations won’t trust anything the server could’ve said.

  18. pep.

    You need to remove every keys yeah, and even then the sender needs to disable e2ee because it's on by default, otherwise they get a "Failed to send" or sth :/

  19. jonas’

    and prevent clients from re-publishing keys

  20. jonas’

    and prevent clients from using cached keys

  21. flow

    that's the thing with e2ee, there is no way to disable it has been enabled once. at least not without making downgrade attacks easier

  22. flow

    that's the thing with e2ee, there is no way to disable it, after has been enabled once. at least not without making downgrade attacks easier

  23. jonas’

    I haven’t enabled it though.

  24. pep.

    you "have", unwillingly :p

  25. Ge0rG

    flow: did you just do LMC?

  26. jonas’

    a client did that without asking me

  27. pep.

    yeah that

  28. Ge0rG

    jonas’: how dare you installing post-modern clients?

  29. jonas’

    I’m not into non-consensual non-consensual stuff.

  30. Ge0rG

    "no means no!"

  31. jonas’

    Ge0rG, I needed multi-account support and stuff

  32. Ge0rG

    there is a v6 fork, why not also a NOMEMO fork?

  33. dwd

    jonas’, Should we be doing anything with XEP-0429, like Last Calling it?

  34. jonas’

    dwd, yes most definitely

  35. jonas’

    lost track of that one

  36. jonas’

    can you add it to the SoD?

  37. dwd

    jonas’, Done.

  38. jonas’

    thx

  39. ralphm

    Sorry, I have to skip today. Work.

  40. MattJ

    No worries

  41. pep.

    !

  42. flow

    Ge0rG, no, my poezio-fu is not strong, I always assume that it does LMC if I just select the messagen from history, modify it and sent it

  43. flow

    Ge0rG, no, my poezio-fu is not strong, I always assume that it does LMC if I just select the message from history, modify it and sent it

  44. flow

    but I am learning

  45. Ge0rG

    flow: it doesn't.

  46. Ge0rG

    flow: I was actually worried that you used a client that generates LMCs that neither of my clients can parse

  47. pep.

    Trello has nothing for us, I still haven't sent stuff I wanted to discuss (my fault, and I don't want to hijack board meetings to discuss new ideas, that goes on list.), I guess this meeting if it happens is going to be quick

  48. pep.

    Seve, Guus?

  49. MattJ

    I'm fine with skipping

  50. Guus

    connectivity issues

  51. pep.

    A wild Seve appeared a few minutes ago in another channel.

  52. Guus

    my internet connection is flaky

  53. Guus

    I don't mind skipping a week

  54. Seve

    Yes, sorry

  55. Seve

    Very much on the same page as you guys

  56. pep.

    Nothing to add to the agenda then?

  57. Seve

    Thanks for the ping pep. Btw :)

  58. pep.

    Ok. See you next week. /me warps back into the nothingness

  59. Ge0rG

    nothinglessness?

  60. winfried

    Has anyone played with this: https://products.office.com/en/business/microsoft-kaizala or analysed it? I spoke a representative of Microsoft Netherlands and he told it is a recently acquired by MS and that it is XMPP based. He seems to be willing to start an internal lobby in MS to give it an external XMPP interface.

  61. MattJ

    Not familiar with it, no

  62. Ge0rG

    winfried: apparently it's included in my o365 subscription, and the first thing it asks for is my mobile number

  63. winfried

    Ge0rG: :-s listening to the discussion I already had the impression they would some strange things with identity....

  64. winfried

    I don't have an o365 subscription, so I couldn't test / debug it...

  65. Ge0rG

    I'm not sure I should try it.

  66. moparisthebest

    didn't microsoft just kill their (already optional) xmpp interface for "skype for business"

  67. dwd

    moparisthebest, That was, IIRC, hanging about primarily to support mandatory XMPP usage inside US (and other ) militaries.

  68. moparisthebest

    https://docs.microsoft.com/en-us/skypeforbusiness/migration/migrating-xmpp-federation

  69. moparisthebest

    > The XMPP functionality is no longer available and is deprecated in Skype for Business Server 2019.

  70. winfried

    moparisthebest: probable, the representative wasn't sure if the higher gods would decide to rewrite kaizala to something non-XMPP :-(

  71. dwd

    I wonder what the API and action card stuff looks like.

  72. Ge0rG

    winfried: first thing the app asks for is phone book access.

  73. Ge0rG

    it looks a bit like Conversations. But maybe all IM apps do?

  74. winfried

    Ge0rG: *sigh* they are all the same... https://github.com/M66B/XPrivacyLua/blob/master/README.md

  75. winfried

    Ge0rG: thanks for looking BTW...

  76. Ge0rG

    winfried: they have some really interesting (read: weird) social aspects. You can not create a group without access to the phonebook.

  77. Ge0rG

    There are three ways to find existing groups: by your location (nearby); by QR code and by a numeric(?) code

  78. Ge0rG

    oh, public groups are in the "discover" tab

  79. winfried

    Ge0rG: I guess they use the phone number as some kind of user id. An idea that was fortunately rejected already. :-D

  80. Ge0rG

    winfried: looks like they are indeed.

  81. Ge0rG

    there are 4.5k users in the Office 365 tech room

  82. Ge0rG

    I'm pretty sure they aren't using MUC for that

  83. winfried

    Interesting!

  84. Ge0rG

    Also looks like many Indians in there. And things like "how do I get rid of this group" ;)

  85. winfried

    It is build in India, became populair in India and China and was purchased by MS

  86. winfried

    They want to have a whatsapp killer

  87. mohamad

    🌷

  88. moparisthebest

    flow: since quic supports network roaming across the same connection I'm not sure it'd make sense to smacks over it, I haven't put a ton of thought into it though

  89. Zash

    MPTCP is apparently in the next Linux version, so maybe we can have that without reinventing the entire stack from scratch