XSF Discussion - 2022-02-21

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

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

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

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

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

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

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

Another thing we could really do with MAM understanding.

Or have MAM support a thread query filter.

That would be MAM understanding threads :)

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

Implementation-dependent

Not mandated by XEP-0313

True

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

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

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

Should be doable too of course

True

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

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. ✏

Howso?

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.

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) ✏

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

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.

> 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.

ok, my bad

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

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

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.

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

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.

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

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

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

> 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.

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.

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?

does a msg ID facility exist?

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

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

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

> 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.

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

Also the specifications are sometimes very vague

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

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

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.

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.

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

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

And many people absolutely hate Slack's threading

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

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

the new threads could be called chains

idk

> 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?

i am like, not a standardizer

Kev, I've seen both camps :)

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

They're both threading, but very differently done

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

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

(which is obviously absurd)

How does Zulip do it?

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

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

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 ✏

There is no "root thread" in a channel

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

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.

Yup

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

Or at least not sensible

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.

movim is doing that :)

Are you also picking thread id = message id?

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

no, those are different things afaik

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.

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 :/

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

I don't understand the question.

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

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

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

and just trust the connection if any TLSA record matches ?

Same check as for outgoing, yes.

without actually making outgoing XMPP connections ?

Correct

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

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

Unfortunately I don't have the energy for IETF

ah, indeed that looks right, thanks!

I'd be happy with just a best practices XEP

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 ✏

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

that *might* be what they are after there

Yes

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

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

Wasn't that a huge footgun?

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

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

no, only for the TTL

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

I don't remember, what were the recommendations?

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

> 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.

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

RFC doesn't seem to suggest anything

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

Should be on the order of hours

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

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

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

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

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

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

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

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

also still using HPKP...

dehydrated also has the amazing feature of _not_ replacing your keys

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

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

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...

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

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

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

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

I thought the consensus was that couldn't be done