XSF Discussion - 2023-06-28

  1. Zash

    https://www.rfc-editor.org/info/rfc9413 Maintaining Robust Protocols Might be worth a look when I'm awake.

  2. MattJ

    edhelas, IIRC you were interested in hats: https://github.com/xsf/xeps/pull/1285

  3. edhelas

    MattJ 💕

  4. Seve


  5. edhelas

    Now lets implement that in XMPP servers :3 !

  6. MattJ

    https://hg.prosody.im/0.12/file/tip/plugins/muc/hats.lib.lua :)

  7. edhelas

    Looks like I'll have to open a ticket for ejabberd ?

  8. MattJ

    IIRC someone told me they were implementing the same syntax

  9. edhelas


  10. MattJ

    The real question (not addressed by this XEP update) is exactly how hats get assigned

  11. edhelas

    To me something like like "only admins/owners" can do it seems doable. And then you let bots taking care of it.

  12. pep.

    why bots?

  13. edhelas

    Discord is doing it this way, and it leaves all the complexity to the implementers.

  14. MattJ

    edhelas, who defines the hats?

  15. edhelas

    Well admins as well ?

  16. MattJ

    Then we need some kind of protocol for that

  17. edhelas

    Time to do PEP over MUC :3 ?

  18. edhelas

    <iq type='set' to='xsf@muc.xmpp.org' id='publish1'> <pubsub xmlns='http://jabber.org/protocol/pubsub'> <publish node='urn:xmpp:hats:0'> <item id='host'> <hat title='Host' uri='http://schemas.example.com/hats#host' xml:lang='en-us'> <badge xmlns="urn:example:badges" fgcolor="#000000" bgcolor="#58C5BA" /> </hat> </item> </publish> </pubsub> </iq>

  19. singpolyma

    > Then we need some kind of protocol for that I have a protocol for you ;)

  20. MattJ

    Of course :)

  21. lovetox

    really colors?

  22. MattJ

    lovetox, it's a common aspect of this feature in other platforms, so yeah

  23. lovetox

    and they can define the colors themself?

  24. lovetox

    as in the user

  25. lovetox

    but i guess why not

  26. lovetox

    so whats the idea, to store the metadata like color somewhere else, and only send a reference in the presence?

  27. lovetox

    ah no its in the presence

  28. lovetox

    so why pubsub?

  29. lovetox

    to store what hats are allowed in a room

  30. lovetox

    to store what hats are allowed in a room?

  31. MattJ


  32. edhelas

    We might have a specific namespaces for colors

  33. edhelas

    So it can be reused in other XEPs, Hats might not be the only case where we might need it

  34. lovetox

    sounds overengineered, security labels use colors since forever

  35. lovetox

    why the uris?

  36. lovetox

    whats the idea behind that?

  37. lovetox

    maybe i missed it, but there is no flow to remove a hat

  38. MattJ

    The URIs allow uniquely identifying a hat

  39. lovetox

    the title does also

  40. lovetox

    or lets say it could

  41. MattJ

    No, because the title might be translated, for example

  42. lovetox


  43. lovetox

    would be a first

  44. lovetox

    who does the translating ? the Admin?

  45. MattJ

    Doesn't matter

  46. lovetox

    in what situation do i need to identify a hat by its uri?

  47. MattJ

    You don't *need* to, which is why there is a title

  48. MattJ

    Clients can just ignore the URI for display purposes, and render the title

  49. MattJ

    But they may understand the URI, and apply some special meaning

  50. lovetox

    its more and more like a security label for presence

  51. MattJ

    Maybe, I can see similarities

  52. lovetox

    has a label/uri which we can ignore, and a displaymarking/title/color which we display :D

  53. lovetox

    presence is of course a problem

  54. lovetox

    should you not go full security label, and attach the hat to the message?

  55. lovetox

    i mean the server

  56. lovetox

    otherwise MAM etc will be a problem

  57. MattJ

    Then how would you discover the hats of people who haven't written a message?

  58. lovetox

    maybe additional?

  59. lovetox

    not instead

  60. MattJ

    Sure, possibly

  61. MattJ

    We have occupant-id and stuff for that though already, right?

  62. lovetox

    hmmm .. meh thats a can of worms

  63. lovetox

    so i receive presence, and then attach a hat retroactively to past messages i receive?

  64. lovetox

    nah it should be independent of presence in my opinion

  65. MattJ

    Hats are associated with users, not messages

  66. MattJ

    Think of them as extended affiliations

  67. lovetox

    are affiliations not added to MUC MAM messages?

  68. MattJ

    I don't think so?

  69. lovetox

    examples in the MAM XEP sure look like it

  70. MattJ

    > In the case of non-anonymous rooms or if the recipient of the MUC archive has the right to access the sender real JID at the time of the query, the archive message will use extended message information in an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with a 'jid' attribute specifying the occupant's full JID, as defined for non-anonymous room presence in Multi-User Chat (XEP-0045) [11]. Indeed.

  71. lovetox

    if you only add it to presence, my GUI would only add it to the roster

  72. lovetox

    MUC roster is mostly hidden for most users

  73. lovetox

    When i read about the XEP i thought, ok i add a "Teacher" badge to each message

  74. lovetox

    because so people know the messages comes from the Teacher

  75. lovetox

    So my GUI would attach hats to messages

  76. lovetox

    don’t know how other im solutions use hats

  77. lovetox

    if its just a "user can look it up if he wants in the roster" kind of thing, i would not find it that useful

  78. lovetox

    Also this attaching it to messages makes it more flexibel, when presence is not broadcasted, for example big MUCs

  79. lovetox

    And then it would be a security label without the security :D

  80. lovetox

    the diff is subtle, with sec labels i can add different to each message, which would not be the case here