moparisthebestemus, sorry I didn't quite finish, I'll get the rest tommorow
emusmoparisthebest: thanks is alright
GuusThis 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 ?
FishbowlerHave 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.
emusSo, no XML excuses anymore 🙂 https://github.com/legastero/stanza
Link Mauveemus, doesn’t sound very maintained.
emusyep, I just saw it
Link MauveBut this (and many similar ones) has been available for literally decades.
Link MauvePeople ranting on XML just want a reason to not use XMPP imo.
emusah, didn't knew
Link MauveA library like slixmpp or aioxmpp will not expose any XML to you, it will expose native objects.
Link MauveYou have to dig pretty far if you want to manipulate raw XML objects.
moparisthebestsee I always found that super annoying
moparisthebestI *want* raw XML and jumping through 80 hoops making objects for each variant and registering serializers and deserializers etc was always a PITA
Matthew (away)has left
Rixon 👁🗨has left
Matthew (away)has joined
Rixon 👁🗨has joined
Link MauveHave fun playing with libstrophe I guess. ^^'
Link MauveI’m not into kink shaming.
moparisthebestthe key is layers so you can reach down as deep as you'd like
emusI cannot review this, is there anyone volunteering?
moparisthebestI've got "connecting to xmpp, being handed seperate stanzas as &[u8] working
moparisthebestnext would be an XML layer, and *then* an object layer, maybe
emusmaybe we should add this to XMPP Myths --> "XMPP means XML = bad"
Link Mauvemoparisthebest, we have that in tokio-xmpp.
Link MauveAnd you can use xmpp-parsers if you want something more usable than XML stuff.
moparisthebesttokio-xmpp depends on an XML lib though right?
Link MauveBut besides XMPP hackers, this is not usable by the layman.
moparisthebestthat's the layer above &[u8]
Link MauveFor XMPP you kind of need to. :p
Link MauveOtherwise you’d have like, a socket library?
moparisthebestyou don't, you can easily split up stanzas without an XML parser
Link MauveAnd parse the stream headers, do the login dance, etc.
Link MauveYeah sure, I mean my first client was literally implemented using printf() and scanf(), but…
moparisthebestsome simple substring on the byte array
Link MauveOh my.
moparisthebestfun fact, ejabberd works like this
emushttps://gitlab.com/xmpp-rs/xmpp-rs can some of the official peopl PR? https://github.com/xsf/xmpp.org/blob/master/data/libraries.json✎
emushttps://gitlab.com/xmpp-rs/xmpp-rs can some of the official people PR? https://github.com/xsf/xmpp.org/blob/master/data/libraries.json ✏
moparisthebestit's not using an xml library on stream features etc, because if you send them formatted differently, it won't work
Link Mauveemus, I still don’t consider the xmpp-rs part usable enough, and the other parts are more like building blocks.
emusbut it is being developed right?
Link MauveWorking 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.
Link MauveYes it is.
emusI 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!!!!"
moparisthebestmy motto is "if it's good enough for ejabberd, it's good enough for me" :P (it rhymes if you say it right)
Link Mauveemus, hmm, that makes sense.
emusI would apprecitate a upgrade. Its more usable than this stanza thing I think, right?✎
emusI would appreciate a update. Its more usable than this stanza thing I think, right? ✏
Link Mauveemus, just one entry, or one entry per component?
emusI 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
emus(they likely wont find if we dont link at all 😉 - IMHO)
Link MauveIndeed. :)
// 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>"###;
moparisthebestthat was, let's say, annoying to debug :)
emusCall for everyone to rather create an entry for your project or also update extisting 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✎
emusCall 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 ✏
moparisthebestthis is XMPP, where (virtually) every client re-invents the wheel with their own library
mathieui21: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
emus> moparisthebest escribió:
> this is XMPP, where (virtually) every client re-invents the wheel with their own library
wurstsalatThere is no Rust in https://github.com/xsf/xmpp.org/blob/master/data/platforms.json
This will most likely fail
ZashAdd there too?
wurstsalatSorry, just on the phone
mathieuiwurstsalat, platforms for the libraries page do not reference those, AFAIK
mathieui(see the other entries, it’s the programming language instead)
emuswurstsalat, Link Mauve: could you guys check on that?
mathieuiSam, they relate because you don’t trust a single client’s featureset anymore
mathieuiso feature detection is mostly dropped in a multidevice world
larmaIt's relevant for Jingle things, as Jingle doesn't use message 😉
mathieui(but yes, the correlation is loose)
Zashthe return of calls, yeah
Link MauveSam, 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.
larmaSam, 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
Samlarma: sure, but you still rely on caps/features to know that something supported it in the first place.
larmaYou could, but then you risk of not showing the call icon for some users that would actually support it
SamYou 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.
ZashBut 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
SamI still don't understand what MUCs or people reading history in 10 years have to do with feature negotiation
SamI'm not trying to be obtuse, but maybe I am? I don't see how this relates to the previous conversation, sorry.
larmaIt depends on which feature you want to negotiate
Link MauveSam, 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.
Link MauveI can send XHTML-IM to this room right now, even if some of you might not support it yet.
Link MauveMy client didn’t even try to negociate the feature, because in the worst case you will just miss part of the message.
SamOh 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.
Link MauveSam, Zash’s point was only that fewer and fewer features are actually negociated that way.
Link MauveDue to multi-client, due to the assumption that people are always online (even if they don’t have a resource), etc.