XSF Discussion - 2021-02-21

Does anyone want to add tls-id from rfc8842 to xep-320 (dtls-srtp)?

rion: can it be done in a backwards-compatible manner?

I believe so

basically it's just a hint when for sure we have to restart dtls

rion: "patches welcome" as they say.

=)

hm, there's an example in that rfc with multiple fingerprints. is that a thing? is it representable per the xep? do we care?

last time I contributed to a xep it took half an year to review =)

320 is what, 8 years old and still not Final :)

rion: you could post to the list about it

> 320 is what, 8 years old and still not Final :) We only recently moved it draft

I also noticed the multiple fingerprint thing. Probably good to have for interoperability with non-xmpp

I guess it's about multiple hash algos. since generating multiple certificates makes less sense (slow)

so hash agility?

we do have xep-0300, which provides discovery and syntax for multiple hash algos...

hm agree. so hash agility is up to an non-xmpp bridge (to discover and choose one) ✏

rion> last time I contributed to a xep it took half an year to review =) that's a pitty and we should definelty see if this can be improved. was your contribution merged eventually?

flow: yes. it's merged

is there any work beeing done on getting 0292 to draft?

to my knowledge now multiple clients implement it

there are many status codes when a user leaves, but not a single one when a user joins a muc

i has to be one of the top 5 worst decisions in xmpp that identity is defined by the resource in mucs

lovetox: mix fixes that ;)

It probably seemed like a good idea at the time

yeah i hope i can implement that some time

yeah not judging anyone, hindsight etc

What should it have been defined by?

some unique id the muc service generates

see occupant-id

And what name should be displayed?

MattJ, i find what occupant-id does is fine

its just sad that it was not there from the beginning