jdev - 2022-07-27

  1. lovetox

    is a type error presence, always generated as a response? Meaning is there a situation where the server would route a error presence to my client, without the client first sending out some presence?

  2. MattJ

    You might get error responses from your contacts after sending initial presence, which is somewhat similar

  3. MattJ

    Specifically, in this case you might receive multiple errors in response to a single presence

  4. MattJ

    I suspect that *may* also happen in some circumstances the event that another client on your account comes online and triggers presence probes

  5. nav

    Now that leaves me with the problem of what happens when someone does recycle an old JID.

  6. nav

    Would it be useful to have some kind of unique (opaque) registration identifier to distinguish between two uses of the same JID?

  7. nav

    Something like an UUID that is associated with a JID for the lifetime of the account. When a JID gets recycled a new UUID is associated with it.

  8. nav

    Then other services can query for the UUID to establish whether it is the same registration.

  9. Kev

    I think the basic solution is 'never allow re-use'.

  10. MattJ

    I think that's for the best. Otherwise every single slot where we currently have a JID, we would need to replace with JID and UUID

  11. nav

    Kev: It's one solution, but not always feasible. For instance because of a catastrophic server failure with loss of data or even GDPR considerations.

  12. MattJ

    Even sending a message. What if you send a message to someone, and it was delayed for a few minutes, but they deleted their account and somebody recreated it?

  13. MattJ

    The logical conclusion is to replace JIDs with UUIDs :)

  14. nav

    MattJ: I was thinking more of an as-needed approach, where the onus is on the receiving entity to validate, if they want to, that they're dealing with the same registration.

  15. MattJ

    But more feasible would be: treat usernames as human-readable UUIDs

  16. nephele

    that problem is fun, if you have a UUID you can also move servers

  17. nav

    For instance, via a disco#info query returning the UUID.

  18. nephele

    if you disallow reuse you might have users that you cannot use for *some* instances because they know your hostname and users that used to be on it, but can use it for other instances that don't know about it... might be a problem if you get a dns name that had a previous owner beforehand

  19. MattJ

    Sure. For Snikket I disallow hostname reuse for this reason, too.

  20. nav

    Of course, it doesn't cover the case where someone recycles JIDs mid-conversation. ☺

  21. nephele

    i'm enviromentally friendly, reuse before recycling! :D better to steal the account mid-conversation

  22. nav

    nephele: I wasn't considering active attacks. If that is a concern, then you'd want to be using encryption.

  23. nephele

    well, the dns entry expiring and beeing re-registered mid conversation seems quite unlikely to me?

  24. MattJ

    It's an extreme example of course, but certainly I could send a delayed reply to someone whose domain expires and was reregistered by someone else

  25. nephele

    I mean, what exactly would a UUID *reasonably* protect against that a JID does not? if it does not have any crpytographic gurantees it could also be recycled mid conversation

  26. nephele

    say, if a caching entity is not told that it was recycled and maintains a wrong association of jid<->uuid

  27. nav

    Actually, I wonder if using encryption would be a viable approach. In theory that would allow both endpoints to authenticate each other.

  28. nav

    nephele: Yes, good point.

  29. Link Mauve

    nav, you mean like SASL EXTERNAL, which validates against TLS certificates? :p

  30. nephele

    I personally like the aproach of "your public key *is* your adress"

  31. nephele

    i am not sure if that is viable, but it would be quite neat ;)

  32. nav

    Link Mauve: Possibly, but how do you get say your external component to ask the user connecting to it to authenticate himself that way?

  33. nav

    nephele: Yeah PKA makes sense.

  34. nav

    I'll need to have a read of the relevant XEPs see how much hassle it is to implement something like OX on something like a component.

  35. nav

    Bit of a problem. Encryption support appears to be largely limited to message stanzas but not IQ or commands.

  36. nav

    It's not encryption per se that I'm concerned about but a way of verifying that you're dealing with the same identity you were dealing with at some unspecified point back in time. Maybe signed presence stanzas will fill the gap.

  37. Link Mauve

    nav, that was a thing in XEP-0027 fyi.

  38. nav

    Link Mauve: Presence signing?

  39. Link Mauve


  40. nav

    Yup, at least Blabber supports it.

  41. nav

    Kind of out of the box if you've configured an OpenPGP key for the account.

  42. nav

    Which is nice because that means the component is getting the signed message essentially for free.

  43. nav

    If the component can be bothered to discover the user's public keys and cache them, then a change in the advertised fingerprints may mean that the user could be someone else (or has replaced his keys). That the advertised fingerprints are valid can be checked by verifying the signed presence message.

  44. nav

    And in principle, this can be done transparently and in a way that's compatible with no OpenPGP use. ☺

  45. flow

    nav: i am not confinced that presence signing is a good idea

  46. flow

    message signing, of course, but presence probably not

  47. flow

    for starters, presence signing probably significantly increases the time your OpenPGP signing key is unencrypted

  48. nav

    flow: The same consideration applies whether you're signing and/or encrypting messages as it does to presence. In any case, at least Blabber automatically signs presence stanzas if you have a PGP key associated with your account.

  49. flow

    nav, the thing is, sending a message is a conscious action, whereas presences are mostly send without the user being aware

  50. flow

    granted, the problem was more severe in the days where whe shove everything into presence, like "the current song you are listening to"

  51. Zash

    XEP-0027 signed presences are *huge* and get broadcast to all your contacts every now and then

  52. Zash

    Doesn't feel efficient

  53. flow

    in those situations, your pgp key practically never got re-locked, and it always stayed unlocked, which wouldn't be the case if only messages are signed

  54. flow

    Zash, I think that modern cipher woulds produce smaller signed presences

  55. nav

    XMPP is hardly efficient to start with. As for presence stanzas, they're not being sent all the time but only when your presence status changes.

  56. Zash


  57. nav

    Zash: ?

  58. flow

    nav, depending on the used extension protocols, your presence status changes quite often

  59. nav

    flow: For instance?

  60. Zash

    auto-away etc

  61. flow


  62. flow

    but shoving stuff into presence is now large considered an anti-pattern, rightfully, if I may add

  63. flow

    but shoving stuff into presence is now largely considered an anti-pattern, rightfully, if I may add

  64. nav

    flow: Why would 0256 increase the rate at which <presence/> is being sent?

  65. Zash

    flow, XEP-0319 too!

  66. nav

    It's, as you say, just adding some more stuff into it.

  67. Zash

    Conversations for example has a feature where it sends presence every time you focus or unfocus it.

  68. Zash

    Disabled by default IIRC

  69. Zash

    In any case, it was agreed in the XMPP community long long ago not to shove so much stuff in presence, instead use PEP

  70. nav

    XEP-0319 is a better example, but as long as it's under control of the user I still don't see the problem

  71. flow

    xep256 isn't the best example, but it was the best I could dig up in short time

  72. nav

    Yup, PEP is a good idea.

  73. flow

    nav, but as I wrote, we had previously XEPs that put the last user tune in presence

  74. Zash


  75. flow

    so every 3 minutes or so, you would emit a new presence

  76. flow

    furthermore presence gets amplified by MUCs

  77. flow

    imagine you are in 3 MUCs with the same people

  78. nav

    flow: Yeah, I remember that fad!

  79. flow

    every time someone emits a new presence, you get it 4 times

  80. flow

    (assuming you are also subscribed to the presence0

  81. flow

    and finally, I am not sure what a signed presence gets you

  82. Zash

    I think it might vary a bit actually, some clients don't send presence updates to MUC

  83. flow

    like what do you do with that information?

  84. flow

    how would you behave if it wasn't signed

  85. flow

    how do you behave differently if it was signed?

  86. flow

    Zash, hmm isn't the server doing that?

  87. flow

    but you are the expert on that topic :)

  88. Zash

    Prosody doesn't. Maybe it should? But you get problems.

  89. flow

    I assumed that MUC presence is based on RFC 6121 § 4.6 Directed Presence

  90. Zash

    Like, it gets weird if you change nickname. Should the server broadcast your presence to both nicks?

  91. nav

    flow: "how do you behave differently if it was signed?" Well, that's what I was getting at. I could make certain assumptions as to whether the JID is under control of the same user.

  92. Zash

    nav, your phone gets stolen. now what?

  93. flow

    nav, I am not sure if this answers my question

  94. flow

    could you give a concrete example?

  95. flow

    don't get me wrong, 20 years ago I also believed that signed presence is cool

  96. flow

    but today, I see only drawbacks and no advantages of presence signing

  97. nav

    flow: See the discussion around 1130Z today for background to the discussion.

  98. flow


  99. flow

    and fwiw, I believe signed presences should include a timestamp, for hopefully obvious reasons

  100. flow

    but then you need to define a time-to-live for those

  101. flow

    1h, 3h, 24h, 7d?

  102. nav

    It all comes from the fact that yesterday I accidentally deleted my account 🙄

  103. flow

    in any case you now inveted a new mechanism that causes presences updates

  104. Zash

    Wasn't that one of the problems with XEP-0027, no replay protection?

  105. flow

    nav, probably the better solution would be a signed pep item in a well-defined pep node

  106. nav

    But the component I was testing at the time still kept all the information associated with my JID.

  107. nav

    It dawned on me that the component will wipe out your info if you unregister with it, but not if you unregister from your own server and someone else takes over your JID.

  108. nav

    flow: That sounds sensible.

  109. flow

    I get that point, and I think the solution lies in PEP, not in Presence :)

  110. flow

    you basically want to place a proof of ownership in the PEP node

  111. nav

    My first thought was some kind of UUID but as was pointed out above that was kind of daft and then someone brought up crypo, and here we are.

  112. nav

    Indeed that sounds like a good solution! ✔

  113. nav

    I could get people to register a password with the component but the usability is not quite as good.

  114. nav

    What about discovering and remembering OMEMO nodes?

  115. flow

    if you work out a protcol with one crypto scheme it is easy to apply to the same to another crypto scheme which is able to sign bytes

  116. nav

    On second thought, that probably would not work.

  117. flow

    the main issue is that OMEMO, unlike OpenPGP, has no concept of a primary key

  118. flow

    at least IIRC

  119. nav


  120. nav

    I like the signed PEP node approach. The disadvantage is that it requires explicit client support.

  121. flow

    how could something like that *not* require explicit support from implementations?

  122. nav

    I should have said explicit client support which is not there at the moment. ☺

  123. Zash

    Deploying new things 🤷️

  124. nav

    That's why I was hoping to piggyback on signed <presence/> stanzas, as some clients already do those.

  125. flow

    isn't that always the issue: that we imagine those kewl new protocol extensions, but then suddenly realize that someone needs to implement them? :)

  126. nav

    The cool thing about the signed PEP is that it could be used by people wanting to prove control over a JID *or a group of JIDs*

  127. Zash

    open standards go brrr

  128. nav

    For instance people who have accounts on different servers.

  129. moparisthebest

    what's it proving? that someone with that private key at some point had access to that account and/or server ?

  130. nav

    moparisthebest: Yup

  131. nav

    No more and no less.

  132. moparisthebest

    what's the intended way to use that info ?

  133. nav

    moparisthebest: https://logs.xmpp.org/jdev/2022-07-26?p=h#2022-07-26-8255b4655df233bd

  134. nav

    With reference to the red warning on XEP-0086 (https://xmpp.org/extensions/xep-0086.html)…

  135. nav

    …considering that I am dealing with handling error conditions in the context of XEP-0030 (https://xmpp.org/extensions/xep-0030.html), I guess I should ignore that warning, right?

  136. Zash

    https://xmpp.org/rfcs/rfc6120.html#stanzas-error is where you should look for syntax of errors.

  137. nav


  138. Zash

    And service-unavailable is the error you must return for any iq-get or set that you do not understand.

  139. nav

    Roger that.

  140. nav

    Is that specified somewhere, off the top of your head?

  141. nav

    Or just customary practice?

  142. Zash

    In the RFC I just linked

  143. nav

    Yup, just found it, ta. https://xmpp.org/rfcs/rfc6120.html#stanzas-error-conditions-service-unavailable

  144. Zash

    10.3.3. IQ > If the IQ stanza is of type "get" or "set" and the server does not understand the namespace that qualifies the payload, the server MUST return an error to the sending entity, which MUST be <service-unavailable/>.

  145. nav

    Cool, that makes life easier. ☺

  146. Zash

    There should also be text to the effect that every iq-get and iq-set must have a matching iq-result or iq-error

  147. techmetx11


  148. techmetx11

    how would you implement multiple nicknames in a vcard

  149. nav

    Zash: True

  150. techmetx11

    the DTD says that multiple <NICKNAME> elements can exist, but multiple nicknames must be a comma-seperated list

  151. techmetx11

    (talking about vcard-temp)

  152. Zash

    My personal advice: Ignore vcard-temp.

  153. Zash

    All the cool kids use vcard4

  154. techmetx11

    how much servers do you think support vcard4

  155. Zash

    Also https://xmpp.org/extensions/xep-0172.html

  156. Zash

    All of them!

  157. Zash

    All Modern XMPP servers support PEP, and that is all you need for vcard4

  158. techmetx11

    Zash: i mean multiple nicknames in a vcard-temp

  159. techmetx11

    also the vcard4 xep is deferred

  160. Zash

    vcard-temp is Historical

  161. Zash

    aka ugly things from before there was a standards process

  162. techmetx11

    ... but still active?

  163. Zash

    deferred just means it hasn't moved forward in the standards process for a year

  164. techmetx11

    if you could just please answer my question

  165. Zash

    with how slow the standards process is, one year doesn't really mean much

  166. techmetx11

    i'll try to send a hand-crafted vcard4 retrival request

  167. techmetx11

    and see if it works

  168. Zash

    all I can say is that the Prosody module handling vcard-temp simply takes the XML and saves it as-is

  169. techmetx11

    disroot's server errored out with "No module handling this query"

  170. techmetx11

    so i'm gonna assume, that this isn't as widely implemented as it might seem

  171. techmetx11

    now anyway, my question was

  172. techmetx11

    how do you implement multiple nicknames in a vcard

  173. techmetx11

    i'm gonna assume multiple elements

  174. nav

    techmetx11: I've just tested and multiple elements does not work with ejabberd.

  175. nav

    In theory, according to the DTD on XEP-0054 it should be allowed, but also the XEP does not prescribe what to do with multiple instances of the same tag. Ejabberd just keeps the last received.

  176. nav

    The DTD does say, in a comment, that "Multiple nicknames must be specified as a comma separated list value" (I guess you've already seen that), and that is also how RFC 6350 specifies it: NICKNAME-param = "VALUE=text" / type-param / language-param / altid-param / pid-param / pref-param / any-param NICKNAME-value = text-list (https://datatracker.ietf.org/doc/html/rfc6350#section-6.2.3)

  177. techmetx11


  178. techmetx11

    i was a bit confused