XSF Discussion - 2022-02-18

emus, sorry I didn't quite finish, I'll get the rest tommorow

moparisthebest: thanks is alright

This is probably a silly question, but I didn't have enough coffee yet. How does one unregister with a MUC? The inverse of https://xmpp.org/extensions/xep-0045.html#register ?

Have always assumed, perhaps incorrectly, that it's intentionally back-channeled. In the same way that many orgs do their Right to Be Forgotten, I'd imagined it to be an "email an admin" affair.

https://xmpp.org/extensions/xep-0077.html#usecases-cancel

Ah, thank you.

So, no XML excuses anymore 🙂 https://github.com/legastero/stanza

emus, doesn’t sound very maintained.

yep, I just saw it

But this (and many similar ones) has been available for literally decades.

People ranting on XML just want a reason to not use XMPP imo.

ah, didn't knew

A library like slixmpp or aioxmpp will not expose any XML to you, it will expose native objects.

You have to dig pretty far if you want to manipulate raw XML objects.

see I always found that super annoying

I *want* raw XML and jumping through 80 hoops making objects for each variant and registering serializers and deserializers etc was always a PITA

Have fun playing with libstrophe I guess. ^^'

I’m not into kink shaming.

the key is layers so you can reach down as deep as you'd like

I cannot review this, is there anyone volunteering? https://github.com/xsf/xmpp.org/pull/1001

I've got "connecting to xmpp, being handed seperate stanzas as &[u8] working

next would be an XML layer, and *then* an object layer, maybe

maybe we should add this to XMPP Myths --> "XMPP means XML = bad"

moparisthebest, we have that in tokio-xmpp.

And you can use xmpp-parsers if you want something more usable than XML stuff.

tokio-xmpp depends on an XML lib though right?

But besides XMPP hackers, this is not usable by the layman.

Yes.

that's the layer above &[u8]

For XMPP you kind of need to. :p

Otherwise you’d have like, a socket library?

you don't, you can easily split up stanzas without an XML parser

And parse the stream headers, do the login dance, etc.

Yeah sure, I mean my first client was literally implemented using printf() and scanf(), but…

some simple substring on the byte array

Oh my.

fun fact, ejabberd works like this

https://gitlab.com/xmpp-rs/xmpp-rs can some of the official people PR? https://github.com/xsf/xmpp.org/blob/master/data/libraries.json ✏

it's not using an xml library on stream features etc, because if you send them formatted differently, it won't work

emus, I still don’t consider the xmpp-rs part usable enough, and the other parts are more like building blocks.

but it is being developed right?

Working building blocks, someone recently made a Jitsi Meet-compatible tool, but as I said besides XMPP hackers it’s not really usable by a random person wanting to use a library.

Yes it is.

I think it is still okay to show its there, because I don't want people now thinking "Ahhh I am going to make a rust library!!!!"

my motto is "if it's good enough for ejabberd, it's good enough for me" :P (it rhymes if you say it right)

emus, hmm, that makes sense.

I would appreciate a update. Its more usable than this stanza thing I think, right? ✏

emus, just one entry, or one entry per component?

I personally don't care. if it all is rust related, I think its fine to just reference the main repo. people will find their way

(they likely wont find if we dont link at all 😉 - IMHO)

Indeed. :)

Link Mauve: ``` // ejabberd never sends <starttls/> with the first, only the second? //let buf = br###"<features xmlns="http://etherx.jabber.org/streams"><starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"><required/></starttls></features>"###; let buf = br###"<stream:features><starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"><required/></starttls></stream:features>"###; ```

that was, let's say, annoying to debug :)

Call for everyone to rather create an entry for your project or also update existing entries (timestamp) - Let's not have people reinventing the wheel (can I say that in English? :D) - if there are doubts we can still discuss or in one year leave it to the archive again ✏

this is XMPP, where (virtually) every client re-invents the wheel with their own library

inb4 libprosody

https://github.com/xsf/xmpp.org/pull/1078

21:14:03 Link Mauve> A library like slixmpp or aioxmpp will not expose any XML to you, it will expose native objects. → I wish though

👍

> moparisthebest escribió: > this is XMPP, where (virtually) every client re-invents the wheel with their own library ☺

There is no Rust in https://github.com/xsf/xmpp.org/blob/master/data/platforms.json This will most likely fail

Add there too?

Sorry, just on the phone

wurstsalat, platforms for the libraries page do not reference those, AFAIK

(see the other entries, it’s the programming language instead)

wurstsalat, Link Mauve: could you guys check on that?

Sam, they relate because you don’t trust a single client’s featureset anymore

so feature detection is mostly dropped in a multidevice world

.

It's relevant for Jingle things, as Jingle doesn't use message 😉

(but yes, the correlation is loose)

larma, true

the return of calls, yeah

Sam, let’s say a client advertises support for feature A and feature B, a victim got their cache poisoned with feature A<B because their client didn’t escape things properly, then they’ll think the first client advertises neither.

Sam, you can't rely on caps/features for the call icon because the call-capable client might be offline and get a push notification as you send a call invite

larma: sure, but you still rely on caps/features to know that something supported it in the first place.

You could, but then you risk of not showing the call icon for some users that would actually support it

You mean if they've never had a client come online that supports it? That seems reasonable to assume they don't have one in that case.

But if I wanna use fancy new features in say, this MUC right here, I can't do negotiation with those who will read it from the archives in 10 years

I still don't understand what MUCs or people reading history in 10 years have to do with feature negotiation

I'm not trying to be obtuse, but maybe I am? I don't see how this relates to the previous conversation, sorry.

It depends on which feature you want to negotiate

Sam, many features which could (and should) be negociated in 1:1 usecases don’t really make sense any longer, now that people routinely use multiple clients and you don’t address a single resource, or in MUCs where people come and go.

I can send XHTML-IM to this room right now, even if some of you might not support it yet.

My client didn’t even try to negociate the feature, because in the worst case you will just miss part of the message.

Oh sure, all of that is true and obvious. I don't see how that makes feature negotiation as a thing less useful though. Yes, lots of features in different ways don't need it and you can just send them and have a good fallback. Others you can't. I was never arguing that every single thing should be feature negotiation all of the time.

Sam, Zash’s point was only that fewer and fewer features are actually negociated that way.

Due to multi-client, due to the assumption that people are always online (even if they don’t have a resource), etc.

Due to MUC+MAM. ✏

Sure, that's probably true

Like, Swift IIRC has a banner warning that not everyone in the chat supports LMC

That's a thing I wish clients would do negotiation on. Every time someone edits a huge message and I get it all over again and have to try and figure out what's different I want to smash something

But yah, lots of things have saner fallbacks

That works fine as long as the audience is the current set of participants, but it's not, it's anyone who might join in the future (before archives expire)

I feel like LMC’s fallback is actually pretty sane. :)

Annoying, but survivable, sure

It could be much worse if you were to just miss an important correction altogether.

The obvious solution being, to actually implement it.

That is not a solution for most users.

> point was only that fewer and fewer features are actually negociated that way. and by extension that the impact of 115 exploits is reduced

That's fair

Messing with call support detection, or PEP +notify might be bad enough tho.