jdev - 2024-07-08

  1. MSavoritias (fae,ve)

    anyone that has knowledge of MLS can answer how good is MLS ordering? I am browsing the RFC now and I stumbled on the > 15.3. Delayed and Reordered Application Messages which says > Since each application message contains the group identifier, the epoch, and a generation counter, a client can receive messages out of order. When messages are received out of order, the client moves the sender ratchet forward to match the received generation counter. Any unused nonce and key pairs from the ratchet are potentially stored so that they can be used to decrypt the messages that were delayed or reordered. reading the rest of the RFC it seems to suggest that epoch and generation identifier together with other things like the rachet tree could give a pretty close indication on message ordering am i reading this right?

  2. MSavoritias (fae,ve)

    also how close is this to omemo? is it that omemo doesnt have the generation counter so we are using the timestamps to compensate?

  3. MSavoritias (fae,ve)

    or maybe because omemo is not used everywhere we can't rely on omemo actually

  4. edhelas


  5. edhelas

    How does this client knows that sending private messages is forbidden in the MUC ?

  6. MattJ

    There is a configuration option in XEP-0045, grep for 'allowpm'

  7. MattJ

    But as mentioned, it's problematic because it isn't able to reflect more fine-grained policies (such as "only PMs with moderators are allowed", which this MUC implements, for example)

  8. edhelas

    Ok :)

  9. MattJ

    There is also no equivalent disco item defined in XEP-0045 as far as I can see

  10. MattJ

    Probably implementations made one up

  11. edhelas

    Yes that's my main problem

  12. lovetox

    all configuration options can be exposed in disco, when i remember correctly

  13. lovetox

    and for example ejabberd does it with the pm setting if i remember correctly

  14. lovetox

    its called muc#roomconfig_allowpm

  15. MSavoritias (fae,ve)

    > is there any movement to make the MUC config/members list authenticated somehow and with access to specific people only? coming back to this MIMI uses an RFC that hasnt been finalized that uses MLS to do something related to that. https://datatracker.ietf.org/doc/draft-barnes-mls-appsync/ could be interesting to see it in practise if we can shove a config in there :P

  16. Guus

    Does anyone have experience with a misbehaving XMPP entity that sends `<nessus/>` on a c2s connection (as a first-level element on the stream, where you'd expect `<iq/>` `<message/>` or `<presence/>`)?

  17. MattJ

    Guus: it's probably the security scanner

  18. MattJ

    Similar to nmap it will send junk to fingerprint software and identify vulnerabilities