XSF Discussion - 2022-02-21


  1. kinetik

    Hi, I'm curious if there's an XEP out there that deals with a tree-like structure for conversations, where each response is either root level or is in response to some other message

  2. kinetik

    (sort of like how reddit structures things, but without all the other stuff)

  3. Sam

    It's built into the RFC, but nothing uses it as far as I know: https://datatracker.ietf.org/doc/html/rfc6121#section-5.2.5

  4. rion

    Interesting. I didn't know it's there but always missed that thing after slack. Definitely something worthing to implement

  5. Link Mauve

    Some clients use it, I know of at least Movim.

  6. MattJ

    The problem with threading is not really the protocol, but the UI

  7. Kev

    Just relying on thread doesn't work very well (like so many things) unless you have complete knowledge, though,.

  8. Kev

    Another thing we could really do with MAM understanding.

  9. Tobias

    Or have MAM support a thread query filter.

  10. Kev

    That would be MAM understanding threads :)

  11. Tobias

    Kind of. Can't you already query for other properties like addresses or body text?

  12. Zash

    Implementation-dependent

  13. Zash

    Not mandated by XEP-0313

  14. Tobias

    True

  15. Zash

    The basic set of fields are all derived from insertion into the archive (archive-id, timestamp, with=to|from depending on direction), not properties of the stanza itself

  16. Tobias

    But technically not all that complex to allow querying for stanza properties, considering it ends up in some kind of database anyway.

  17. Zash

    You probably want to have some index over the things you query on

  18. Zash

    Should be doable too of course

  19. Tobias

    True

  20. Kev

    Querying for a hierarchy of thread references would probably not be a very enjoyable SQL statement to write (or whatever).

  21. larma

    MattJ, I think the thread protocol IS a problem. It had a completely different concept in mind than what we call threads in Slack or even e-Mails nowadays.

  22. larma

    MattJ, I think the thread protocol in RFC 6121 IS a problem. It had a completely different concept in mind than what we call threads in Slack or even e-Mails nowadays.

  23. Kev

    Howso?

  24. larma

    Threads in Slack and e-Mails is basically something like a collection of replies (including depth with replies to replies in e-Mail). Threads in RFC 6121 is more like a session (with child sessions). For example, if we do a board meeting in this channel, the board meeting could be a thread and each agenda sub items could be a sub-thread.

  25. larma

    In Slack/e-Mails, a thread starts with a message and all other messages in the thread are child of that message. In RFC 6121 the first and subsequent messages of a thread are the same level.

  26. larma

    In Slack/e-Mails, a thread starts with a message and all other messages in the thread are child of that message. In RFC 6121 the first and subsequent messages of a thread are the same level (except for sub-threads, which are largely independent and also fork of a thread, not a specific message of that thread)

  27. Andrzej

    can't we just use https://xmpp.org/extensions/xep-0372.html#usecase_previous for linking messages and building a tree?

  28. larma

    Andrzej, 0372 ยง 3.4 is about adding a reference (aka a link) to a previous message where the original message forgot to include the link, not about having your new message reference an old message.

  29. larma

    > An example of this might be where a MIX channel asynchronously adds information about references made in previous messages by users. In this case the message MUST NOT contain a body.

  30. Andrzej

    ok, my bad

  31. larma

    https://xmpp.org/extensions/xep-0461.html would have the correct syntax, but is specifically not meant for creating threads but rather for telegram/whatsapp like replies

  32. larma

    Because it's close to impossible to build the thread feature in a backwards compatible fashion

  33. Kev

    larma: Right, the 'not sending to the channel' thing is Slack/Discord/Guilded/etc.-ish. I'm not convinced the same is true of email - they're all still at the same level logically. My intention with MIX was that threads would go off on their own node within the room.

  34. larma

    "Best" way is probably to not show the thread to non-supporting clients...

  35. larma

    "Best" way is probably to not show a thread to non-supporting clients...

  36. Kev

    Probably going to be hard to get agreement on whether best is to flood a non-supporting client or to deny them completely. But I think once you've got a community where threads are in use any fallback is going to suck one way or another.

  37. Kev

    (I'm pro-threads, BTW, in case that doesn't come across)

  38. larma

    Kev, even if we agree flooding non-supporting clients with fallback messages, what would you put in such fallback messages?

  39. Kev

    Of course, if you have supporting clients, and you have MAM understanding threads, <thread> is just about enough to get going with.

  40. Kev

    > Kev, even if we agree flooding non-supporting clients with fallback messages, what would you put in such fallback messages? Yes, it's not going to be very satisfying whatever you do there.

  41. larma

    If you want Slack-like UI, how do you fork a thread off a message that did not carry a <thread> already? RFC 6121 requires the initial message of a thread to already carry a thread id.

  42. Ellenor Malik

    could message and thread IDs exist in the same namespace, where a thread ID of a message A being the message ID of a message B is illegal?

  43. Ellenor Malik

    does a msg ID facility exist?

  44. larma

    > The value of the <thread/> element MUST uniquely identify the conversation thread either between the conversation partners or more generally

  45. Kev

    So we're saying that we need a forklift update to the network to support a feature we've had standardised since 2004? :)

  46. MattJ

    Ellenor Malik: we have at least 4 ways of adding IDs to messages, so I hope we're good on that front :)

  47. Ellenor Malik

    > Kev wrote: > So we're saying that we need a forklift update to the network to support a feature we've had standardised since 2004? :) I think so.

  48. larma

    Kev, well, I feel the feature that was standardized isn't exactly what people want.

  49. larma

    Also the specifications are sometimes very vague

  50. Ellenor Malik

    The value of the element could be assumed if not specified?

  51. Ellenor Malik

    The value of the thread element could be assumed if not specified?

  52. larma

    Also reading XEP-0201 again: > the value of the <thread/> element shall be considered equivalent to a unique identifier for the chat session

  53. Kev

    larma: I think that's true of a lot of our specs - that they (deliberately) define the protocol, but not how to use it for particular use cases. Whether that's a problem or not probably depends who you ask, but it does mean three people wanted to produce a threads-based system at the moment, they'd probably end up with four logically incompatible systems.

  54. larma

    I remember that some client (I think it was Gajim) implemented RFC 6121 threads. All messages in a conversation used the same thread id unless you close the conversation and reopen it. That sounds like what XEP-0201 has in mind, but totally is not what Slack or the likes do.

  55. larma

    XEP-0201 even suggests color coding the thread information. I can imagine that to work pretty good (a message in thread A has a red bar inn front of it, a message in thread B a green bar and a message in thread C that is a child of A has a red and a blue bar), but again it's completely different than Slack-like

  56. larma

    The RFC 6121/XEP-0201 threads seem more similar to the thread concept of Zulip

  57. MattJ

    And many people absolutely hate Slack's threading

  58. Kev

    I think using the same thread for a conversation unless you branch off is probably sane, isn't it?

  59. MattJ

    Which goes back to what I said earlier - it's mostly a UI problem, not a protocol one

  60. Ellenor Malik

    the new threads could be called chains

  61. Ellenor Malik

    idk

  62. Kev

    > And many people absolutely hate Slack's threading I know that's true, but are these people who want a *different* threading model, or just hate threads?

  63. Ellenor Malik

    i am like, not a standardizer

  64. MattJ

    Kev, I've seen both camps :)

  65. MattJ

    e.g. Zulip is crazy about threads, and I know people who love that and hate Slack's implementation

  66. MattJ

    They're both threading, but very differently done

  67. MattJ

    And with this being such a subjective feature, I don't see how we can standardize threading across the ecosystem in any particular way

  68. MattJ

    Unless every client is expected to implement the protocol and UI for every type of threading

  69. MattJ

    (which is obviously absurd)

  70. Kev

    How does Zulip do it?

  71. larma

    MattJ, you can easily do the threading of Zulip in Slack, it just needs discipline. The UI of Zulip is better in enforcing things.

  72. Zash

    Can't you do all kinds of threads with `<thread/>` already?

  73. larma

    Kev, in short, every message has a topic and messages of the same topic form a thread. If you reply to a message, it will be the same topic, if you create a new message you have to specify the topic

  74. larma

    Kev, in short, every message has a topic and messages of the same topic form a thread. If you reply to a message, it will be the same topic as the message you replied to, if you create a new message you have to specify the topic

  75. larma

    There is no "root thread" in a channel

  76. Zash

    Just have to pick a style and be consistent. So it's impossible.

  77. larma

    Zash, I guess the problem is that <thread> doesn't really define how to do things. At that makes it IMO useless in a federated environment of different clients.

  78. Zash

    Yup

  79. larma

    There are a few things though that don't work with threads.

  80. larma

    Or at least not sensible

  81. larma

    You could just make <thread> behave as <reply-to>, that is, every message creates a new thread and that new thread has the thread id of the message it replied to as a parent thread id. This would allow e-Mail like thread trees (where a message has a parent message and not a thread a parent thread) and Slack-like off-threads. If you want to make it easier, pick your thread id to always be your message id, so you spare one id. Make it even easier and remove the <thread> alltogehter and just have a <parent> that references the message id instead of thread id.

  82. edhelas

    movim is doing that :)

  83. larma

    Are you also picking thread id = message id?

  84. Ellenor Malik

    Thread id = message id would mainly make it easier to search for messages threaded up to a given message id

  85. edhelas

    no, those are different things afaik

  86. larma

    Ellenor Malik, it also means you have to handle one id less, we already have a bunch of ids on every message, so not adding another one would be a good idea.

  87. moparisthebest

    so I've read https://datatracker.ietf.org/doc/html/rfc7712 and https://xmpp.org/extensions/xep-0344.html but one thing remains unclear: you got server A accepting s2s from server B, server B sends a certificate for sasl external that is not signed by a CA so A doesn't immediatly trust it, is the solution to immediately go for dialback? or has anyone considered using POSH or DANE in this case? I'm thinking it'd be secure to "get all hashes that can be used for that domain" and check that the certificate matches at least one of them, in which case you offer SASL EXTERNAL and never do dialback? cc dwd and Zash since I know they've worked on this, though looks like dwd is not currently here :/

  88. moparisthebest

    if you squint *real* hard, that's *almost* what is said by https://xmpp.org/extensions/xep-0344.html#samecert including DANE+POSH in the lookup, just skipping the actual connecting step

  89. Zash

    I don't understand the question.

  90. moparisthebest

    Zash, tl;dr how to authenticate incoming S2S certificate using DANE/POSH without dialback

  91. Zash

    The implementations I did do all the lookups and use that, yes.

  92. Zash

    I.e. for DANE it does SRV and then TLSA lookups for each SRV

  93. moparisthebest

    and just trust the connection if any TLSA record matches ?

  94. Zash

    Same check as for outgoing, yes.

  95. moparisthebest

    without actually making outgoing XMPP connections ?

  96. Zash

    Correct

  97. moparisthebest

    excellent, that seemed secure and the right thing to do, but it's not actually written down anywhere is it ?

  98. Zash

    I think that's what the DANCE WG is about <https://datatracker.ietf.org/wg/dance/about/>

  99. Zash

    Unfortunately I don't have the energy for IETF

  100. moparisthebest

    ah, indeed that looks right, thanks!

  101. moparisthebest

    I'd be happy with just a best practices XEP

  102. Zash

    The Cool Thing would be for the client to look up its own TLSA stuff and include that in the TLS handshake along with client certificate, like kinda like the backwards OCSP

  103. Zash

    The Cool Thing would be for the client to look up its own TLSA stuff and include that in the TLS handshake along with client certificate, kinda like the backwards OCSP

  104. moparisthebest

    > TLS extension to indicate DANE identification capability and the client's DANE identity name to WGLC (PS)

  105. moparisthebest

    that *might* be what they are after there

  106. Zash

    Yes

  107. Zash

    Also, this kind of thing was implemented in Chrome once upon a time! (In the other direction tho)

  108. moparisthebest

    we also used to have HPKP but that went away too :(

  109. Zash

    Wasn't that a huge footgun?

  110. moparisthebest

    I mean, no more than DANE or DNSSEC in general is I guess ?

  111. Zash

    As in, didn't it permanently burn the domain if you messed it up?

  112. moparisthebest

    no, only for the TTL

  113. moparisthebest

    course if you made the TTL very long, well your bad

  114. Zash

    I don't remember, what were the recommendations?

  115. Zash

    HSTS TTL recommendations tend to be like 6 months or more AFAIK

  116. moparisthebest

    > Note: These examples use a max-age of two months and include all subdomains. It is advised to verify that this setup will work for your server.

  117. moparisthebest

    from https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key_Pinning , and since everyone only looks at the examples... :D

  118. moparisthebest

    RFC doesn't seem to suggest anything

  119. Zash

    Maybe I should just shoot myself in the DNSSEC and see how long it takes to recover

  120. Zash

    Should be on the order of hours

  121. moparisthebest

    yea you generally don't have a DNS TTL of 2 months

  122. Zash

    Worst case if someone is trying to mess with you would be a couple of weeks

  123. moparisthebest

    but both HPKP and DNSSEC/DANE should be the same in regard to breaking your website for however long your TTL says

  124. Zash

    Relatedly I did a CDS based key rollover and it was painless to the point of boring.

  125. moparisthebest

    I've only rotated my DNSSEC keys once so far and I don't remember it being a problem but also don't remember details

  126. Zash

    As in, publish new keys and delegation records and the parent zone picks them up.

  127. Zash

    Dealing with certbot has been cumulatively more painful by now, and I don't even use it

  128. moparisthebest

    I only use acme.sh which by default doesn't change your key, so my key is published in a TLSA that never has to change

  129. moparisthebest

    also still using HPKP...

  130. Zash

    dehydrated also has the amazing feature of _not_ replacing your keys

  131. Zash

    Found out recently it can generate keys before using them, for rollover, which I'm in the middle of figuring out how to do.

  132. moparisthebest

    for hpkp I just generated encrypted backup keys years ago and published them, haven't switched to using them yet though

  133. moparisthebest

    Standards-wise I think I'm really leaning towards putting both discovery of connection methods (to replace srv) and key material (to replace Dane+posh) in host-meta, so we aren't adding yet another thing to look up, just parsing more things from the existing one...

  134. moparisthebest

    In my ideal world with dnssec everywhere we'd just use srv+dane instead, but that doesn't seem likely to happen soon? :'(

  135. guus.der.kinderen

    Does anyone have experience with moving a server-implementation from stringprep to precis?

  136. guus.der.kinderen

    some quick tests on our server show that out of 241277, 68 seem to have issues when trying to compare them to all others.

  137. guus.der.kinderen

    (I ment to inject 'usernames' in there somewhere)

  138. moparisthebest

    I thought the consensus was that couldn't be done