jdev - 2024-07-06


  1. MSavoritias (fae,ve)

    reading through https://xmpp.org/extensions/xep-0289.html [XEP-0289: Federated MUC for Constrained Environments] as i am interested in having a multicast based group chat thing, I also noticed that it opens with: > MUC's design generally assumes a highly reliable network providing plenty of bandwidth, and it functions well in Internet settings. It is sometimes the case that server to server traffic is heavily constrained, with typical problems for constrained links being high latency, tiny amounts of available bandwidth and unreliability (including, potentially, long-term failure of S2S links). which is exactly the specs i want to have as i have mentioned before. has these been fixed after this got published in MUC? will they be fixed in MUX?

  2. MSavoritias (fae,ve)

    reading about it also, it seems a bit of a "hack" pardon the language

  3. wgreenhouse

    MSavoritias (fae,ve): fmuc is implemented only by isode's server afaik

  4. wgreenhouse

    and mix is polling, so inefficient in a new and different way

  5. MSavoritias (fae,ve)

    i meant MUX not MIX :) the updated MUC

  6. MSavoritias (fae,ve)

    polling you mean pull not push right?

  7. MSavoritias (fae,ve)

    i do want to go for pull as much as possible but yeah it comes with different problems altogether

  8. MattJ

    I'm not sure I understand how you can get to "MIX is polling"

  9. MSavoritias (fae,ve)

    > MSavoritias (fae,ve): fmuc is implemented only by isode's server afaik hmm. that was another one of the questions i had as i was reading this yeah. meaning: is FMUC even "supported" or should i go for something else

  10. MSavoritias (fae,ve)

    i get the feeling also that 0289 assumes there is a "main" room somewhere. and everything else is just mirroring the main room

  11. MSavoritias (fae,ve)

    because of this wording > The joining FMUC node MUST NOT send the traffic generated by these data back to the joined room, but only deliver them to local participants (and in the case of chained FMUC nodes, any nodes joined to it). It also MUST NOT pass the fmuc payloads through to local clients.

  12. MSavoritias (fae,ve)

    ah and it also sends presence everywhere. never mind then probably not

  13. wgreenhouse

    MattJ: a naive reading of the spec gave me the impression that MIX is polling at least at the c2s level, which is exactly where I wouldn't want that, if MAM is essentially the only means of getting mesaages

  14. wgreenhouse

    it seems as though this will be less reliably immediate even for a client with an open connection to its server

  15. MSavoritias (fae,ve)

    MAM is not the only way according to the spec. Its the messages node > The Messages node is used to distribute messages. The Messages node is a transient node and so no PubSub items are held. Messages MUST go to the associated MAM archive and history is retrieved by use of MAM. Users subscribe to this node to indicate that messages from the channel are to be sent to them. Private Messages are not distributed by the Messages node.

  16. MSavoritias (fae,ve)

    so messages do go "live" to people

  17. MSavoritias (fae,ve)

    the transient just seems to say that they are not kept in history but instead the node is just a relay. history its MAM only

  18. MSavoritias (fae,ve)

    (unless i am reading it wrong that is)

  19. MSavoritias (fae,ve)

    coming back to FMUC this also makes it bad to deploy outside of organizations: > This allows an FMUC node to proxy for another JID, so should only be deployed in scenarios where either the FMUC nodes are trusted, or it is known that the users of an FMUC node are in the same security domain as the FMUC node itself. so yeah not for me

  20. wgreenhouse

    MSavoritias (fae,ve): it's hard for me to tell, tbh. there is no example of receiving normal message traffic that way, but lots of detail is provided for doing so via MAM

  21. MSavoritias (fae,ve)

    fair. I mean MIX is almost all theoretical afaik

  22. wgreenhouse

    I interpreted it as you might get a notification of new messages being delivered via the pubsub node, but your client woild then have to sync up with a MAM request

  23. MSavoritias (fae,ve)

    heh that would be an interesting architecture

  24. wgreenhouse

    similar to how lots of sillier protocols have a separate "push notification" stream but then your client has to do something else to get the content

  25. MSavoritias (fae,ve)

    now that i think about it some more adding distributed to MUC is a really bad idea to begin with

  26. MSavoritias (fae,ve)

    because the config and roster are not in any way shielded from interference or malice of a node

  27. MSavoritias (fae,ve)

    hmm. maybe "authenticated" actions with a signed omemo message would work. but then you basically recreated pubsub :P

  28. wgreenhouse

    fmuc assumes the same entity (namely US .mil who was the customer) runs all the fmuc servers

  29. MSavoritias (fae,ve)

    yep i saw

  30. MSavoritias (fae,ve)

    and the DMUC xeps just copy the config around. which got me to ask how MUC actually manages config. didnt want to know that really :/

  31. MSavoritias (fae,ve)

    is there any movement to make the MUC config/members list authenticated somehow and with access to specific people only?

  32. MSavoritias (fae,ve)

    i am thinking like MLS or Matrix did

  33. wgreenhouse

    looking forward to the possibility of rooms being "bricked" like we have in Matrix

  34. MSavoritias (fae,ve)

    what aspect are you referring to here exactly?

  35. MSavoritias (fae,ve)

    in the sense of how do authenticated changes lead to whatever you said

  36. Guus

    Openfire has experimental support for FMUC.

  37. MattJ

    wgreenhouse: the whole premise of MIX was "we already have pubsub which is able to broadcast stuff to a list of people in realtime, which is basically what a group chat is, so let's use pubsub for group chats"

  38. MattJ

    MAM is for catch-up, same as 1:1/MUC

  39. singpolyma

    Pubsub also has it's own history mechanism, but I guess maybe mix ignores that?

  40. wgreenhouse

    singpolyma: mix seems to specify don't use it

  41. wgreenhouse

    if that's what's meant by transient

  42. wgreenhouse

    don't use the history aspect of pubsub I mean

  43. taba

    where's the email address i send requests to for the source code of us millitary programs

  44. wgreenhouse

    I doubt there's just one. many agencies have their own open source programs

  45. taba

    :nerd-face-pensive:

  46. flow

    singpolyma, IIRC the idea was to use MAM also for pubsub (since pubsub is also message-stanza based), which is sensible IMHO, given that MAM is more powerful and flexible compare to what native pubsub provides

  47. singpolyma

    Is it? Native pubsub is pretty powerful

  48. lovetox

    mam is basically a way to give the server filter conditions

  49. lovetox

    so the more filter conditions you have the more "powerful"

  50. lovetox

    does pubsub even have filter conditions or is it just RSM?

  51. lovetox

    dont see a single filter condition, its just RSM + get me a single item by ID

  52. MSavoritias (fae,ve)

    either way it would recreating MAM in pubsub so probably not wise to do so

  53. MSavoritias (fae,ve)

    both for future advancements and for backwards compatibility

  54. Kev

    Broadcast FMUC (or broadcast based MUC, anyway) is a thing I’m interested in. I’m not sure I’d call FMUC a hack, it largely uses existing MUC protocol but to join a room to a room instead of a user to a room, so it’s fairly natural. It works pretty well for the use case it was designed for, which is not most people’s use case. Notably it doesn’t have a “main” room, and can be deployed between organisations, but there is a definite mutual trust requirement.

  55. MSavoritias (fae,ve)

    i checked the affiliated versioning also and it doesnt seem to be authenticated in any way. more of a way to reduce bandwidth

  56. MattJ

    The authentication would be the normal s2s authentication, and the mutual trust KeV mentioned

  57. MattJ

    The authentication would be the normal s2s authentication, and the mutual trust Kev mentioned

  58. Kev

    In fact, in situations you want to FMUC, you frequently want to avoid S2S even and do something like X2X instead.

  59. MSavoritias (fae,ve)

    > The authentication would be the normal s2s authentication, and the mutual trust Kev mentioned that doesnt make much sense imo

  60. MattJ

    Why not?

  61. MSavoritias (fae,ve)

    yeah my problem is what do you do in "mutually suspicious" networks

  62. MSavoritias (fae,ve)

    because we already have spam accounts

  63. MattJ

    Sure, that's harder

  64. Kev

    And yes, it‘s partly a bandwidth saving mechanism, while also being a mechanism for allowing discussion to continue on the local side when the link is down.

  65. Kev

    > yeah my problem is what do you do in "mutually suspicious" networks Yeah, FMUC is not for that environment, and something good for that environment isn’t going to be good for FMUC cases.

  66. MSavoritias (fae,ve)

    so delegating checks to servers doesnt scale really. and it will become very easy to hijack the room

  67. MSavoritias (fae,ve)

    in an open registration environment that is

  68. MSavoritias (fae,ve)

    now i you have some kind of web of trust the situation changes

  69. MSavoritias (fae,ve)

    but 1. we dont 2. it would still be nice to have an additional assurance

  70. MSavoritias (fae,ve)

    especially since we have signing already in some form

  71. MSavoritias (fae,ve)

    > > yeah my problem is what do you do in "mutually suspicious" networks > Yeah, FMUC is not for that environment, and something good for that environment isn’t going to be good for FMUC cases. makes sense. thanks for the clarification

  72. MSavoritias (fae,ve)

    i understand that not having servers to fall back to, makes things complicated

  73. Kev

    There’s lots of interesting things to do here, and not a one size solution for competing requirements.

  74. MSavoritias (fae,ve)

    my first take would be to put all config/members/metadata of the room in a pubsub node.

  75. MSavoritias (fae,ve)

    and take the permissions model of pubsub and add signing of events

  76. MSavoritias (fae,ve)

    but then you have MIX :P

  77. MSavoritias (fae,ve)

    > There’s lots of interesting things to do here, and not a one size solution for competing requirements. sure. i understand that FMUC was made for a different set of requirments

  78. Kev

    Yuhhuh.

  79. Kev

    (yuhhuh, re mix)

  80. MSavoritias (fae,ve)

    then you also lessen the bandwith because you can send only things that changed and not the whole config

  81. Kev

    I still believe in the mix model, but I don’t know how to frame it and/or tweak protocol in a way that makes sense to people.

  82. MSavoritias (fae,ve)

    i keep trying to make MUC work for me but yeah :/

  83. singpolyma

    I was a big believer in MIX when it was "let's just use pubsub" but then in grew into a monster that wasn't that anymore and MUC already exists if I want something like that

  84. MSavoritias (fae,ve)

    i mean that is fair. I was mainly talking about my use case and requirments. I didnt mean to start "replacement" discussion

  85. MSavoritias (fae,ve)

    because it feels i am trying to twist MUC into becoming MIX

  86. Kev

    Maybe I should just rewrite mix as “do muc with the mix model” that fixea the core issues, and go from there.

  87. MSavoritias (fae,ve)

    that would be interesting yeah

  88. MSavoritias (fae,ve)

    like there is the server compatiblity with 408 but there is not a client compatibility

  89. MSavoritias (fae,ve)

    or actually a development migration thingy to reuse existing components as you said yeah

  90. moparisthebest

    > What happens if a test fails? Guus: your tool optionally outputs junit XML which is the universal format for CI parsing/output

  91. moparisthebest

    Damn happened again but only happens when I'm not in a position to troubleshoot... My Cheogram can send+receive messages to MUCs and other 1:1, and wife's Cheogram can do the same, except she gets 1:1 messages from me but I get none from here until I log out and back in... Thoughts singpolyma ? It could be a prosody bug too I guess

  92. moparisthebest

    Damn happened again but only happens when I'm not in a position to troubleshoot... My Cheogram can send+receive messages to MUCs and other 1:1, and wife's Cheogram can do the same, except she gets 1:1 messages from me but I get none from her until I log out and back in... Thoughts singpolyma ? It could be a prosody bug too I guess

  93. singpolyma

    ...all your stanzas everywhere work except a single jid sending messages to you and a log out/in fixes? That might be the craziest thing I've heard today

  94. singpolyma

    When you log out and back in are all the things she tried to send you there from mam?

  95. moparisthebest

    Yes, it's actually happened multiple times, at least 4 or 5 over the last few months

  96. moparisthebest

    And yes I get them all from mam when I log back in

  97. singpolyma

    So server knows about them. Client doesn't think it ever saw them

  98. moparisthebest

    Note my connection has been extra flaky today so that could be a cause

  99. singpolyma

    Next time it happens enable debug logs on prosody and see if it thinks it it sending them to your c2s?

  100. singpolyma

    Since we don't have XML console in mobile to check such things...

  101. moparisthebest

    Yea I think I'll have to do that to be able to blame Cheogram or prosody

  102. moparisthebest

    Now that I think about it I was only doing muc so if online presence didn't get out somehow, that could explain me not getting 1:1...

  103. singpolyma

    Yes. If zero 1:1 works I have more possible theories

  104. singpolyma

    If it's just one contact it's bonkers

  105. moparisthebest

    I didn't try other 1:1 but I can next time

  106. moparisthebest

    I'm now wildly guessing it's a SM bug where presence doesn't make it out