XSF Discussion - 2024-02-10


  1. hyol

    hook: what features are AP projects missing?

  2. hook

    hyol: To be fair, I am not intimately famiar with it, but from what I can tell the federation within one app works fine, but interoperability between different apps is not a given. It seems very "move fast, break things" right now, whereas XMPP seems more methodic. Again I could be terribly wrong.

  3. hook

    In any case, my intent was not to bash AP really, it was 1) an idle brainfart observation I had, which led me to 2) wondering how we could (help) polish up the UX for XMPP.

  4. lovetox

    MattJ, new try to convince you to change the MUC Hats XEP. It would be much easier to implement, and also would function better if the server injects the hat into all messages, and also stores the current Hat at point of writing a message in the database. Right now it only serves as a attribute on the *current* muc roster, if someone wants to look up the current hat of some person. But what i really want to do in the client is to display the Hat as part of the message. Nobody will go and look up in the roster what hat a person has .. constantly. But i cant really display it as part of the message, because i will receive mam messages, from people where i saw no presence from. Also it would be very useful if i dont always have only the current head. Its interesting what a person wrote back in history and what role/title/hat he had when he wrote the message, this is context for the message and depending on the roles/title/hat it can be interpreted in different ways. It makes a lot of sense to me to store the Hat as attribute of the message, because it is context. The same way when you receive a Email at your company the title/role of that person is important to give context to the mail. injecting the hats into the message, gives the XEP a lot more value and flexibility to implement different use cases.

  5. singpolyma

    I can see value ins seeing the hats they had at the time, but I can also see value in seeing their hat change on all messages when their hat changes. I guess it's a trade off. We go one way with Nick and the other way with hats/affiliation/avatars right now

  6. lovetox

    The client is free to apply the last hat on the message for all previous messages

  7. lovetox

    If that fits his use case

  8. lovetox

    That's no reason to separate context from the message for me

  9. lovetox

    But I doubt anyone would do this

  10. lovetox

    Because it's not a nickname, it's a role/title at a very specific point in time, and I fail to see a example where I want to lose that context

  11. singpolyma

    Is affiliation sent with message? Hats are basically extended affiliation. (Im not venturing an opinion what we should do, mostly thinking out loud)

  12. MattJ

    singpolyma, yes, apparently we do

  13. lovetox

    On MAM messages at least

  14. lovetox

    But I found no place where this is mandated

  15. hook

    FWIW hats/affiliations make sense both in roster and in messages to me. Ideally both.

  16. hook

    It is useful to find who has certain hats/affiliations in the room right now.

  17. hook

    But if e.g. I speak in a MUC (esp. archived) and wear a hat/affiliation, I would expect my messages carry my affiliation of when I spoke. My affiliation my change drastically – e.g. if I speak as director of project/org. on a certain project-related strategic point, that is quite a different weight of the message than if I do so as a simple user. And my status even within a project/org can change quite a bit. It would be weird, to say the least, to have a message attributed to the (role of) director, if that person was not the director at that point it time. And scaling to e.g. military makes this even more of a problem.

  18. hook

    Wearing multiple hats is also something that could be clarified in the message. In the roster/presence/contact I can have multiple hats, but when I speak as HatX, that could be recorded in the message.

  19. hook

    (also, feel free to tell me to shut up and/or leave, if non-XSF-members are not to comment on this channel)

  20. MattJ

    > feel free to tell me to shut up and/or leave, if non-XSF-members are not to comment on this channel Absolutely not the case 🙂

  21. hook

    I’m shit at code, but I’ve contributed to a few other specs (SPDX, OpenChain, REUSE.software, DRACC, …), so I hope I can help there now and again :)

  22. lovetox

    it not either or, of course hats should be communicated in presence, thats simply needed for the use case where someone wants to know the hats of a user, waiting until the user writes a message would be really bad. I dont think anyone questions that. For me this is mostly a protocol design descision, presence should be something optional, it should not be needed to receive a complete message with all the context. Like here is a message body, but for context go look into presence data, of course only if you didnt hit one of the cases where it was not possible to get the presence before receiving the message.

  23. hook

    lovetox: got a suggested new version draft anywhere?

  24. lovetox

    no, and i dont think thats the usual mode of work, author of a XEP proposes something, then we discuss, and later author can accept or not. MattJ is the author so we are the stage where i communicate my concerns, i would only draft something if he tells me he has no time to maintain the XEP anymore, or if he says he agrees but has no time to make the changes.

  25. hook

    > no, and i dont think thats the usual mode of work, author of a XEP proposes something, then we discuss, and later author can accept or not. MattJ is the author so we are the stage where i communicate my concerns, i would only draft something if he tells me he has no time to maintain the XEP anymore, or if he says he agrees but has no time to make the changes. Ah, ok, that makes sense. Thanks for explaining me the ropes.

  26. hook

    So a counter proposal would be a separate XEP then, I assume.

  27. lovetox

    this would only make sense if there is a substantial difference in the approach how to solve the feature, not moving one tag to another stanza type

  28. Daniel

    Proposals can take the format of PRs/rendered xep but the usually process is mailing list discussion and then the author is supposed to incorporate feedback / 'the rough consensus' of the mailing list discussion into the XEP

  29. Daniel

    The XEP author generally isn't the sole decision maker

  30. singpolyma

    lovetox, MattJ: given my position of hats as extended affiliation and the confirmation of practice of putting affiliation in mam, I think hats in mam makes sense to me

  31. Daniel

    MAM yes. Live messages no. Would be my gut feeling having not looked into hats a lot

  32. MattJ

    I'm inclined to agree, I think. I'm not a fan of the overhead and duplication, but at least on the server storage side we can relatively easily store that more efficiently if we cared to

  33. Andrzej

    While I do not like duplication of data and overhead of that, I wonder, in mobile scenarios (iOS with frequent reconnects), what is sent more: presence or message (when in MUC room)

  34. Andrzej

    no to mention how hats would „work” in presence-less MUC (if we would consider to have one)

  35. singpolyma

    We already have presence-less MUCs yeah and it could be a concern there but maybe including anyone with a hat in the part you still send presence for is good. I dunno

  36. singpolyma

    I guess some way to fetch list of all hats like you can fetch all affiliation would be useful too

  37. Andrzej

    yes, that would be useful and could work in presenceless scenario

  38. hook

    On message vs MAM, we’re talking detailed technical implementation differences, right?

  39. hook

    (I was not implying to fork MattJ’s proposal, just trying to understand the process. Thanks everyone for clarifying.)

  40. hook

    To add some more complexity, I wonder how multiple-hats should be stored in a message (archive). It may be very important which hat was used. And that is then also a client-side question: how does one select which message was under which hat.

  41. MattJ

    I think it makes sense to put hats wherever affiliations are, because they are very much related

  42. MattJ

    I'm not a fan of affiliations being included with every message, but apparently we already crossed that bridge, so I don't think adding hats will cause any great problem

  43. lovetox

    > I guess some way to fetch list of all hats like you can fetch all affiliation would be useful too then you invite race conditions

  44. lovetox

    also there is some duplication, but not necessarily always

  45. lovetox

    its just more consistent to simply add it to all messages

  46. lovetox

    you need to add it to MUC History and MAM anyways, now we shave of a few bytes to not add it to live messages, and it costs us more complexity on the client side implementation

  47. lovetox

    and even makes it inflexible for use cases where presence is not send at all

  48. lovetox

    also i think this feature has way more value then affiliations or roles, think about it, it lets the users create whatever roles they want, it lets users replicate whatever organisational structure they want.

  49. lovetox

    roles/affiliations are mostly irrelevant in a day to day live of a MUC user The most interesting is the Moderator Role, but thats about it.

  50. lovetox

    also i can remember that affiliations were never intended to even be seen by normal muc users, i remember 7-8 years ago that Daniel did need to convince all server implementations to even allow a normal user to query affiliations.

  51. lovetox

    and i think we did this only so OMEMO could work, *not* because people were interested in affiliations.

  52. lovetox

    hm no, i think the problem was, real jid *only* communicated in presence, so we could not encrypt to people not in the room. So ignore what i just said about affiliations

  53. singpolyma

    I agree that hats are what affiliations should always have been

  54. singpolyma

    And roles are just confusing hon

  55. singpolyma

    And roles are just confusing honestly

  56. hook

    Crazy idea: would it be possible to extend affiliations in MUC XEP directly then? Might be possible without breaking the current affiliations, just adding new ones to it (multi-affiliation might be a prob)

  57. singpolyma

    That's basically what hats is

  58. hook

    Yes. I mean if it was a new version of the MUC XEP instead of a hat XEP modifying the MUC XEP (but I guess, that is not how XEP work, need to finish reading on that)

  59. singpolyma

    There is rumbling about a new version of MUC xep which might mention hats if it happens

  60. hook

    You mean MIX?

  61. singpolyma

    No. Mix is unrelated

  62. pep.

    Also something something spec update something new spec

  63. lovetox

    https://xmpp.org/extensions/xep-0030.html#info-nodes , specifies > If the request included a 'node' attribute, the response MUST mirror the specified 'node' attribute to ensure coherence between the request and the response.

  64. lovetox

    but the same is not specified in https://xmpp.org/extensions/xep-0030.html#items-nodes

  65. lovetox

    so if i send a adhoc command and want to get all adhoc commands, and add a "node="http://jabber.org/protocol/commands"" , but the service ignores the node and simply answers with a disco items response like the node was not specified

  66. lovetox

    this would be compliant?

  67. singpolyma

    I'm not sure specifying node or not on the response means you can ignore node on the query and return the wrong items