XSF Discussion - 2019-03-03


  1. jonas’

    I also wanna make a high-level-ish language on top of sed to re-implement the echo bot in that

  2. jonas’

    and then maybe a libc implementation with a shim wrapper around sed to invoke syscalls

  3. ta

    Whatever floats your boat.

  4. Link Mauve

    Hi, for people who have read/written MIX, what is the story with user PEP?

  5. Link Mauve

    If I join a MIX channel and want to obtain e.g. the User Tune of all members, will the MIX service subscribe to everything I have a +notify for, or does it rely on the participants explicitly publishing their User Tune to each MIX channel they’re in?

  6. Steve Kille

    My basic model is that the primary goal of MIX sharing of participant info is to share who are the participants. With JID hidden, this is typically going to be minimal information. With JIDs shared, I see that sharing further info can go directly, and should not be involving the MIX channel.

  7. Link Mauve

    So in my case, a participant interested in the User Tune of each other participant should subscribe manually to all of them?

  8. Link Mauve

    Or retrieve it as the user scrolls in the list, or something like that, depending on the UI of the client.

  9. Kev

    I've been assuming that the server can straightforwardly proxy PEP, but I might be being naive.

  10. Kev

    Well, semi-straightforwardly.

  11. Link Mauve

    Would PAM imply that the MIX channel is auto-subscribed to all PEP items?

  12. Link Mauve

    Or something like that.

  13. Kev

    That was my assumption.

  14. Link Mauve

    Great, thanks.

  15. Link Mauve

    PEP nodes*

  16. Kev

    Details TBC.

  17. zinid

    Link Mauve: are you implementing mix?

  18. Link Mauve

    zinid, I’m actually thinking about PEP proxying for MUC.

  19. zinid

    Link Mauve: ah

  20. Link Mauve

    Somehow.

  21. Link Mauve

    Details TBC too, I’m just playing with a poc.

  22. zinid

    whatever, I decided to stop fiddling with muc in ejabberd and focus on mix

  23. zinid

    fiddling with both is too taxing

  24. Link Mauve

    It was prompted by https://github.com/xsf/xeps/pull/760 and the idea to finally deprecate 0153.

  25. zinid

    I know the idea

  26. Link Mauve

    I’m trying to see if it’s viable before I push this PR to standards@.

  27. zinid

    Link Mauve: well, the council decided to start the discussion 😁

  28. zinid

    before voting

  29. Link Mauve

    Yes.

  30. zinid

    I am honestly not sure why are you worried about it so much 🤔

  31. zinid

    I am honestly not sure why you are worried about it so much 🤔

  32. zinid

    I really don't like the situation when we cannot decide where to move, we will end up with incompatible implementations

  33. Link Mauve

    Yeah, I guess I could just send my proposal instead.

  34. zinid

    either we continue muc necromancy or focus on mix.

  35. Link Mauve

    I’m fine with both so far.

  36. Link Mauve

    With a slight preference towards fixing what we have.

  37. zinid

    well, I am not 😀

  38. Link Mauve

    Neither clients nor servers will be able to go MIX-only for quite a while, even if all implementations got MIX support today.

  39. Link Mauve

    So, fixing MUC will be useful during the transition period anyway.

  40. zinid

    > Neither clients nor servers will be able to go MIX-only for quite a while, even if all implementations got MIX support today. True. My approach in ejabberd is to implement very tiny muc subset above the mix code. Like joining/leaving and message sending.

  41. Link Mauve

    Only that? :/

  42. pep.

    And then tell users MUC is bad because you implement only 3% ? :P

  43. zinid

    Link Mauve: I didn't decide what exactly to implement.

  44. zinid

    yet

  45. zinid

    I just want to make sure the chat is usable in at least popular clients.

  46. zinid

    configuration/moderation won't be supported for sure

  47. Link Mauve

    zinid, is your current MUC code not reusable at all?

  48. zinid

    Link Mauve: no, it's total garbage

  49. Link Mauve

    zinid, sounds pretty bad. :x

  50. zinid

    and strictly speaking it's not my code 😋

  51. Link Mauve

    zinid, “your” as in Ejabberd’s. :p

  52. zinid

    I only patched that trash

  53. zinid

    Link Mauve: I mean technically I didn't write it

  54. Link Mauve

    Prosody recently got a rewrite of its MUC code, it now is very easy to extend and could maybe become the basis of some kind of MIX.

  55. Link Mauve

    But I have yet to read a recent version. :x

  56. zinid

    Link Mauve: yes, but I don't want to rewrite it. this was the basic dilemma for me: either rewrite it or go mix.

  57. Link Mauve

    Ok.

  58. Link Mauve

    That’s sensible.