jdev - 2022-07-25


  1. lovetox

    regarding 0045

  2. lovetox

    > A MUC service MUST include the MUC extensions even if the client did not send an empty <x/> element qualified by the 'http://jabber.org/protocol/muc' namespace on entering the room; naturally, a client MUST ignore such information if it does not understand it (in accordance with RFC 6120).

  3. lovetox

    this is from 17.3, rule 10.

  4. lovetox

    what are MUC extensions in that context?

  5. Ge0rG

    lovetox: that reads like GC1.0 join, which we luckily killed with fire a few years ago

  6. lovetox

    i wanted to know what the words MUC Extensions mean in the context of a presence

  7. lovetox

    it MUST include it

  8. lovetox

    what is a MUC Extension

  9. Ge0rG

    The extension is probably the <x xmlns='http://jabber.org/protocol/muc#user'> payload

  10. lovetox

    so do i read this correctly, a service MUST add a x element with a MUC related namespace, in EVERY Presence it sends

  11. Ge0rG

    I think this is only related to the immediate response to a join presence

  12. lovetox

    ok so also in an error presence as a response to a join?

  13. Ge0rG

    The previous wording was: > A MUC service MUST send extended presence to a client even if the client did not send an empty <x/> ele

  14. Ge0rG

    Changed in 2011

  15. Ge0rG

    0045 is not the best worded of XEPs, so maybe it makes sense to remove this point

  16. lovetox

    how would that help ..

  17. lovetox

    im trying to figure out if a MUC service must include <x xmlns='somemucnamespace#> in presences

  18. Ge0rG

    lovetox: I don't see how it could make any sense, so removing it would make the XEP clearer?

  19. Ge0rG

    lovetox: in which presences?

  20. lovetox

    in all

  21. Ge0rG

    well, occupant presences are supposed to have the <x> user element, which other presences are there?

  22. lovetox

    error presence in response to a join, for example, banned, or password needed etc etc

  23. Ge0rG

    how would an error presence with that <x> element look?

  24. Ge0rG

    is it legitimate for a <presence> to contain both the <x> and an error? The examples imply such a thing

  25. lovetox

    it is legitimate to send the content of the presence back as error

  26. lovetox

    obviously if i join, i send <x> with it

  27. lovetox

    but some impl dont do this

  28. lovetox

    so the question is, if the xep intends that they should, if not mirror the initial presence, at least include the <x>

  29. lovetox

    its weird to me from a spec point, that all presences include <x>, but not error presences

  30. Ge0rG

    lovetox: original 0045 allowed joining a room with a presence that doesn't have <x>

  31. Ge0rG

    groupchat 1.0, but we've removed that because you can't see if it's a presence update or a join from a desync client

  32. lovetox

    from a development view, its really painful how often in xmpp we have to guess, or cache somewhere some data, to even determine what a stanza is about

  33. qy

    Do you think that could have been avoided with foreknowledge, or is it a direct consequence of flexibility?

  34. Ge0rG

    it's a consequence of bad protocol design, and by bad design I mean twenty years of moving forward the state of the art ;)

  35. Ge0rG

    Carbons and MAM are pretty bad designs that only result from avoiding breaking changes

  36. qy

    So yeah, could have been avoided with some precognition

  37. qy

    Shame

  38. Ge0rG

    qy: computers and IM were very different twenty years ago

  39. qy

    Ofc

  40. qy

    Im not lamenting it, i dont mind much, was just wondering why

  41. Ge0rG

    XEP-0045 was an attempt to make IRC channels better

  42. lovetox

    its just not consitently a first class citizen

  43. lovetox

    there is type=groupchat, which is good, its clear what we deal with here

  44. lovetox

    but yeah then there are messages which are not type=groupchat, but can still be from a groupchat

  45. lovetox

    presences with <x mucnamespace>

  46. lovetox

    but yeah also presences without it

  47. Ge0rG

    lovetox: error presence is always a response to a presence you sent

  48. lovetox

    if i would design a protocol, single chat and groupchat would be separated pretty hard in ALL aspects

  49. lovetox

    Ge0rG, yes its stuff like this "yeah its a repsonse so the client probably can figure out itself whats this about"

  50. Maranda

    > <lovetox> presences with <x mucnamespace> or private messages with are of type chat

  51. Maranda

    or private messages which are of type chat

  52. lovetox

    thats for me in practice, it generates much development overhead

  53. lovetox

    yeah thats my favorite, private dm type=chat

  54. Maranda

    In theory that should be fixed with ... MIX where everything is type "groupchat" ... maybe ... sorta, If I did glance at 0369 correctly.

  55. Maranda

    at least the message payloads

  56. qy

    I get the impression MIX is in the realm of vaporware atm

  57. Maranda

    More than vaporware, bloatware

  58. Maranda

    it was supposed to simplify stuff but then someone decided it was good to add PubSub to it which extremely complicated stuff instead.

  59. Maranda

    As usual in the best of XMPP traditions.

  60. emus

    MattJ: can we place the new images in the wiki?

  61. Zash

    > but then someone decided it was good to add PubSub to it which extremely complicated stuff instead. Nah, PubSub was there from the beginning. MIX is "what if we used PubSub" taken as far as it goes, from the very first whiteboard drawings.

  62. Zash

    Source: I was there, 3000 years ago, when the courage of... I mean when the early design was drawn up at a Summit

  63. Sam

    What do people do if they unmarshal a bit-of-binary data element and the CID doesn't match the actual hash of the data? I guess when receiving it I can just return an error, but sending it is weird (I either let the user specify the CID in which case it might not match, or I don't but then the XML marshaler doesn't know what hash to use and I don't have a good way to tell it what hash to use

  64. Sam

    )

  65. Sam

    Sorry, very vague question. I suppose it should have been two different things: if the data doesn't match when receiving do you still use it (and cache it under and opaque string tied to that specific user instead of globally by hash) or do you discard it?

  66. Sam

    And "if I have struct{ Data []byte, MaxAge int }" or similar that marshals to a data element, how do you ensure that the output SID is correct?

  67. Link Mauve

    Sam, you take its SHA-1.

  68. Sam

    Link Mauve: I don't understand how that relates to the question

  69. Sam

    I'd rephrase, but I can't tell what the ambiguity or confusion is

  70. Link Mauve

    Sam, that was an answer to your last message only, if you have a Data []byte, you take its SHA-1, prepend cid: and append @bob.xmpp.org and you got the SID.

  71. Zash

    We have a few things where you know some kind of hash before you fetch the full thing. Caps, avatars, BOB e.g. Do any of those XEPs say anything about what to do in this case?

  72. Link Mauve

    Err, I confused SID and CID, sorry.

  73. Zash

    Probably consider it a failure

  74. Link Mauve

    When receiving invalid stuff I tend to reject it and propagate the error to the user so they can tell their contact to fix their thing.

  75. Link Mauve

    For sending, you should aim at not sending anything invalid ever.

  76. Sam

    Link Mauve: you're saying "only support sha1?"

  77. Sam

    In that second question my confusion is that I have no good way to decide what hash to use if multiple are supported

  78. Link Mauve

    Sam, yes, bob only supports SHA-1 IIRC.

  79. Link Mauve

    It doesn’t do XEP-0300’s hash agility.

  80. Link Mauve

    Same as avatars, same as 0115.

  81. Sam

    I don't think that's true

  82. Sam

    It mentions algo+hash, and I don't see anything that says "algo always == sha1"

  83. Link Mauve

    Wanna bet how many clients will support anything but SHA-1, given it’s the only algo used in the examples? ^^'

  84. Sam

    Maybe I just shouldn't support BoB at all then and work on some new way to do this sort of thing; not having any sort of ability to upgrade seems like a pretty serious flaw

  85. Sam

    We do have a problem in general where nothing that uses hashes tells you where to get the canonical name of them and half these specs don't make it clear if you can actually use multiple hashes or not, I don't think it's just this one

  86. Maranda

    > <Zash> Source: I was there, 3000 years ago, when the courage of... I mean when the early design was drawn up at a Summit 🧙‍♂️ that explains the beard

  87. Link Mauve

    Sam, some specs have been updated for that ability, like 0115 → 0390.

  88. Link Mauve

    Actually you seem to be right about hash agility in 0231, it seems to be properly supported, aside from the text form of the algorithm not being spelled out.

  89. Sam

    Oh great, this uses "sha1" and that uses "sha-1", I just realized that my general hash/names stuff is probably wrong for some specs

  90. Link Mauve

    It uses "sha1" as the only example, I could guess sha256 and sha512, but beyond that would it be sha3-256? blake2b-512? With underscores? Undefined here.

  91. Sam

    IIRC the IANA hash database hasn't been updated since sha1 came out too (or something, I don't remember exactly when, just that it's only old hashes)

  92. Sam

    oh, no, it's got sha2 stuff at least. Still, not a lot here: https://www.iana.org/assignments/hash-function-text-names/hash-function-text-names.xhtml

  93. Zash

    and like https://xmpp.org/extensions/xep-0300.html it's different from the 'sha1' used in BoB

  94. Sam

    Anyways, without re-inventing the world I'm now even more stumped about how to implement this properly and my original two questions.

  95. Sam

    Maybe the answer to the first question is to ignore it; caching will be up to the user anyways so I can just hand them the CID and provide a function to verify it against some data to save them a few steps.

  96. Zash

    Time to snort up some Second Syndrome and write BoB 2!

  97. Sam

    Honestly, I can't tell if BoB is actually useful or not but if it is we should probably make it at least sort of consistent and less ambiguous

  98. Zash

    https://www.rfc-editor.org/rfc/rfc6920.html mapped to XMPP mayhaps?

  99. Sam

    huh, TIL they have multiple specs for URLs containing hashes.

  100. Zash

    Just like us!

  101. Sam

    That registry seems more complete at least

  102. Zash

    A-B all the specs

  103. moparisthebest

    maybe we should start doing something like https://quicwg.org/quic-v2/draft-ietf-quic-v2.html to combat people supporting only what's in the examples

  104. Sam

    huh, that's an interesting idea, although I kind of can't imagine it would accomplish anything

  105. Sam

    oh wait, this named information registry doesn't have sha1 in it… so really both these iana registries are pretty useless.

  106. Sam

    I guess sha3 isn't really necessary yet, we could go with the one that has sha2 and sha1 names and try to get it updated later if necessary

  107. Sam

    I wonder if I should even parse this format. CID URls can be anything, and it is a "SHOULD" that they follow this particular format. Maybe I should just treat this as an opaque string.

  108. Zash

    That's one approach

  109. Sam

    Suggested fix: https://github.com/xsf/xeps/pull/1193

  110. Link Mauve

    I’d recommend against adding sha-1 as supported though.

  111. Link Mauve

    Current version says sha1, let’s keep it at it and not add newer unsupported names for the same thing.

  112. Sam

    That's for forward compatibility, but yah, I could go either way.

  113. Sam

    Note that it's only supported when reading, not writing so in theory it never gets used.

  114. Sam

    Also went ahead and submitted a suggestion in response to the form discussion the other day. https://github.com/xsf/xeps/pull/1194\

  115. Sam

    I don't think there was any consensus in the discussion, but it sounded like this was the original intent and it's easy for users who want to mix and match to create a new field type later.

  116. Link Mauve

    Sam, don’t assume someone won’t mess it up, and then every implementation would be forced to add compatibility just for it.

  117. Link Mauve

    If it’s downright forbidden, then nothing has to change.

  118. moparisthebest

    if algo.toLower().startsWith("sha") && algo.endsWith("1") { SHA1 } what could possibly go wrong? :P

  119. Sam

    I'm not sure what you mean by that; that's part of the point, if they mess it up we can still read either

  120. Sam

    The obvious mistake people will make is read "textual names registry" and then just do that and not notice that "sha1" isn't right, so this lets you read both.

  121. moparisthebest

    the legends say this is why microsoft had to skip windows 9

  122. Sam

    But I really don't care either way, I just don't see it causing problems

  123. qy

    moparisthebest: ShaOne

  124. Sam

    Anyways, fixed

  125. Link Mauve

    LGTM!