XSF Discussion - 2023-01-16

Entity caps 2 hashing for Conversations 3 ✅

🎉

is that the same XEP or a new one?

390

Council issued a last call

Ta

Oh that's a nice XEP :)

Might be interested to implement is as well

If I get technical assitance I am always happy to make tweets and toots out of it

would 0390/caps2 be a good place to create something like: <query xmlns="disco#items"><item jid="foo"><c xmlns="urn:xmpp:caps"><hash xmlns="urn:xmpp:hashes:2" algo="sha-256">…</c></item></query>

i really want _something_ like this; doesn’t necessarily have to be that syntax

Me too! Recursive caps-disco something something

it doesn’t necessarily have to be recursive

just the caps hash of each item in the items response

Also something in stream:features on connect for local components etc

(that the server knows)

the next step would be to put the items in the bind2 response…

Negotiated with `<iq><{disco#info}query><{ecaps}plz-include-in-items/></query></iq>` or something ?

does it have to be negotiated if it's just an extension?

but yes that's an option to save traffic I guess

Dunno how careful we need to be with unexpected items in these very core pieces

TLS land (including QUIC) does a whole bunch of purposefully putting random unexpected items in core places so that new things will work in the future, maybe we should do the same?

https://www.rfc-editor.org/rfc/rfc9287.html for example

https://www.rfc-editor.org/rfc/rfc8701

8701 is probably what we should emulate with bind2, register a few useless extensions, have servers randomly insert them

are we facing the same issues that causes TLS to do so?

If Zash is afraid of putting unexpected things in there then maybe...

We used to be a lot less scared of breaking changes :)

I'm inclined to just go for it in this case - it *is* how XMPP is meant to work

what's the X for again?

eXcept too many implementations failed on uneXpected values...

>Daniel : what's the X for again? X factor. eXciting, eXtendable, eXtensible, eXtraordinary, ineXhaustible and uneXceptional

Daniel, point about conserving size might be relevant, but otoh caps helps with caching so probably won't matter

moparisthebest> eXcept too many implementations failed on uneXpected values... not in my experience. I believe, at least in the FOSS space, the majority of XMPP implementations correctly handle unknown extensions at the well defined extensions points

and even if not, say if you use "exotic" extensions points like namespaced attributes, then I still would be willing to accept the fallout of implementations not handling namespace attributes like they should and tell those to fix their implementation ✏

TLS was extensible in the same way and failed hard this way, and we have very popular servers that can't parse stream features if you format them in a totally valid but unexpected way, so I'd disagree...

Write a server and send: <features xmlns="http://etherx.jabber.org/streams"><starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"><required/></starttls></features> Then be surprised you can only federate with ~half the network, because the other half fails if you don't send <stream:features ...

Hash the remote domain, and feed that into a probability function that gradually increases the percentage of domains which we send prefix-free <features/> to, until it reaches 100% on a certain date

Phased rollout strategies, on my federated network?

Something we should do more of :)

Wait, aren't we already?

By upgrading software?

Yeah. Not everyone does it at the same rate etc.

With an algorithm we get to control the rate though, I guess

Yeah.

If we want to be able to send prefix-free features, we can't just release that today or it will break for 50% of remote domains

if we want to make that change within a year, we can't just release it in a year either

For that particular bug I suppose we should just fix the offending server and wait, but in theory something like GREASE would prevent the same thing from happening with bind2 etc ✏

Prosody trunk, enabled by default, see who notices anything :)

Roughly 75% of the servers running the server software that I'm working on have not updated in the last 2 years. 😨 About 3% has not updated in more than 10 years. 😱

never change a running system 😀️

moparisthebest, your example falls more into the namespaced attributes category than into what I consider "well defined extension points"

and the latter is what I understand you want to feed with "random unexpected items", but maybe I misunderstood that

flow: I think it's all basically the same, that programmers handle things they see and not things they don't

Maybe xmpp-proxy could have a mode where it inserts random caps, randomly changes single quotes to double quotes, randomly changes prefixes etc etc

moparisthebest: that sounds honestly really good for testing😀

chaosproxy

GREASE is about testing the points we know should be flexible, but in production where, let's face it, is the only place many things are actually tested lol

pep.: hmm very nice I might steal that name lol

Have we had any discussion about the forthcoming CRA legislation? I just now glanced at https://blog.nlnetlabs.nl/open-source-software-vs-the-cyber-resilience-act/ and https://www.internetsociety.org/blog/2022/10/the-eus-proposed-cyber-resilience-act-will-damage-the-open-source-ecosystem/ - their warnings are concerning.

empp

In general, an interoperability testsuite that checks for such mistakes, implementations are known, to make would be a good idea ✏

Hi folks! I plan to let go of our renewal policy for the software listing on xmpp.org. Until now, every maintainer had to update "last_renewed" once per year. We now have DOAP files for many actively developed clients, servers, libraries, and tools. Software providing a DOAP file would be listed in a rich list (like it is now), and software without would be listed in a simple table below, behind a "Show List" button. Any objections?

👍

wurstsalat: None here

@wurstsalat that sounds reasonable

👍

wurstsalat: can you call via member, jdev and standards to update and provide doaps one last time? should I?

that's probably a good idea

done

thanks a lot!