XSF Discussion - 2023-08-08

  1. edhelas

    Hi everyone :) I might do some work soon on XEP-0372: References in Movim. I did a while ago a PR to complete and clarifiy some things in it there https://github.com/xsf/xeps/pull/1281

  2. edhelas

    Do not hesitate to put comments and feedback if there is things that you would like to see/change in it

  3. edhelas

    The idea would be to add support for @nickname in chatrooms messages in Movim to start with

  4. Seve

    Made this module for Prosody a while ago for References https://modules.prosody.im/mod_muc_inject_mentions.html might need to check out that PR 😀

    👍 1
  5. singpolyma

    I plan to do something with references too in coming months, so will check it out. I'm hoping to use @ as part of the UI but not as part of the body text

    💯️ 1
  6. edhelas

    > I plan to do something with references too in coming months, so will check it out. I'm hoping to use @ as part of the UI but not as part of the body text Yes, that was also my goal, @ is only there to trigger the JS-html-menu thing, in the end only the nickname is sent on the wire (then the <body/> looks the same) ✎ ↺

  7. edhelas

    > I plan to do something with references too in coming months, so will check it out. I'm hoping to use @ as part of the UI but not as part of the body text Yes, that was also my goal, @ is only there to trigger the JS-html-menu thing, in the end only the nickname is sent on the wire (then the <body> looks the same) ✏ ↺

  8. edhelas

    > I plan to do something with references too in coming months, so will check it out. I'm hoping to use @ as part of the UI but not as part of the body text Yes, that was also my goal, @ is only there to trigger the JS-html-menu thing, in the end only the nickname is sent on the wire (then the body looks the same) ✏ ↺

  9. edhelas

    And I also add back the @ when generating the message in my UI

  10. lovetox

    Nickname ?

  11. lovetox

    I would send the occupant id

  12. lovetox

    Otherwise we run again into situations where something is mapped to the wrong user

  13. singpolyma

    In the context of a semi-anon chat is there much difference though? it's about what user will get the "ping" which is already commonly done by plain-text nickname on the whole network

  14. lovetox

    Yes the difference is huge, one is a bad workaround which uses non unique identifiers, and the other one is a proper solution.

  15. singpolyma

    I guess it depends what you think the feature is meant to do

  16. singpolyma

    If it's meant to notify a particular nickname then by nickname seems more correct to me

  17. lovetox

    ? a client knows it's nickname and occupant id

  18. moparisthebest

    I actually find it highly annoying and confusing when a message highlights me but doesn't have my name in it, that could be the crusty old IRC user in me coming out though

  19. lovetox

    Where is the difference for you?

  20. MSavoritias fae.ve

    My two cents sending the occupant-id and mapping everything to that seems like a much better solution than scanning all text in the chat for a nickname that may or may not exist next week.

  21. edhelas

    singpolyma the goal was to move the Mentions things in a specific XEP, pep. worked on it during a sprint with me

  22. edhelas

    The thing is that in that XEP, mentions were kinda incomplete and blurry

  23. edhelas

    We wanted to have a proper urn:xmpp:reference:mention:1 or something that clearly explain how to mention someone in a MUC, anonymous MUC, in a MIX channel ...

  24. edhelas

    So for example the occupant id thing will then be specified in that new XEP, and References stays generic enough

  25. edhelas

    That's also why we bumped it

  26. larma

    I'd like to point out that mentions is two things in my head that often come together but should be technically unrelated: - Notify one or multiple users (or all in a MUC or admins of a MUC or maybe people with a specific hat in a MUC) - Markup to have a username displayed nicely (e.g. with option to click on it like a link to see details) when it appears in a message.

  27. lovetox

    +9 ✎

  28. lovetox

    . ✏

  29. edhelas

    We added hreflang (optional) attribute, make URI optional as well, clarifiy the difference between the anchor and URI

  30. edhelas

    This is to me enough to bump the namespace

  31. edhelas

    Knowing that References can also by used for totally different purposes, for example referencing a Pubsub item in a message

  32. edhelas

    To me I'd prefer to have a generic References XEP that just explain how to point to something in XMPP and then have more specific XEPs to specificy the use cases, for example a Nickname Quoting Reference

  33. singpolyma

    If you split the xep will be weed a registry for the "type" attribute? ✎

  34. singpolyma

    If you split the xep will be need a registry for the "type" attribute? ✏

  35. edhelas

    I'm not sure

  36. edhelas

    I was thinking of something similar as https://xmpp.org/extensions/xep-0472.html#profiles

  37. larma

    edhelas: for which of the two usecases I mentioned do you envision to use references? The markup or the notify?

  38. singpolyma

    larma: how do you see them as different?

  39. edhelas

    Actually I wanted to start just with the second one, just having nice @ quoting

  40. edhelas

    But we had in mind hats and quoting as well

  41. edhelas

    So you could also do @admin @all etc...

  42. singpolyma

    I have @here already. I'm no sure those are the same because there's nothing to link to

  43. edhelas

    That's actually why the URI was made optional

  44. larma

    singpolyma: With encryption you might want to do the notify outside the encryption but markup should always be encrypted. Also you might want to reference a person without notifying them, e.g. when you talk about but not with them

  45. singpolyma

    URI has been treated as optional forever anyway because of sims

  46. edhelas

    Just to give some precisions, Movim currently implement references in messages when you share some Pubsub items (articles in Movim) in a chat message. Implementation there https://github.com/movim/movim/blob/master/app/Message.php#L418

  47. nicomuc

    edhelas: pep started working on this too: https://bouah.net/specs/mentions.html

  48. singpolyma

    Hmm, this idea of "extending" an element by adding un-namespaced attributes to it seems very problematic to me. Why not use a child element in that case as we do for sims?

  49. singpolyma

    Right now I use https://xmpp.org/extensions/xep-0224.html for what this protoxep defines urn:xmpp:reference:mention:1#channel for

  50. singpolyma

    I also obviously don't like the hard dependency on occupant id :P

  51. edhelas

    > edhelas: pep started working on this too: https://bouah.net/specs/mentions.html Yes, that was what I was talking about :) ↺

  52. lovetox

    > Also you might want to reference a person without notifying them sounds over engineered to me, are there any IM solutions that give the user choice over this destinction?

  53. lovetox

    but yes a valid point, it should be considered in the XEP design process if the data needs to be processed by the server

  54. lovetox

    should we consider a reference private metadata which needs to be encrypted?

  55. lovetox

    then it should certainly not mixed with non-private content which needs to be processed by the server

  56. lovetox

    on another note, can we have another review of https://github.com/xsf/xeps/pull/1270

  57. lovetox

    - Change gets rid of fastening - Change moves the id attribute into the retract element

  58. lovetox

    And defines origin-id must be used, and stanza-id in MUC

  59. lovetox

    for me this looks good, but if anyone has doubts please voice them, so we can get this merged

  60. lovetox

    Message moderation depends on this change

  61. MattJ

    lovetox: posted to standards@?

  62. lovetox

    is the webinterface up?

  63. lovetox

    can i subscribe, can i look through threads

  64. lovetox

    otherwise, i rather not

  65. stpeter

    We are still working to reinstate the web interface. In the meantime, I can add subscribers via Python instructions at the command line if needed. ;-)

  66. lovetox

    i would appriciate it if you could add philipp@hoerist.com to jdev and standards

  67. lovetox

    thanks

  68. stpeter

    OK!

  69. stpeter

    lovetox: apparently that email address is already subscribed to standards, but I added it to jdev

  70. stpeter

    lovetox: if you do not receive email messages from the standards@ list, perhaps you disabled delivery?

  71. stpeter

    bbiab

  72. lovetox

    i received nothing in months

  73. lovetox

    how can one disable delivery?

  74. lovetox

    hm no ignore me

  75. lovetox

    i changed email provider, and didnt migrate my rules to put them into the correct folder

  76. lovetox

    everything good, thanks

  77. lovetox

    so whats the process for merging a PR?

  78. lovetox

    can it put on some agenda?

  79. Kev

    Editor will get around to it eventually.

  80. Kev

    Otherwise feel free to help find someone to do the Editor job properly.

  81. lovetox

    Is there somewhere a description of the job?

  82. lovetox

    i see XEP-0001 probably

  83. Kev

    There's process docs for most things in the xeps repository.

  84. Kev

    It's mostly "Process PRs, forward things to the appropriate Authors/Approving bodies, act on outcome, run some scripts to push updated builds".

  85. Kev

    An hour or two a week would do a good job of it, I'm just struggling to carve out anything like that much.

  86. lovetox

    hmmm

  87. lovetox

    and you are currently the only Editor?

  88. Kev

    Effectively.

  89. Kev

    I'm just trying to keep things ticking over until we can find a more permanent replacement.

  90. moparisthebest

    The answer is more automation and less "well the current editor is ok with running these scripts manually"

  91. moparisthebest

    For some reason we are too afraid of that though

  92. Kev

    Honestly, the scripts aren't so much the issue for me at the moment. It's the actual processing of the PRs based on the output of the scripts.

  93. Kev

    Like shoving version blocks in when PR authors don't, or fixing them, or ...

  94. moparisthebest

    Right, so GitHub actions should run the scripts and do the processing?

  95. moparisthebest

    Scripts can just fail saying the author needs to do that etc etc

  96. Zash sheds a tear over Github-centricness of everything

  97. Kev

    More automation would be a good thing. Just saying that it's not so much the script bit that's the biggest pain point for me.

  98. moparisthebest

    Zash: the scripts are just scripts at least

  99. Kev

    But, equally, if the scripts *immediately* told the author to add a version block, etc., that might make life better.

  100. Kev

    It's unhelpful for me to wait a month, and *then* tell someone to add a block.

  101. moparisthebest

    Kev: maybe not a problem for you, but 100% the problem preventing more editor volunteers

  102. moparisthebest

    Want to be an editor? Ok great, well we have no explanation of what needs done or how to do it, thanks!

  103. moparisthebest

    We have some outdated documents and manual scripts though, have fun!

  104. lovetox

    moparisthebest, why are you saying that, https://github.com/xsf/xeps/blob/master/docs/ has much info on what to do

  105. lovetox

    but yeah, setting up CI checks for something like version blocks should be not much work

  106. lovetox

    do i read xep-0001 correctly, that once a author has a published experimental XEP, he can push changes without anyone approving?

  107. moparisthebest

    Very outdated, doesn't even mention the scripts that automatically check all that (not that it should... CI should just apply the tags automatically)

  108. lovetox

    hm so what is needed is not actually a new editor, its improving the tools, which is a way smaller job, time capped, and can be done by probably many people

  109. lovetox

    did someone try to list the things that need automation, and just ask if someone willing to implement them?

  110. lovetox

    or was it until now expected that the editor does this himself

  111. singpolyma

    There was a bunch of discussion about it late last year, which I thought had led to some improvements, but maybe it just led to us choosing a new victim

  112. moparisthebest

    In theory yes, in practice someone writes the scripts and can't get reviews for months and then can never get approval to integrate running them automatically ;)

  113. moparisthebest

    (hence my complaints)

  114. lovetox

    is not only the editors approval necessary? i mean its his job that gets automated so his responsibility that the scripts work

  115. Kev

    Tooling was improved significantly end of last year, primarily by moparisthebest writing a script that would check a PR, and then me early this year writing a script that would run a complete Editor 'session' of reviewing PRs in order and publishing artifacts.

  116. Kev

    So things got much better. They can be better still.

  117. moparisthebest

    That's great but basically locks you into being the only possible editor

  118. Kev

    Whyso?

  119. moparisthebest

    What about just making those scripts run automatically and apply tags to PRs ?

  120. Kev

    Yes, that would be better.

  121. Zash

    Any thoughts on pre-commit hooks? Opt-in, but there's tooling to automate automatically automating pre-commit automatic checks :)

  122. moparisthebest

    Any downsides to doing this? I feel like worst case some tags get applied wrong

  123. Kev

    I'm off for the night. o7

  124. moparisthebest

    If you would consider the automatic tag applying, as much as I hate playing with GitHub actions, I'll give it a go But if you don't want it I don't want to waste time, let me know :)

  125. lovetox

    Kev, im willing to try it, though i think this will mean you probably would have to train me, if this is of interested ping me.

  126. moparisthebest

    I'm also willing but not until after all automation that makes sense to do has been done :D

  127. MSavoritias fae.ve

    Sounds to me we just in a person with merge rights to the repo to just merge everything moparisthebest is writing and we can have editors after :)

  128. moparisthebest

    There will always be some manual checks but the ones that can be automated should be imho

  129. lovetox

    moparisthebest, im not yet understanding the dynamics of this situation, the editor has merge rights, become the editor and merge any automation that eases the job

  130. lovetox

    who would stand against that?

  131. lovetox

    its the job of the editor to do this things as statet in XEP0001

  132. lovetox

    nothing is said about the tools you need to use for it

  133. moparisthebest

    Really an editor team discussion though, not something one should do unilaterally

  134. lovetox

    the editor team member count is 1, as i understood it :d

  135. lovetox

    Anyway, i see you are motivated to improve the situation, but feels like dancing around something that is not spoken out. Who is preventing you to do the automation work and why? then we can discuss it and hopefully find a resolution.

  136. moparisthebest

    That's why I'm asking Kev, he said he didn't want it before

  137. moparisthebest

    Oh this could come in handy https://github.com/nektos/act

  138. Kev

    I don't remember being anti-automation, although I may have said I thought the script should bed in before being run automatically? I don't know. Anyway, I'm not opposed to automation.

  139. Kev

    Even if it turns out I once was for some reason.

  140. Kev

    Bed. o7