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
sabryhas left
neshtaxmpphas left
neshtaxmpphas joined
kinetik
(sort of like how reddit structures things, but without all the other stuff)
BASSGODhas left
millesimushas left
restive_monkhas left
sabryhas joined
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
millesimushas joined
andrey.ghas joined
Andrzejhas joined
restive_monkhas joined
sabryhas left
sabryhas joined
restive_monkhas left
jcbrandhas joined
adiaholichas joined
restive_monkhas joined
restive_monkhas left
matkorhas joined
jcbrandhas left
restive_monkhas joined
adiaholichas left
qwestionhas joined
emushas left
alacerhas joined
stphas joined
Vidakhas joined
adiaholichas joined
Andrzejhas left
BASSGODhas joined
matkorhas left
andrey.ghas left
tykaynhas left
stphas left
alacerhas left
Vidakhas left
adiaholichas left
matkorhas joined
alacerhas joined
adiaholichas joined
adiaholichas left
Matthew (away)has left
homebeachhas left
Rixon 👁🗨has left
uhoreghas left
Half-Shothas left
Half-Shothas joined
Matthew (away)has joined
Rixon 👁🗨has joined
uhoreghas joined
homebeachhas joined
Andrzejhas joined
adiaholichas joined
argentumhas left
wladmishas left
Friendly Resident Cynichas left
daagshas joined
qwestionhas left
Andrzejhas left
matkorhas left
matkorhas joined
Friendly Resident Cynichas joined
Andrzejhas joined
qwehas joined
Yagizahas joined
Andrzejhas left
Calvinhas joined
qwehas left
marc0shas left
marc0shas joined
florettahas left
florettahas joined
adiaholichas left
Menelhas joined
adiaholichas joined
Titihas joined
millesimushas left
mimi89999has left
mimi89999has joined
eevvoorhas left
alacerhas left
eevvoorhas joined
xnamedhas left
Sevehas joined
petehas left
Andrzejhas joined
millesimushas joined
paulhas joined
Tobiashas joined
Titihas left
florettahas left
florettahas joined
adiaholichas left
adiaholichas joined
adiaholichas left
adiaholichas joined
Titihas joined
me9has joined
msavoritiashas joined
ti_gj06has joined
Vidakhas joined
chronosx88has joined
wurstsalathas joined
ti_gj06has left
ti_gj06has joined
me9has left
Andrzejhas left
Vidakhas left
sabryhas left
chronosx88has left
chronosx88has joined
jcbrandhas joined
millesimushas left
Paganinihas left
millesimushas joined
Vidakhas joined
sabryhas joined
Vidakhas left
Vidakhas joined
marchas joined
Guushas left
Guushas joined
Menelhas left
ti_gj06has left
sabryhas left
ti_gj06has joined
xnamedhas joined
goffihas joined
xnamedhas left
debaclehas joined
Mikaelahas joined
marchas left
marchas joined
emushas joined
eabhas left
eabhas joined
norkkihas left
Sevehas left
Andrzejhas joined
millesimushas left
norkkihas joined
rion
Interesting. I didn't know it's there but always missed that thing after slack. Definitely something worthing to implement
Sevehas joined
adiaholichas left
fhtesthas joined
adiaholichas joined
Link Mauve
Some clients use it, I know of at least Movim.
adiaholichas left
adiaholichas joined
MattJ
The problem with threading is not really the protocol, but the UI
millesimushas joined
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.
wladmishas joined
Andrzejhas left
Matthew (away)has left
homebeachhas left
Rixon 👁🗨has left
uhoreghas left
Half-Shothas left
Half-Shothas joined
Matthew (away)has joined
Rixon 👁🗨has joined
uhoreghas joined
homebeachhas joined
Tobias
Or have MAM support a thread query filter.
Kev
That would be MAM understanding threads :)
millesimushas left
xnamedhas joined
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.
Andrzejhas joined
Zash
You probably want to have some index over the things you query on
Zash
Should be doable too of course
Tobias
True
Dele Olajidehas joined
marchas left
marchas joined
APachhas left
pasdesushihas joined
adiaholichas left
chronosx88has left
Kev
Querying for a hierarchy of thread references would probably not be a very enjoyable SQL statement to write (or whatever).
adiaholichas joined
Andrzejhas left
Dele Olajidehas left
adiaholichas left
adiaholichas joined
millesimushas joined
wladmishas left
wladmishas joined
xnamedhas left
adiaholichas left
mjkhas joined
adiaholichas joined
Matthew (away)has left
Rixon 👁🗨has left
homebeachhas left
uhoreghas left
Half-Shothas left
Half-Shothas joined
Matthew (away)has joined
Rixon 👁🗨has joined
uhoreghas joined
homebeachhas joined
Steve Killehas left
Steve Killehas joined
Steve Killehas left
Steve Killehas joined
Steve Killehas left
Steve Killehas joined
sabryhas joined
fhtesthas left
fhtesthas joined
stphas joined
millesimushas left
chronosx88has joined
restive_monkhas left
karoshihas joined
tykaynhas joined
gooyahas joined
Andrzejhas joined
Vidakhas left
restive_monkhas joined
neshtaxmpphas left
Vidakhas joined
adiaholichas left
millesimushas joined
fhtesthas left
lskdjfhas joined
Andrzejhas left
Andrzejhas joined
sabryhas left
gooyahas left
adiaholichas joined
gooyahas joined
wladmishas left
wladmishas joined
fhtesthas joined
karoshihas left
adiaholichas left
adiaholichas joined
karoshihas joined
Vaulorhas left
rafasaurushas left
fhtesthas left
sabryhas joined
marchas left
marchas joined
Vaulorhas joined
millesimushas left
neshtaxmpphas joined
gooyahas left
gooyahas joined
millesimushas joined
karoshihas left
neshtaxmpphas left
neshtaxmpphas joined
karoshihas joined
ti_gj06has left
marc0shas left
marc0shas joined
gooyahas left
gooyahas joined
jgarthas left
Friendly Resident Cynichas left
karoshihas left
ti_gj06has joined
adiaholichas left
adiaholichas joined
BASSGODhas left
lovetoxhas left
adiaholichas left
lovetoxhas joined
karoshihas joined
adiaholichas joined
Wojtekhas joined
alex11has left
jcbrandhas left
jcbrandhas joined
adiaholichas left
adiaholichas joined
huhnhas joined
huhnhas left
ti_gj06has left
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.✎
sabryhas left
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?
Danielhas left
ti_gj06has joined
adiaholichas left
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) ✏
adiaholichas joined
Andrzej
can't we just use https://xmpp.org/extensions/xep-0372.html#usecase_previous for linking messages and building a tree?
karoshihas left
Danielhas joined
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
rafasaurushas joined
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... ✏
karoshihas joined
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)
millesimushas left
millesimushas joined
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?
Menelhas joined
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
millesimushas left
adiaholichas left
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 :)
wladmishas left
wladmishas joined
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.
BASSGODhas joined
Wojtekhas left
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? ✏
wladmishas left
wladmishas joined
BASSGODhas left
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.
Wojtekhas joined
adiaholichas joined
wladmishas left
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.
Wojtekhas left
wladmishas joined
wladmishas left
wladmishas joined
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)
Wojtekhas joined
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 ✏
wladmishas left
larma
There is no "root thread" in a channel
wladmishas joined
Zash
Just have to pick a style and be consistent. So it's impossible.
millesimushas joined
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.
Matthew (away)has left
homebeachhas left
Rixon 👁🗨has left
uhoreghas left
Half-Shothas left
Half-Shothas joined
Matthew (away)has joined
Rixon 👁🗨has joined
uhoreghas joined
homebeachhas joined
Zash
Yup
larma
There are a few things though that don't work with threads.
wladmishas left
wladmishas joined
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 :)
wladmishas left
wladmishas joined
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.
ti_gj06has left
adiaholichas left
ti_gj06has joined
wladmishas left
wladmishas joined
adiaholichas joined
millesimushas left
Menelhas left
millesimushas joined
xnamedhas joined
ti_gj06has left
Wojtekhas left
BASSGODhas joined
ti_gj06has joined
Wojtekhas joined
marchas left
marchas joined
Kevhas left
Steve Killehas left
marchas left
Steve Killehas joined
Kevhas joined
marchas joined
xnamedhas left
marchas left
marchas joined
adiaholichas left
florettahas left
karoshihas left
karoshihas joined
adiaholichas joined
ti_gj06has left
ti_gj06has joined
xnamedhas joined
chronosx88has left
chronosx88has joined
florettahas joined
xnamedhas left
marchas left
marchas joined
robertooohas left
robertooohas joined
marchas left
marchas joined
robertooohas left
robertooohas joined
Wojtekhas left
harry837374884has left
harry837374884has joined
adiaholichas left
marchas left
marchas joined
matkorhas left
argentumhas joined
matkorhas joined
karoshihas left
florettahas left
Paganinihas joined
millesimushas left
florettahas joined
sabryhas joined
alacerhas joined
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 :/
qwehas joined
Calvinhas left
Calvinhas joined
karoshihas joined
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
fhtesthas joined
sabryhas left
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
fhtesthas left
fhtesthas joined
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 ?
millesimushas joined
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
reimarhas joined
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)
marchas left
marchas joined
BASSGODhas left
BASSGODhas joined
moparisthebest
we also used to have HPKP but that went away too :(
Zash
Wasn't that a huge footgun?
fhtesthas left
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?
millesimushas left
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
adiaholichas joined
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.
alacerhas left
Matthew (away)has left
uhoreghas left
Rixon 👁🗨has left
homebeachhas left
Half-Shothas left
Half-Shothas joined
Matthew (away)has joined
Rixon 👁🗨has joined
uhoreghas joined
homebeachhas joined
Zash
Dealing with certbot has been cumulatively more painful by now, and I don't even use it
matkorhas left
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.
adiaholichas left
adiaholichas joined
sabryhas joined
marchas left
marchas joined
emushas left
harry837374884has left
harry837374884has joined
emushas joined
moparisthebest
for hpkp I just generated encrypted backup keys years ago and published them, haven't switched to using them yet though
emushas left
millesimushas joined
emushas joined
adiaholichas left
marchas left
marchas joined
BASSGODhas left
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...
sabryhas left
adiaholichas joined
moparisthebest
In my ideal world with dnssec everywhere we'd just use srv+dane instead, but that doesn't seem likely to happen soon? :'(
papatutuwawahas joined
Matthew (away)has left
uhoreghas left
Rixon 👁🗨has left
homebeachhas left
Half-Shothas left
Half-Shothas joined
Matthew (away)has joined
Rixon 👁🗨has joined
uhoreghas joined
homebeachhas joined
qwehas left
xnamedhas joined
APachhas joined
Menelhas joined
Dele Olajidehas joined
govanifyhas left
govanifyhas joined
govanifyhas left
govanifyhas joined
govanifyhas left
govanifyhas joined
adiaholichas left
adiaholichas joined
marchas left
marchas joined
harry837374884has left
matkorhas joined
me9has joined
Dele Olajidehas left
rubihas left
rubihas joined
adiaholichas left
fhtesthas joined
harry837374884has joined
jgarthas joined
Friendly Resident Cynichas joined
florettahas left
qwehas joined
djorzhas joined
me9has left
karoshihas left
florettahas joined
phrykhas joined
karoshihas joined
Steve Killehas left
Steve Killehas joined
djorzhas left
djorzhas joined
gooyahas left
Titihas left
gooyahas joined
djorzhas left
harry837374884has left
harry837374884has joined
julianhas left
fhtesthas left
djorzhas joined
florettahas left
wladmishas left
wladmishas joined
florettahas joined
gooyahas left
gooyahas joined
BASSGODhas joined
BASSGODhas left
BASSGODhas joined
wladmishas left
wladmishas joined
Steve Killehas left
Steve Killehas joined
qwehas left
guus.der.kinderenhas joined
gooyahas left
gooyahas joined
neshtaxmpphas left
neshtaxmpphas joined
fhtesthas joined
neshtaxmpphas left
neshtaxmpphas joined
fhtesthas left
fhtesthas joined
fhtesthas left
fhtesthas joined
Titihas joined
gooyahas left
gooyahas joined
rafasaurushas left
gooyahas left
gooyahas joined
restive_monkhas left
rafasaurushas joined
Dele Olajidehas joined
Dele Olajidehas left
adiaholichas joined
robertooohas left
adiaholichas left
robertooohas joined
robertooohas left
robertooohas joined
Yagizahas left
qwehas joined
argentumhas left
restive_monkhas joined
restive_monkhas left
jgarthas left
jgarthas joined
wladmishas left
wladmishas joined
xnamedhas left
ti_gj06has left
ti_gj06has joined
adiaholichas joined
papatutuwawahas left
wladmishas left
wladmishas joined
karoshihas left
pasdesushihas left
adiaholichas left
Mikaelahas left
wladmishas left
wladmishas joined
xnamedhas joined
neshtaxmpphas left
neshtaxmpphas joined
ti_gj06has left
pasdesushihas joined
gooyahas left
gooyahas joined
karoshihas joined
gooyahas left
gooyahas joined
Andrzejhas left
Andrzejhas joined
ponymontanahas joined
ponymontanahas left
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.