jdev - 2021-05-05

  1. flow

    moparisthebest, thanks, but POODLE and friends operate on the cryptographic's layer padding, whereas SCE (and OX) operate on the ciphertext. I *think* that makes a difference, but I am by no means an expert in this field

  2. flow

    strictly speaking, <rpad/> is also no padding (at least how I understand padding), so it could be possible that the name of the element was badly choosen. I take full responsibility for that one :)

  3. marc0s

    hi, how do you handle muc joins in carbon-copied sessions? Thinking about it, I would say that I should react to the presence message directed to my bare jid with a 110-code status child in it so I can redraw the UI with that muc in the list. Other alternatives would be to react to the first message from a recipient that I don't already track, or joining as well whenever an invite is carbon-copied to me, but that leaves out non-invite-based joins. Thanks!

  4. MattJ

    marc0s, MUC traffic is (as a general rule) not cc'd, everything goes to the full JID of the joining session

  5. MattJ

    One exception is private messages from other MUC occupants, which do get copied by default (for this reason most implementations hopefully tag them an <x> in the MUC namespace, so clients can handle them appropriately)

  6. marc0s

    thanks for the correction MattJ. How do clients handle then sharing the information about joined MUCs across sessions?

  7. MattJ

    Short answer... they don't

  8. MattJ

    Longer answer, the "autojoin" flag on MUC bookmarks is the current best signal for that

  9. MattJ

    There have been threats of a dedicated protocol, but so far I don't think any have been submitted

  10. MattJ

    But power users want to keep the ability to join rooms on some devices and not others, etc.

  11. marc0s

    so, best bet is to rely in bookmarks and properly propagate changes on them to all available sessions, right?

  12. Zash

    via PEP notifications, is what at least Conversations and Dino does

  13. marc0s

    makes sense

  14. flow

    which works well, im my experience

  15. marc0s

    thank you all, helpful as always :)

  16. Zash

    Except for the power user wish of not burdening ones phone with e.g. big noisy public channels

  17. marc0s


  18. MattJ

    Pesky power users. Pity they're the ones who write all the specs and develop all the apps :)

  19. Kev

    Except for me. I pretty much just want it to work as if it was Discord/Slack :D

  20. lovetox

    edhelas, Zash: i think the avatar xep is mistunderstood

  21. lovetox

    only because the info element provides height and width

  22. lovetox

    does not mean the xep supports multiple resolutions of the same picture

  23. lovetox

    i read this XEP over and over, and come always to the same conclusion, it was never intended

  24. lovetox

    sentences like that for example bring me to that conclusion

  25. lovetox

    The <metadata/> root element MAY contain more than one <info/> element. Each <info/> element MUST specify metadata for the same avatar image but in alternate content-types (e.g., "image/png", "image/gif", and "image/jpeg"), and one of the formats MUST be "image/png" to ensure interoperability.

  26. lovetox

    its for different content-types

  27. Zash

    I have a council hat and I say let's do it anyway!

  28. lovetox

    you may argue you can add multiple image/png

  29. lovetox

    but then some things are underspecified

  30. lovetox

    for example which hash of which resolution will be the item id of the metadata node

  31. Zash

    The XEP has history going back ~18 years. Requirements and expectations drift a bit over time.

  32. Zash

    We haven't really used it until recently anyway

  33. Zash

    It could do with a touch-up

  34. lovetox

    its also very akward in many situations

  35. lovetox

    for example you can not communicate an addition of another resolution

  36. lovetox

    because the sha would not change from the default avatar

  37. lovetox

    or if you add another content-type than image/png

  38. Zash

    Pick one .png as the "default". Put it first. Use its sha1 as item-id

  39. edhelas

    lovetox what is also interesting is that the metadata node id item is having the hash of the png version

  40. edhelas

    and not itemid="current" like for many other xeps like that

  41. edhelas

    this means that you can actually store several metadata items

  42. Zash

    But you have no way to select the primary

  43. edhelas

    "oldest" in order :D

  44. edhelas

    pubsub is ordered

  45. edhelas

    you have pagination on pubsub items

  46. Zash

    The vcard-temp legacy compat stuff in Prosody will pick the item-id of the newest entry and use that in the xep-153-presence thing

  47. edhelas

    in Telegram you cannot reorder your pictures

  48. edhelas

    actually is "latest uploaded is the main one"

  49. edhelas

    so it could fit there

  50. Zash

    You could re-publish the metadata item to reorder, I guess.

  51. edhelas


  52. lovetox

    edhelas, but then the notification mechanism of pep does not work anymore

  53. lovetox

    bookmarks 2 does only work with multiple items

  54. Zash

    why doesn't what work?

  55. lovetox

    because its a nessecery to query all bookmarks at start

  56. lovetox

    then register to updates

  57. lovetox

    Zash because pep says you get the *last* published item

  58. edhelas

    exisiting PEP Avatar clients will still work the same way

  59. lovetox

    and not all

  60. edhelas

    they will pick "the latest" picture only

  61. lovetox

    it not "old" clients

  62. Zash

    So last one is the primary one, that you see unless you go out of your way to look at older avatars, if you have such a feature

  63. lovetox

    its not a viable way to query all avatar elements from all contacts at start

  64. edhelas

    if latest element != currently stored element => query the whole list again

  65. edhelas

    and then you can have your +notify to notify you if the list changed

  66. Zash

    PubSub Since ?

  67. lovetox

    no, if i update my avatar

  68. lovetox

    thats my new avatar

  69. lovetox

    and my old one should be dead

  70. lovetox

    a client who starts to query old avatars and treat it like different versions

  71. edhelas


  72. lovetox

    i mean that was never intended, and just because the xep could be used like that

  73. lovetox

    no one does it, its not documented

  74. lovetox

    i dont see this in any way viable

  75. Zash

    Document it, patch the XEP! We can do it!

  76. qrpnxz

    anyone have a regex on hand for JIDs?

  77. Sam

    There is no such thing; regular expressions are regular, JIDs are not.

  78. lovetox

    if you are happy with regex that is not perfect, google regex for email, should be close enough

  79. edhelas

    wow wow wow :D

  80. edhelas

    email != jid

  81. Sam

    Nope nope nope nope

  82. Sam

    I can almost guarantee you that just implementing the splitting algorithm (if you don't care about actual validation and just want the parts) is easier

  83. Sam

    But there's interesting discussion of it going on in operators@ if anyone is interested

  84. lovetox

    i said its close enough

  85. edhelas

    nah :D

  86. edhelas

    better validate something@something then

  87. lovetox

    im sure if you google email regex thats one of the propsed solutions

  88. lovetox

    Sam i think applying the splitting algo is slow

  89. lovetox

    if someone says regex its not only for "i want to know if this string is a jid"

  90. lovetox

    its also for i have these 10000 lines of text and want to find all jids

  91. Link Mauve

    lovetox, but my JID is foo, most email regexes won’t match this perfectly valid JID!

  92. Sam

    It's definitely not slower than compiling and running a regexp, especially with the crappy recursive backtracking algorithm most regexp parsers use

  93. lovetox

    Link Mauve, it was always about close enough

  94. Sam

    But sure, I suppose for finding "things that might be JIDs" in a bunch of text I'd probably do a quick regexp too, fair enough

  95. Link Mauve

    Most words will match then. :)

  96. Sam

    I can't imagine anyone cares about the JID "foo".

  97. Sam

    If they're parsing for things that look like JIDs in a document at least

  98. Link Mauve

    Then they’re not looking for JIDs, but for bare user or MUC JIDs.

  99. Link Mauve

    So basically anything containing a @.

  100. Sam

    Sure, more or less, I assumed that's what lovetox meant when they said they were looking in a document

  101. Sam

    We're talking about looking for JIDs with a regexp… no need to be precis here (pun intended).

  102. lovetox

    yes if people get messages, they want URLs, JIDs, Emails all highlighted

  103. lovetox

    so they can click them

  104. pulkomandy

    Smalltalk: everything is an object Tcl: everything is a string Xmpp: everything is a JID

  105. qrpnxz

    Sam, didn't know JID were not regular. What kind of nesting can they have?

  106. qrpnxz

    i'm sceptical tbh. I'm gonna spend hours trying to make one now aren't I... Wish me luck.

  107. Sam

    If you just want to split it I'm wrong I think, I was being dumb about resource parts

  108. Sam

    https://lab.louiz.org/poezio/slixmpp/-/blob/master/slixmpp/jid.py#L26 may be good enough fir you.

  109. Sam

    Still, it's probably a bad idea.

  110. moparisthebest

    > probably a bad idea. So... All technology then?