-
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
-
kinetik
(sort of like how reddit structures things, but without all the other stuff)
-
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
-
rion
Interesting. I didn't know it's there but always missed that thing after slack. Definitely something worthing to implement
-
Link Mauve
Some clients use it, I know of at least Movim.
-
MattJ
The problem with threading is not really the protocol, but the UI
-
Kev
Just relying on thread doesn't work very well (like so many things) unless you have complete knowledge, though,.
-
Kev
Another thing we could really do with MAM understanding.
-
Tobias
Or have MAM support a thread query filter.
-
Kev
That would be MAM understanding threads :)
-
Tobias
Kind of. Can't you already query for other properties like addresses or body text?
-
Zash
Implementation-dependent
-
Zash
Not mandated by XEP-0313
-
Tobias
True
-
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
-
Tobias
But technically not all that complex to allow querying for stanza properties, considering it ends up in some kind of database anyway.
-
Zash
You probably want to have some index over the things you query on
-
Zash
Should be doable too of course
-
Tobias
True
-
Kev
Querying for a hierarchy of thread references would probably not be a very enjoyable SQL statement to write (or whatever).
-
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.✎ -
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. ✏
-
Kev
Howso?
-
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.
-
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.✎ -
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) ✏
-
Andrzej
can't we just use https://xmpp.org/extensions/xep-0372.html#usecase_previous for linking messages and building a tree?
-
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.
-
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.
-
Andrzej
ok, my bad
-
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
-
larma
Because it's close to impossible to build the thread feature in a backwards compatible fashion
-
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.
-
larma
"Best" way is probably to not show the thread to non-supporting clients...✎ -
larma
"Best" way is probably to not show a thread to non-supporting clients... ✏
-
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.
-
Kev
(I'm pro-threads, BTW, in case that doesn't come across)
-
larma
Kev, even if we agree flooding non-supporting clients with fallback messages, what would you put in such fallback messages?
-
Kev
Of course, if you have supporting clients, and you have MAM understanding threads, <thread> is just about enough to get going with.
-
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.
-
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.
-
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?
-
Ellenor Malik
does a msg ID facility exist?
-
larma
> The value of the <thread/> element MUST uniquely identify the conversation thread either between the conversation partners or more generally
-
Kev
So we're saying that we need a forklift update to the network to support a feature we've had standardised since 2004? :)
-
MattJ
Ellenor Malik: we have at least 4 ways of adding IDs to messages, so I hope we're good on that front :)
-
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.
-
larma
Kev, well, I feel the feature that was standardized isn't exactly what people want.
-
larma
Also the specifications are sometimes very vague
-
Ellenor Malik
The value of the element could be assumed if not specified?✎ -
Ellenor Malik
The value of the thread element could be assumed if not specified? ✏
-
larma
Also reading XEP-0201 again: > the value of the <thread/> element shall be considered equivalent to a unique identifier for the chat session
-
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.
-
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.
-
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
-
larma
The RFC 6121/XEP-0201 threads seem more similar to the thread concept of Zulip
-
MattJ
And many people absolutely hate Slack's threading
-
Kev
I think using the same thread for a conversation unless you branch off is probably sane, isn't it?
-
MattJ
Which goes back to what I said earlier - it's mostly a UI problem, not a protocol one
-
Ellenor Malik
the new threads could be called chains
-
Ellenor Malik
idk
-
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?
-
Ellenor Malik
i am like, not a standardizer
-
MattJ
Kev, I've seen both camps :)
-
MattJ
e.g. Zulip is crazy about threads, and I know people who love that and hate Slack's implementation
-
MattJ
They're both threading, but very differently done
-
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
-
MattJ
Unless every client is expected to implement the protocol and UI for every type of threading
-
MattJ
(which is obviously absurd)
-
Kev
How does Zulip do it?
-
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.
-
Zash
Can't you do all kinds of threads with `<thread/>` already?
-
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✎ -
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 ✏
-
larma
There is no "root thread" in a channel
-
Zash
Just have to pick a style and be consistent. So it's impossible.
-
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.
-
Zash
Yup
-
larma
There are a few things though that don't work with threads.
-
larma
Or at least not sensible
-
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.
-
edhelas
movim is doing that :)
-
larma
Are you also picking thread id = message id?
-
Ellenor Malik
Thread id = message id would mainly make it easier to search for messages threaded up to a given message id
-
edhelas
no, those are different things afaik
-
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.
-
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 :/
-
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
-
Zash
I don't understand the question.
-
moparisthebest
Zash, tl;dr how to authenticate incoming S2S certificate using DANE/POSH without dialback
-
Zash
The implementations I did do all the lookups and use that, yes.
-
Zash
I.e. for DANE it does SRV and then TLSA lookups for each SRV
-
moparisthebest
and just trust the connection if any TLSA record matches ?
-
Zash
Same check as for outgoing, yes.
-
moparisthebest
without actually making outgoing XMPP connections ?
-
Zash
Correct
-
moparisthebest
excellent, that seemed secure and the right thing to do, but it's not actually written down anywhere is it ?
-
Zash
I think that's what the DANCE WG is about <https://datatracker.ietf.org/wg/dance/about/>
-
Zash
Unfortunately I don't have the energy for IETF
-
moparisthebest
ah, indeed that looks right, thanks!
-
moparisthebest
I'd be happy with just a best practices XEP
-
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✎ -
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 ✏
-
moparisthebest
> TLS extension to indicate DANE identification capability and the client's DANE identity name to WGLC (PS)
-
moparisthebest
that *might* be what they are after there
-
Zash
Yes
-
Zash
Also, this kind of thing was implemented in Chrome once upon a time! (In the other direction tho)
-
moparisthebest
we also used to have HPKP but that went away too :(
-
Zash
Wasn't that a huge footgun?
-
moparisthebest
I mean, no more than DANE or DNSSEC in general is I guess ?
-
Zash
As in, didn't it permanently burn the domain if you messed it up?
-
moparisthebest
no, only for the TTL
-
moparisthebest
course if you made the TTL very long, well your bad
-
Zash
I don't remember, what were the recommendations?
-
Zash
HSTS TTL recommendations tend to be like 6 months or more AFAIK
-
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.
-
moparisthebest
from https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key_Pinning , and since everyone only looks at the examples... :D
-
moparisthebest
RFC doesn't seem to suggest anything
-
Zash
Maybe I should just shoot myself in the DNSSEC and see how long it takes to recover
-
Zash
Should be on the order of hours
-
moparisthebest
yea you generally don't have a DNS TTL of 2 months
-
Zash
Worst case if someone is trying to mess with you would be a couple of weeks
-
moparisthebest
but both HPKP and DNSSEC/DANE should be the same in regard to breaking your website for however long your TTL says
-
Zash
Relatedly I did a CDS based key rollover and it was painless to the point of boring.
-
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
-
Zash
As in, publish new keys and delegation records and the parent zone picks them up.
-
Zash
Dealing with certbot has been cumulatively more painful by now, and I don't even use it
-
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
-
moparisthebest
also still using HPKP...
-
Zash
dehydrated also has the amazing feature of _not_ replacing your keys
-
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.
-
moparisthebest
for hpkp I just generated encrypted backup keys years ago and published them, haven't switched to using them yet though
-
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...
-
moparisthebest
In my ideal world with dnssec everywhere we'd just use srv+dane instead, but that doesn't seem likely to happen soon? :'(
-
guus.der.kinderen
Does anyone have experience with moving a server-implementation from stringprep to precis?
-
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.
-
guus.der.kinderen
(I ment to inject 'usernames' in there somewhere)
-
moparisthebest
I thought the consensus was that couldn't be done