jdev - 2021-07-20


  1. southerntofu

    hello is there a semantic distinction between user disconnect and user leaving a MUC? i'm wondering how to filter random client disconnects (though still displaying meaningful join/leaves) in the case of bridging so that we don't "pollute" the chan on the other side of the bridge

  2. jonas’

    southerntofu, not really

  3. jonas’

    MIX has that :-X

  4. southerntofu

    thanks for answer! "not really" as in can be infered from something else? or "no"

  5. jonas’

    southerntofu, well, if we take "membership" as "being in the MUC", then you could use that as a hint, but I don't think that any clients revoke membership when you delete the bookmark (if we want to take that as "leaving"; there is also not really a model (beyond ←) as to what "leaving" a room for good means on the client/user side)

  6. southerntofu

    clients don't revoke membership when you close and unbookmark a MUC? oO

  7. jonas’

    I'd be surprised if they did

  8. jonas’

    you can't get it back when the user wants to undo that change

  9. southerntofu

    you mean membership as in affiliation status with registered nickname etc?

  10. jonas’

    yes

  11. jonas’

    (mind that membership etc. is not really mappable to the IRC world, if this is in any way related to the discussion in biboumi@)

  12. jonas’

    (I mean it is, but it is messy (think chanserv) and biboumi doesn't do it)

  13. southerntofu

    ah ok it's not homeserver-side "membership" (which is nothing more than the bookmark right?)

  14. jonas’

    yes

  15. jonas’

    the MUC server (or other participants for that matter) cannot know about that type of membership

  16. southerntofu

    yes the discussions are related, i'm investigating how network drop or server restart can be mitigated so as not to produce tons of join/leaves

  17. jonas’

    (well unless you accidentally set your bookmark node to "open", buuut ... ;))

  18. southerntofu

    (haha)

  19. jonas’

    southerntofu, as I said in the other place, tons of joins/leaves are how IRC works. I wouldn't worry too much :)

  20. southerntofu

    because that was pointed out by some people on other networks that such pollution is unwelcome

  21. southerntofu

    i agree jonas’ but they mentioned the specific case of matrix.org as an extreme example of what not to do, because it had ghost users who no longer existed still connected via the bridge, and rooms with thousands of people bridged, which produced A LOT of noise

  22. southerntofu

    on IRC side rooms tend to be smaller and the network operators apply their own membership/abuse policies, which they obviously can't enforce on other networks, sooooo looking for ways to play nice

  23. southerntofu

    for the curious ones, this was the issue i'm referencing: https://github.com/Mikaela/mikaela.github.io/issues/242 (involving disroot hosting coop)

  24. southerntofu

    also because in the case of cheogram-muc a new component is introduced so the probability for mass disconnects is doubled, whether biboumi or cheogram-muc restarts/timeouts