jdev - 2024-02-26


  1. lovetox

    whats the state of "Mention" a user in a muc, i think there was XEP 0372, never finished, does not use occupant id, does not mention MUC

  2. lovetox

    there is https://xmpp.org/extensions/xep-0452.html which seems to be about notificaitons outside of a MUC

  3. pulkomandy

    0372 is in use by converse.js and Renga. In one of the past xmpp sprints we discussed updating it or making a new version but I think no draft was submitted

  4. pep.

    There was a PR submitted to 372 that never got even ACK'd

  5. pep.

    But yeah the spec we wrote alongside that was never submitted

  6. pep.

    https://github.com/xsf/xeps/pull/1281

  7. pep.

    Ok it says "Removes the mention chapter (defined in another XEP)", but that could easily be reintroduced

  8. pep.

    And the WIP that's available for anyone to grab is here: https://bouah.net/specs/mentions.html I'm not working on it anymore

  9. lovetox

    This draft makes more sense to me

  10. lovetox

    Some thing which just came to mind

  11. lovetox

    When we add stuff that references points in the message, but we are not able to correct them later, because correction xep does not allow correcting something except body

  12. lovetox

    That's a problem

  13. lovetox

    I have to say, mentions in MUC is surely one of the most requested things by Gajim users

  14. lovetox

    It seems also one of the basic requirements for groupchats

  15. edhelas

    I'd also love to have the @all @online @specific-hat feature in Movim for sure

  16. lovetox

    edhelas: and how do you solve normal user mentions? By matching nicknames ?

  17. edhelas

    Yup

  18. edhelas

    Like where doing now, lovetox , like this :)

  19. blue

    May be making it the same way with special group mentions - with @ or any other syntax is better. it's less confusing and doesn't make false alarms when someone talks about you but doesn't want to mention, or when your nick is a common name

  20. blue

    May be making it the same way with special group mentions - with @ or any other syntax is better. it's less confusing and doesn't make false alarms when someone talks about you but doesn't want to mention, or when your nick is a common word

  21. pulkomandy

    The "mentions" xep allows to explxcitly encode (from the sender side) who/what is being mentionned. It doesn't really matter what syntax or ui is used to create a mention then. In Renga I send a mention when a nickname was added to a message using nickname tab-completion, but other clients could do it using the @ key and a completion popup or whatever you want

  22. pulkomandy

    It removes the need for scanning the message text and trying to guess if it was a mention on the receiving side

  23. edhelas

    That was the plan we had with pep. indeed

  24. edhelas

    And yes, in Movim I was planning to have the @ syntax to trigger the UI, but then only send "mentions" metadata in the wire

    👍️ 1
  25. lovetox

    pep., whats the story behind the href lang attribute? the XEP does not describe the purpose

  26. lovetox

    https://bouah.net/specs/mentions.html#beginend

  27. lovetox

    whats the use case here, why would mentioning 3 different people all point to the same characters in a text

  28. lovetox

    i thought begin and end is there so we can find the string that contains the username which we should highlight

  29. lovetox

    i think i dont agree with that intention, that a begin and end attribute specifies a text which is addressed to a user

  30. lovetox

    for me that overlaps with a quote mechanism

  31. lovetox

    i also have no ideas how a UI could look like which would make this feature possible, are there any messengers out there who support this features?

  32. lovetox

    also a question, is it intended to only send the references, and not send the nicknames anymore in the message? Then this would not be backwards compatible

  33. lovetox

    i think it would be best if the XEP would be more specific, references to a user should reference the string in the message which is the nickname of the user, and not just *some* text addressed to the user

  34. lovetox

    without this specified in the XEP, as a client i wouldnt even know what to do with the text information. It can be anything and i cannot infer any actions for the user

  35. lovetox

    i always thought the purpose is that we replace the nickname in the string with more interactive elements, that can be clicked by the user, maybe show a menu, but if the text can be anything, even text thats important to understand the rest of the message, i cannot replace it

  36. MSavoritias (fae,ve)

    > whats the use case here, why would mentioning 3 different people all point to the same characters in a text this is in case you want to do @all or @admins

  37. jonas’

    shouldn't that, instead of referencing indivduals, reference a Hat or something?

  38. MSavoritias (fae,ve)

    although it could easily get very big the stanza imo. this should be just be calling a hats element

  39. MSavoritias (fae,ve)

    ah too slow :P

  40. lovetox

    > this is in case you want to do @all or @admins Yes and No, this is covered and would be done without referencing single users

  41. MSavoritias (fae,ve)

    right it mentions affiliations https://bouah.net/specs/mentions.html#associations which this should be hats instead

  42. MSavoritias (fae,ve)

    never mind it has hats

  43. lovetox

    can be both, no need to make it a OR

  44. lovetox

    moderators and admins should not be Hats

  45. MSavoritias (fae,ve)

    then yeah i would keep single user and hats and remove everything else.

  46. MSavoritias (fae,ve)

    well since we can create custom hats i would leave only hats to simplify personally

  47. MSavoritias (fae,ve)

    side-note: i just saw that the command to add a hat is "don". what is "don" and why isnt it add or create?

  48. lovetox

    The XEP should mention that a text start/end referenced, is expected to be replaced by a supported client, and therefor should not contain anything else then a fallback text for not supporting clients

  49. jonas’

    MSavoritias (fae,ve), https://en.wiktionary.org/wiki/don#Verb

  50. MSavoritias (fae,ve)

    oh jesus. why did this end up in the xep

  51. jonas’

    because half of the XSF are english nerds /jk

  52. MattJ

    s//jk//? :)

  53. jonas’

    syntax error

  54. MattJ

    s,/jk,,

  55. MattJ

    I do think "create" and "add" might be confusing, but if it's an admin performing the action then "attach"/"detach" could work

  56. MSavoritias (fae,ve)

    right or that

  57. MattJ

    or "assign"

  58. lovetox

    tailor

  59. MSavoritias (fae,ve) facepalm

  60. jonas’

    MattJ, well, half of the XSF *are* english nerds, but I'm not sure that is or should be the reason ;)

  61. lovetox

    https://github.com/turt2live/matrix-doc/blob/39e674ccb355af61bcfef92be4b557f53db46ea4/specification/modules/mentions.rst

  62. lovetox

    matrix seems to use some kind of xhtml for that

  63. MSavoritias (fae,ve)

    yeah it basically is

  64. MSavoritias (fae,ve)

    https://spec.matrix.org/v1.9/client-server-api/#user-and-room-mentions

  65. MSavoritias (fae,ve)

    ``` { "body": "Hello Alice!", "msgtype": "m.text", "format": "org.matrix.custom.html", "formatted_body": "Hello <a href='https://matrix.to/#/@alice:example.org'>Alice</a>!", "m.mentions": { "user_ids": ["@alice:example.org"] } } ```

  66. jonas’

    let's just hope they never lose the matrix.to domain.

  67. MSavoritias (fae,ve)

    i wonder if this means that every single mention pings the matrix.to domain

  68. jonas’

    unlikely

  69. jonas’

    (and even if it does, the part behind the `#` is not transmitted to servers)

  70. MSavoritias (fae,ve)

    ah ok. so its basically the poor persons xml namespaces

  71. lovetox

    i wonder how we make references work with quotes

  72. lovetox

    do i need to add the refs received again if i qoute the message?

  73. lovetox

    probably not .. otherwise the people would be mentioned again

  74. lovetox

    better would be a reply i guess, then i can look up the message in the database and draw it correctly

  75. lovetox

    but then quoting will get weird if in a non-quote i replace the nicknames with fancy UI, and in the quote it shows only the fallback text ...

  76. lovetox

    but i guess this is good enough, most people will use replies anyway

  77. lovetox

    its insane how many people over decades try to solve the exact same problems over and over again in many messengers ..

  78. pep.

    > therefor should not contain anything else then a fallback text for not supporting clients This is invalid as one can't distinguish between supporting and non-supporting clients in.. many places nowadays (as much as I don't like it)

  79. pep.

    > also a question, is it intended to only send the references, and not send the nicknames anymore in the message? Then this would not be backwards compatible What was this making reference to again? I'm not familiar with the WIP anymore

  80. pep.

    <body/> is sent unmodified right? So non-supporting clients can still do whatever they did before

  81. singpolyma

    > When we add stuff that references points in the message, but we are not able to correct them later, because correction xep does not allow correcting something except body Correction definitely allows things othes than body. It only doesn't allow changing the "kind" of stanza example being from a chat message to a pubsub event or equally crazy

  82. lovetox

    > and not to change the nature of the stanza or its metadata

  83. lovetox

    you can read into that what you want, metadata is for me everything that is not the body

  84. singpolyma

    Its says the "nature of" the metadata

  85. singpolyma

    Changing the subject or the attached image or mentions does not change the naturn of, rather the opposite it preserves the nature

  86. lovetox

    if you interpret it that way, nothing comes to mind that would be not correctable

  87. singpolyma

    Right. Which I believe is the intent

  88. singpolyma

    Just not meant to use it for insane things like the chat to pubsub example

  89. singpolyma

    Or correcting a JMI to a chat or other wild stuff

  90. lovetox

    i struggle how to model that in the database, if everything can be replaced, and we need to assume to receive correction before the original message, this means we probably want normal messages and corrected in the same table

  91. lovetox

    is there some SQL magic that lets me only load the last message ... i didnt find it yet

  92. singpolyma

    Correction could be second table. If done naively this means a correction to no known original doesn't show, which might be fine though not quite the spec intent. Otherwise insert replacement to second table and also upsert a row to main table, oldest wins (thus putting there if needed and updating with original eventually)

  93. singpolyma

    Probably want something like this to show edit history also

  94. lovetox

    what exactly do you store in the second table?

  95. lovetox

    as a correction can be almost everything, that would need both tables would need to look almost identially

  96. singpolyma

    yes, very very similar schema I expect. though second table might not need columns and indexes that exist for searches etc

  97. pep.

    fwiw, we're not there yet, but if you're designing your database schema again you may want to take into account MLS stuff.. https://www.ietf.org/archive/id/draft-ietf-mimi-content-01.html#name-edit edits for example use the latest id and not the original id like we do now

  98. pep.

    (I mean, do store both, someday, maybe)

  99. singpolyma

    that looks like mimi not mls

  100. pep.

    Well it's likely some of this ends up in the MLS payload

  101. MSavoritias (fae,ve)

    what payload? because MLS is already standardized

  102. pep.

    The encryption mechanism is standardized right? Not what you encrypt

  103. singpolyma

    MSavoritias (fae,ve): MLS is an encryption scheme. it doesn't say what should be in there it's just a binary blob

  104. singpolyma

    for us it will probably be SCE XML

  105. MSavoritias (fae,ve)

    right

  106. singpolyma

    MIMI is trying to invent a new chat protocol and hoping people will use it instead of their existing protocol

  107. singpolyma

    this is not related to MLS except that they happen to use MLS as their encryption

  108. MSavoritias (fae,ve)

    MLS federated rfc just says: > The negotiation can be done at the KeyPackage level, or through the MLS extension mechanism.

  109. MSavoritias (fae,ve)

    so im guessing xmpp can define whatever it wants

  110. MSavoritias (fae,ve)

    ah there is an extension about content advertisement so probably xmpp will be based on that partially

  111. lovetox

    Mimi is a protocol for interior with other messenger services?

  112. lovetox

    Mimi is a protocol for interop with other messenger services?

  113. lovetox

    So would be some kind of gateway on the server in xmpp?

  114. MSavoritias (fae,ve)

    its a protocol of its own afaik.

  115. MSavoritias (fae,ve)

    same as if every silo implemented xmpp and we all talked through that

  116. lovetox

    Of course referencing different IDs would be a problem, because the server cannot translate that

  117. lovetox

    We could simply add an extension which sends the other id

  118. pulkomandy

    lovetox: I think no one answered about that: The lang attribute in mentions was to allow sending a message with multiple bodies in different languages, and have the corresponding mentions with the begin/end for each of them. I think this won't be used by a user facing ui client but it could be used by a bot who sends mentions

  119. lovetox

    singpolyma, i thought something like this

  120. lovetox

    https://www.db-fiddle.com/f/pze1KseEaU2b79Jk2WuT8H/2

  121. lovetox

    you have a table where you store only a mapping from correction_id -> message_pk

  122. lovetox

    over this table you build a group with max(timestamp) so you basically get a table with correction_id -> message_pk and message_pk is the primary key of the last correction

  123. lovetox

    then you join your normal message table with message_id against correction_id, and then join the message_pk

  124. lovetox

    of course this approach lets you only display messages where you have the original first message received

  125. lovetox

    but this makes sense, if you scroll backwards to a certain point in time, you should wait until you reach the point from the first original message, to display it and the corrections

  126. singpolyma

    so you're storing the corrections in the normal message table and doing a many-to-many self join?

  127. lovetox

    i store it in the normal table but its only a 1:1 join, because you join with the result of that group by query

  128. lovetox

    and every account/remotejid/messageid combination is only expected to be once in that other table

  129. lovetox

    because i grouped away all corrections which are not the last

  130. lovetox

    the table in the fiddle, represents the "correction_table"

  131. lovetox

    not the the message table

  132. lovetox

    its just the table that stores which message_pk map to which corrected message-id

  133. lovetox

    not sure if im making sense :D

  134. lovetox

    but i think it needs a solution where you store all messages in one table

  135. lovetox

    everything else is to hacky for me

  136. singpolyma

    Sure, I was just confused by your "of course this approach lets you only display messages where you have the original first message received" because my suggested approach had that problem (at least done the naive way) since you would insert corrections to the second table and nothing to the first (maybe, unless you do the upsert). But with this then the messages are all in one table so you can always have something to show

  137. lovetox

    i wonder how slow this all gets, if i finished implementing all the XEPs and have 27 tables to join

  138. Zash

    aren't SQL engines supposed to be good at that kind of thing?

  139. singpolyma

    usually

  140. lovetox

    ha i solved it even easier, i can join simply against the message table itself, no need for a second table

  141. singpolyma

    right