XSF Discussion - 2023-01-05


  1. qy

    ugh i remember that too now, i don't think i've even solved that entirely correctly yet

  2. MattJ

    qy, there shouldn't be anything for a client to solve these days

  3. MattJ

    It is weird how they end up in MAM but won't be Carbon'd though

  4. MattJ

    But everything about MUC PMs is weird

  5. qy

    it's the differentiation between muc and pm, which i don't think i've done robustly, i thought of an edge case this morning but i can't remember it now

  6. pep.

    While we're on MUC PMs. While I agree MUC PMs are weird and I'd rather use direct messages, I'm always hesitant to say "Don't use them, just use direct chat messages". First because semi-anon rooms are still a thing so in practice it doesn't work, not everybody knows everybody else's JIDs. And then, why should they? (know everybody else's JIDs). There's still some unresolved things I find about having separate identities on XMPP. Creating yet another account isn't also very practical (even though it may currently the best way to have separate entities) :/

  7. MSavoritias (fae,ve)

    Ideally in my opinion it shiuld work like this in semi anon rooms: 1. Person wants to message another person privately in a semi annon room. They click a button or type pm and then the nickname if the person. 2. In the background the client creates a new ephemeral xmpp id and creates a room for tne two people linked to the previous room optionally. 3. Both people are dropped in the room with their temporary xmpp ids. When they leave the room the xmpp ids are automatically discarded and the room destroyed.

  8. MSavoritias (fae,ve)

    Ideally of course. This requires burner jids to be implemented too

  9. MSavoritias (fae,ve)

    Which should be the default for semi anon rooms anyway imo

  10. jonas’

    that seems more clunky than even normal MUC-PMs on first sight (especially in the multi-client scenario), what's the advantage?

  11. pep.

    While we're on MUC PMs. While I agree MUC PMs are weird and I'd rather use direct messages, I'm always hesitant to say "Don't use them, just use direct chat messages". First because semi-anon rooms are still a thing so in practice it doesn't work, not everybody knows everybody else's JIDs. And then, why should they? (know everybody else's JIDs). There's still some unresolved things I find about having separate identities on XMPP. Creating yet another account isn't also very practical (even though it may currently be the best way to have separate entities) :/

  12. mathieui

    Burner JIDs are cumbersome, though I would like to see them used one day

  13. MSavoritias (fae,ve)

    Hmm. I was thinking that this way there is a room and actual jid/xmpp ids involved. Instead of inline things in tne chat going to nicknames

  14. mathieui

    having to restart a new session for each JID is a pain from a client perspective, frankly

  15. MSavoritias (fae,ve)

    So the seperation is clearer

  16. mathieui

    especially if you want to go the 1 JID = 1 MUC route

  17. pep.

    mathieui, all that handled transparently for the user yeah :P

  18. MSavoritias (fae,ve)

    > mathieui: > having to restart a new session for each JID is a pain from a client perspective, frankly I wonder if that would be solved with xmpp over quic

  19. pep.

    I don't think the transport changes anything here

  20. jonas’

    MSavoritias (fae,ve), but I would cut out a room in that case, if it's just 1:1

  21. mathieui

    you still need to do SASL everytime

  22. jonas’

    let the participants use burner JIDs on both ends and have a 1:1 communication, without a MUC inbetween.

  23. jonas’

    that works much better with multi-client setups (even though I have no clue how burner JID + multi-client could work)

  24. MSavoritias (fae,ve)

    Ah yeah. Sorry i meant room in the matrix way 😅

  25. jonas’

    I see

  26. mathieui

    I would rather have something like wrapped payloads inside the main session

  27. MSavoritias (fae,ve)

    Yeah for sure. 1:1 chat i agree

  28. singpolyma

    That would reveal your domain

  29. qy

    i still don't see what the benefit of burner jids is here

  30. jonas’

    then you just have to figure out how to do multi-client burner JID in a way that admins are not incentivised to block those from s2s communications (as you are with SASL ANON)

  31. qy

    they're useful, but not for MUC PMs

  32. jonas’

    and we're good to go

  33. pep.

    singpolyma, burner jids still are on the same domain anyway right? It's a given that your domain is revealed

  34. MSavoritias (fae,ve)

    > qy: > i still don't see what the benefit of burner jids is here Because to drop two users in a 1:1 room you need to show some jid

  35. MSavoritias (fae,ve)

    To my knowledge

  36. jonas’

    pep., semi-anon MUC PMs as of today do not reveal your domain.

  37. qy

    ^

  38. singpolyma

    pep.: right. So doesn't work for the semi Anon MUC pm case

  39. mathieui

    pep., you could provide burner JIDs as a third-party service

  40. mathieui

    (I guess)

  41. jonas’

    mathieui, who would do that?

  42. pep.

    mathieui, yeah you could just like you could provide sasl anon but barely anybody does that

  43. mathieui

    buuut you end up with the same issue as anon auth services

  44. MSavoritias (fae,ve)

    Why cant the jid be completely randomized.

  45. mathieui

    which nobody does unrestricted because of abuse

  46. jonas’

    I wouldn't expect SASL ANON to ever be allowed to federate.

  47. mathieui

    MSavoritias (fae,ve), because it needs to be routed

  48. singpolyma

    > buuut you end up with the same issue as anon auth services Not if you auth to the burner service from your real jid. Same as MUC PM at that point

  49. pep.

    jonas’, I do, in controlled environments. anon.jabberfr.org is allowed on some other services

  50. jonas’

    exactly

  51. singpolyma

    Give real jid to service X, they send traffic onwards

  52. mathieui

    but then I don’t see the point of having burner JIDs if you could have MUC PMs instead

  53. qy

    exactly

  54. MSavoritias (fae,ve)

    Then we need to seperate the generation of jid and routing to what we show

  55. qy

    mathieui; exactly

  56. mathieui

    why solve hard problems when you have an easy one at hand

  57. jonas’

    MSavoritias (fae,ve), unlikely to ever happen within XMPP

  58. MSavoritias (fae,ve)

    Maybe the xmpf server the user is using can act as a proxy

  59. singpolyma

    mathieui: I think she people want jid->bare jid translation to always work?

  60. MSavoritias (fae,ve)

    Yeah probably

  61. singpolyma

    mathieui: I think some people want jid->bare jid translation to always work?

  62. MSavoritias (fae,ve)

    Do be honest though even if it leaks only the domain its still better than exposing the actual jid

  63. qy

    as in, to be stable and not depend on nickname?

  64. singpolyma

    MSavoritias (fae,ve): those are the same in my case

  65. pep.

    If, "if", we every manage to make it like MUC PMs are not a pain anymore, I'd see JIDs in MUC replaced by something like occupant-id fwiw. Even for moderators

  66. singpolyma

    And for many people

  67. jonas’

    qy, singpolyma, that's what MIX gives, fwiw

  68. pep.

    (full-anon again!)

  69. singpolyma

    lol, MIX

  70. jonas’

    proper addressing of participants

  71. jonas’

    one of the key issues with MUC which cannot be solved within MUC

  72. MSavoritias (fae,ve)

    Would mixake it easier to do pms?

  73. jonas’

    MSavoritias (fae,ve), verily

  74. pep.

    jonas’, "proper"? With the 4-in-3 thing?

  75. jonas’

    pep., well, better in any case

  76. jonas’

    done right, the 4-in-3 isn't as bad

  77. qy

    "cannot" seems strong

  78. jonas’

    qy, you'd have to redo the entire addressing scheme of MUC

  79. qy

    don't we already have several ideas for stable ids?

  80. jonas’

    you cna also do MIX then.

  81. jonas’

    you can also do MIX then.

  82. jonas’

    stable IDs are nice and all, but not if they're not JIDs

  83. jonas’

    and addressable as JIDs

  84. qy

    but they can be

  85. jonas’

    there's no concept I know of for *addressable* stable occupant IDs in MUC

  86. pep.

    They're not addressable as JIDs outside of the MUC. They could be

  87. singpolyma

    Stable IDs sort of defeats the point of an anon room, no?

  88. jonas’

    not even within the MUC

  89. MSavoritias (fae,ve)

    So either we make MUC into MIX or adopt MIX

  90. jonas’

    singpolyma, depends on your use case

  91. jonas’

    there are use cases where you want stable, but anonymous ID, and use cases where every visit should have a different ID

  92. MSavoritias (fae,ve)

    Yeah. And stable but "annon" ids also have their place

  93. qy

    no need to differentiate, as long as they remain routable, they can be changed as often as liked

  94. singpolyma

    Registered nicks then ;)

  95. jonas’

    e.g. in programming@, I'd be content with a stable identifier which cannot be mapped back by the general public to my real JID

  96. jonas’

    qy, good, make a concept for that :-). and also how resources fit into that.

  97. jonas’

    and make sure to read the corresponding MIX specs, because they have that already

  98. qy

    i've moved to the camp that prefers to update MUC rather than adopt MIX, for guessable reasons

  99. jonas’

    qy, especially then you should also look at the prior art in MIX

  100. qy

    i'm just suggesting ideas. I have no stake in this

  101. MSavoritias (fae,ve)

    If it changes that much i dont see the point of trying to redo half of how the muc works. But 🤷

  102. singpolyma

    Realistically, MUC PM has been working fine for decades and any change will have an inertial problem

  103. singpolyma

    Not that change is always bad, but yeah

  104. pep.

    singpolyma, "fine" :P

  105. singpolyma

    Much bigger problem, if it's a problem but it seems more like one, is MUC nick iq. I realize the possible solutions are similar

  106. pep.

    Maybe there should be a document that defines clearly what's wrong with MUC PMs

  107. pep.

    (if there isn't already)

  108. MSavoritias (fae,ve)

    Yeah if we change muc that much that it needs a migration path (identifiers and pms) then its a problem anyway

  109. pep.

    As a first step

  110. singpolyma

    But of course a full solution to that will probably result in many bugs that essentially leak the jid, so bah. I mean, my jid is public but as a matter of culture many expect theirs not to be

  111. jonas’

    singpolyma, "MUC nick iq"?

  112. singpolyma

    jonas’: sending an iq from one muc participant to another

  113. pep.

    singpolyma, my public JID is public, my other non-public JIDs aren't :x

  114. jonas’

    singpolyma, ah yes, that's doomed

  115. jonas’

    MIX fixes that :-X

  116. singpolyma

    pep.: do you use your public jid for joining public rooms?

  117. pep.

    jonas’, does it? There's still an issue with leaking info right?

  118. jonas’

    pep., leaking info?

  119. jonas’

    well if you reply to IQs, you need to be careful what you reply with

  120. jonas’

    well if you reply to IQs, you need to be careful what you reply with to whom

  121. singpolyma

    jonas’: does mix fix the problem where even in a non anon room the room could be lying to me about what people's JIDs are? ;)

  122. jonas’

    that's irrespective of the transport used for that

  123. jonas’

    singpolyma, no, and thinking about that hurts my head

  124. pep.

    Yeah that's a non-issue to me

  125. pep.

    For this matter

  126. singpolyma

    jonas’: yes but usually with an iq you can assume the other side knows your jid

  127. jonas’

    it becomes a significant issue when you think about MUC-OMEMO

  128. singpolyma

    Except with MUC

  129. singpolyma

    Needs more e2ea

  130. singpolyma

    Or at least s2ea

  131. pep.

    I think we can dissociate anonymity to the MUC and to MUC participants

  132. pep.

    And maybe solve these in different ways (dunno)

  133. qy

    so other than MUC IQs being a thing, i don't personally have an issue with MUC PMs as they stand, but some people would like routable stable addresses in some form; i guess that's the sum of things "wrong" at the moment?

  134. singpolyma

    A MUC could pretend to be non-anon and give out burner JIDs at a companion service

  135. jonas’

    singpolyma, indeed

  136. jonas’

    kind of what biboumi does

  137. pep.

    singpolyma, yeah I was thinking about that

  138. jonas’

    that's actually pretty smart

  139. jonas’

    but!

  140. jonas’

    the companion service would have to translate your JID somehow

  141. jonas’

    and to do that correctly, it needs context

  142. jonas’

    which can be encoded in the JID, but uh

  143. jonas’

    sounds like a fun project

  144. Kev

    Isn't that context encoding basically what MUC PMs already do?

  145. singpolyma

    It would need to know your jid, but could store in a lookup table, or salted hash it, or whatever makes sense for the use case

  146. singpolyma

    Probably gonna need a lookup either way

  147. jonas’

    singpolyma, put the JID of both occupants encrypted into the localpart of the burner JID, that should do the trick

  148. jonas’

    plus maybe a random part or hmac of the room JID

  149. pep.

    Kev, kinda? I have to admit it's not very clear to me what's the difference yet

  150. jonas’

    then you got unique IDs and routing based on the room

  151. singpolyma

    jonas’: JIDs have almost no length limit riiiiiiight ;)

  152. jonas’

    1023 bytes should be enough for that

  153. jonas’

    well, they're not

  154. jonas’

    so yeah, you need some lookup

  155. singpolyma

    But that's fine the muc already needs lookup anyway

  156. pep.

    Ok I'll have to reread this and write it down in a way that's understandable :P

  157. pep.

    Maybe I can implement it in my MUC component

  158. pep.

    Yeah it's similar to what MUC currently does because it still has to go through MUC, as opposed to burner JIDs. I don't know if it improves things compared to what MUC currently does though.

  159. jonas’

    pep., it does if we can make it so that bare JID === identity

  160. jonas’

    which is not the case in MUC currently and that causes a lot of headaches

  161. pep.

    hmm

  162. pep.

    Really someday I want to stop relying on resources for nicknames, and either use item@nick (but that's not used by other participants right? Just for nickname changes?) or 0172

  163. qy

    the funny thing is, i kinda want things to go the opposite direction

  164. pep.

    How?

  165. pep.

    (and why?)

  166. qy

    namely in biboumi, i'd ever so slightly like it to more mirror MUC PMs as things stand, but then also for the sake of consistency i'm ok with how it is

  167. pep.

    Well IRC doesn't have this concept

  168. jonas’

    pep., what is "item@nick"?

  169. qy

    yeah ofc, but my point is i'd rather solidify the state-of-affairs than create some other system

  170. pep.

    <{muc#user}x><item nick="foo"/></x>

  171. jonas’

    ah, that

  172. stpeter

    Hi all, the XSF Board meeting is starting now: https://wiki.xmpp.org/web/Board-Meeting-2023-01-05

  173. emus

    ✨✨

  174. moparisthebest

    Firefox on Android kept joining and then "error! Trying to reconnect!" But the jitsi app from f-droid worked fine

  175. pep.

    I tried twice on firefox at the beginning and gave up as it was chocking as soon as I connected :(

  176. emus_web

    Just found this via a twitter bot: https://www.gsocorganizations.dev/organization/xmpp-standards-foundation/

  177. emus

    moparisthebest: I totally forgot to offer you to speak on the Editor automation topic. Do you want to follow-up here?

  178. moparisthebest

    emus: I don't really have anything, jonas’ wants a language update I can get to soon and then hopefully it'll be ready to merge

  179. moparisthebest

    I put thoughts on the other issue in there but haven't tried to write a POC or anything

  180. moparisthebest

    Other issue being getting rid of the attic as it currently exists

  181. emus

    moparisthebest: Okay alright, thanks!