XSF Discussion - 2023-05-29


  1. Zash

    singpolyma, I thought JSXC and Dino were looking in that direction

  2. Zash

    https://www.jsxc.org/blog/2021/08/31/A-group-call-proposal.html talks about SFUs

  3. edhelas

    singpolyma what is SFU ?

  4. edhelas

    Ah yes I see

  5. edhelas

    In Movim I'd like to find some funding to implement group call this year

  6. goffi

    singpolyma: MUJI and SFU are both planed in Libervia with the grant I'm currently working on. Don't expect them before a couple of month though.

  7. goffi

    Btw, I know that there is a lot of legacy here and the Jingle stack predate webRTC and all, but I've seen severals bugs related to mapping between SDP and Jingle, would not it be better to somehow send the SDP directly to peers?

  8. goffi

    The stack is complicated with many specifications, it's really easy to make it wrong here.

  9. MattJ

    Past discussion: https://logs.xmpp.org/xsf/2023-01-18?p=h#2023-01-18-26f7ca05f3e728a0

  10. goffi

    oh ok, thanks MattJ

  11. Dele Olajide

    >goffi : would not it be better to somehow send the SDP directly to peers? I susggested this a while back and the idea was shot down in flames. There has since been another proto XEP for this https://xmpp.org/extensions/inbox/jingle-sdp.html

  12. emus

    *GSoC 2023 & XMPP: Kickoff call* 30 May 2023, Tue, 4pm CEST https://teamjoin.de/GSoC2023-XMPP-Kickoff No need for video, if not wanted

  13. singpolyma

    goffi: do you have plans on how to use the SFU or how to communicate with it, or is this more of a "will look into it when I get there"? I've been looking at a few myself and trying to decide what the best way to do it is, and if it fits well with muji etc is why I'm asking

  14. goffi

    singpolyma: more like will look into it when I get there. I guess your best bet at the moment is larma, we had a talk at the summit about it, he mentioned the work of Matrix on a SFU that maybe could be used with XMPP. Otherwise my initial plan was to use Jitsi one, but I'm not yet into it

  15. goffi

    also I was planning to implement COLIBRI, but it seems that it's not used anymore.

  16. MattJ

    The Tigase folk were working with one IIRC

  17. singpolyma

    goffi: colibri is which?

  18. singpolyma

    JSXC blog post seems to have used SFU in an un-integrated way, which is most expedient for a prototype but needs a change to interop with anyone

  19. MattJ

    The Jitsi one: https://xmpp.org/extensions/xep-0340.html

  20. singpolyma

    Ah, ok. I will read this xep. I guess this is how jitsi worked at the time of drafting, basically?

  21. MattJ

    Yeah

  22. singpolyma

    While I'm speaking about Muji, I'm a bit concerned that it probably fails catastrophically if you join the MUC with the same nick from two clients

  23. MattJ

    Around FOSDEM time there was some talk about updating it to match the current implementation, but I don't think anyone has worked on that yet

  24. moparisthebest

    > Security Considerations: Pending ☠️

  25. moparisthebest

    Anyway seems like implementing non e2e group calls when all current calls are e2e would be an expectation mismatch for users and a huge step backwards, why not go e2e from the start?

  26. singpolyma

    moparisthebest: calls will all be e2ee usually

  27. singpolyma

    Because of WebRTC

  28. moparisthebest

    singpolyma: the SFU is not an end though

  29. singpolyma

    Well, I guess it depends if your SFU strips and re-encrypts or not. Which depends what features you need. The simplest SFU would be e2ee

  30. singpolyma

    But more advanced ones (with speaker detection etc) might not be

  31. moparisthebest

    In 2 seconds of searching here are a few technical details about zoom's implementation https://www.kaspersky.com/blog/rsa2021-zoom-end-to-end-encryption/40562/

  32. moparisthebest

    Probably should find that talk if it's available...

  33. Zash

    Didn't Jitsi have some e2ee stuff too?

  34. singpolyma

    Yes, jitsi has e2ee as an option

  35. singpolyma

    Looks like livekit is actively working on e2ee as well

  36. moparisthebest

    So it'd be pretty embarrassing if a bunch of good XMPP clients rolled out support for group chats but they weren't e2e 😬

  37. larma

    Jitsi isn't using COLIBRI anymore btw

  38. larma

    Jitsi Meet isn't using COLIBRI anymore btw

  39. larma

    They did an entirely new version and at some point dropped support for COLIBRI.

  40. singpolyma

    Yeah, if we could get actual jitsit meet compatibility it would be very neat, but I expect that involves a lot more than speaking the same protocol as their SFU, not sure.

  41. moparisthebest

    And really, what's the point when jitsi can and will just change it all out from under us at some arbitrary point in the future?

  42. goffi

    larma: weren't you mentioning, when we talked at the summit, some work from Matrix on a SFU that could potentially be used with XMPP too?

  43. mjk

    jitsi meet compat could only be thought of as bridging to a silo that has some fundamental protocol compatibility, but not syntax-level

  44. mjk

    and even that is optimistic, imho

  45. mjk

    we'll see what DMA brings, I guess? jitsi probably would want to be compatible with some cross-silo megastandard for calls

  46. moparisthebest

    > jitsi meet compat could only be thought of as bridging to a silo that has some fundamental protocol compatibility, but not syntax-level Sounds right, what I was trying to say is if whatever jitsi is doing makes sense for XMPP and it would end up being compatible that would be nice, but going out of the way to do it is just wasted effort

  47. MSavoritias (fae,ve)

    are they even interested to standardize what they are doing or is it only from us the interest?

  48. MSavoritias (fae,ve)

    (besides the xep from 2 years ago)

  49. mjk

    MSavoritias (fae,ve): seems to be one-sided, but (iirc) larma should know more

  50. larma

    Yes, they mad explicit that they don't care about interoperability with other clients and will unilaterally change their protocol when they see fit.

  51. larma

    Yes, they made explicit that they don't care about interoperability with other clients and will unilaterally change their protocol when they see fit.

  52. moparisthebest

    Unless things have changed, the last I read about it was their comment on a Conversations issue on GitHub that the only interest jitsi has in interop is for Conversations to "embed jitsi in a webview" so none at all... Now I think someone in here said they talked to jitsi folk after and they might be more willing, but until I see action or at least writing I'm skeptical

  53. MSavoritias (fae,ve)

    So we should get advise from them but other than that i dont see why we should strive to be compatible 🤷

  54. MattJ

    MSavoritias (fae,ve), one reason is so we can use their SFU, which is already in use in XMPP-Jingle contexts

  55. MSavoritias (fae,ve)

    Yeah that sounds good. Hence the "ideas" part

  56. MSavoritias (fae,ve)

    Just like we should look at matrix too imo

  57. MattJ

    Sure

  58. MattJ

    It's not something we *have* to do, but they expressed an interest in working on updated XEPs, so I think it's not an option to rule out

  59. MattJ

    But I doubt they're going to put effort into standardization unless there is some interest in the community

  60. MattJ

    If everyone decides to use something else it would be a waste of time to document the new Jitsi stuff

  61. MSavoritias (fae,ve)

    Sure

  62. singpolyma

    It's interesting that both SFU things I've seen so far (colibri and jsxc) basically place a multiparty call inside a MUC whereas Muji turns the MUC into a call. I guess this is because advanced SFU features work best if everyone on the call uses the same one so there is desire to use it that way

  63. MSavoritias (fae,ve)

    reading the matrix spec it does also a call inside a group

  64. MSavoritias (fae,ve)

    but it restricts it to one call per room only

  65. MSavoritias (fae,ve)

    but i also has the option to make the call the room

  66. MSavoritias (fae,ve)

    which i think would be a good idea to do in the xep

  67. singpolyma

    The downside of the "the MUC is the call" approach with Muji is I don't see how it could possibly work for users with multiple clients. The clients will fight over which one is in the call (or possibly over if the user even supports being in the call at all)

  68. moparisthebest

    Now that I think about it I've never tried to join a voice/video call from more than one device, I wonder how widely supported that is anywhere

  69. singpolyma

    Though I guess if you implement colibri where everyone who wants to join the call does jingle with the MUC JID that is also a version of "the MUC is the call" without this issue

  70. moparisthebest

    I agree it'd be nice to have though

  71. MSavoritias (fae,ve)

    cant you have multiple devices join at the same time?

  72. MSavoritias (fae,ve)

    i see that also as a nice thing to have

  73. MSavoritias (fae,ve)

    mutliple devices / same account

  74. MSavoritias (fae,ve)

    mutliple devices with same account

  75. singpolyma

    It's smelling to me kind of like the main thing from a client PoV is supporting multiple audio/video streams for someone you are doing Jingle with (not assuming 1 for audio or 2 for AV) and then details on SFU or not or which is possibly not even a client concern. Though you'd want some way also to "nickname" different streams -- probably we have that in jingle already just unused? So that different people can have their name on their stream even if you "aren't doing jingle with their jid" or whatever

  76. singpolyma

    MSavoritias (fae,ve): yeah, just with Muji it won't work at a technical level that's all

  77. singpolyma

    unless every device uses a different nickname in the MUC, which is not the norm

  78. singpolyma

    So you get a footgun like "join call in client X, join same MUC just to chat from client Y, call drops in client X"

  79. MSavoritias (fae,ve)

    matrix basically adds a device_id to the join form

  80. MSavoritias (fae,ve)

    and all device_ids are hold under the jid

  81. MSavoritias (fae,ve)

    and all that is under an event that is published

  82. MSavoritias (fae,ve)

    so we could add a identification for the calls from each device the person has. (that for the nickname of different streams)

  83. singpolyma

    oh yeah, jingle has content@name which we can use for stream nicknames, I thought there must be something

  84. MSavoritias (fae,ve)

    and i was looking at the wrong msc. they decided to split it. let me see..

  85. MSavoritias (fae,ve)

    The matrix one seems way too over engineered..

  86. MSavoritias (fae,ve)

    So probably not that good of an inspiration imo