Modern XMPP project discussion - 2023-03-20

is there a list anywhere of xeps that should be avoided or nice to have? while cleaning up pidgin, docs.modernxmpp.org doesn't make things exactly easy. For example, we're re-architecting our status and "mood" api, but there's nothing about XEP 0107 User Moods that I can find on the website

It's not exactly used anymore around here so yeah there isn't much to say about it

I guess you're welcome to propose something

well this isn't the only case... which is why i'd like a list.. like xhtml formating gets a mention at least, but custom smiley/emojis someone built using BoB i'm sure isn't in use anywhere, so that ones easy. I just hate having to come and ask everyone who's knowledge on this stuff is way more up to date than I am ;)

i'm not in the position to propose anything, i'm trying to determine if i should nuke this code or comment it out until we finish this api rewrite

There's the compliance suites

https://xmpp.org/extensions/xep-0459.html

we have other protocols to support that do something similar, but if no other xmpp clients implement it, maybe it's not worth our time especially right now with a complete rewrite of our xmpp support looming

XHTML-IM unfortunately has been deprecated. I'm personally in favor of keeping it but I think modernxmpp is going with the less structed 393

Good to know that pidgin is looking into have decent XMPP support again :)

ok, this list is kind of it.. but i was hoping for a list of like every xep and whether or not it's status/recommendation

structured*

The goal isn't to catch 'em all really

i understand, but from an old implementation point of view trying to figure out what should and shouldn't stay is difficult at the moment

I agree things could be a lot better though

Do you have a list of what you support? Maybe we (here) could help cross things off it and/or add to it.

if we do i'm sure it's not reflective of reality :)

And possibly contribute that to modernxmpp if that can be of use to someone else.

Also have a look at https://xmpp.org/software/ the recent overhaul may help you to have a clue about what's implemented where

Also https://data.xmpp.net/explore/ if you like querying :P

But the compliance suites are a start, once you have everything in there implemented and working and following modernxmpp guidelines and tested against other implementations, you can start looking at other things you want to add to it.

i mean i pretty much just look at dino, gajim, conversations, and xabber to test stuff and see what other clients are doing already

Link Mauve: i can't get to that point until i get the cruft out of here..

Xabber is nice in its own way. For some (most?) of the things it's doing its own thing

like i said, right now it's a matter of delete or comment stuff out because we have a rewrite looming, but we haven't started it yet because theres other things that need to happen first

Nobody is going to punish you for supporting User Mood when no other moden client does, but it's not something people are going to miss if you want to remove it

Well that depends on your user base

i believe this is the closest thing we have a list of XEPs that we support https://keep.imfreedom.org/pidgin/pidgin/file/tip/libpurple/protocols/jabber/namespaces.h

If you stick around here I'm personally happy to point you to things when needed

And/or I can join another channel ✏

user mood is just one of i'm sure many examples.. the specifics don't matter.. but right now i'm trying to rip out or current "mood" api as it sucks and it's being integrated into our new presence api. so i either need to comment out the xep 0107 support or delete it so we can compile and continue moving forward

timeline on implementing any of this is anyone's guess.. i literally just built a new sasl library for pidgin3 because the existing options all had stupid problems we didn't and shouldn't have to deal with in 2023..

that's the level of rewrite and care we're putting into this effort

From this list I think you can: - Remove 0012 (Last activity), - Remove 0096 (SI File Transfer) to replace with Jingle-ft / OMEMO / JET (0391) - You do BOSH, maybe you want to also? instead? Add support for websockets - BoB 0231 for stickers is only used by Movim. I think people are going towards 0449 nowadays

And yeah, compliance suites

ok, but looking at 0107, i think we're better off just allowing any emoji as a mood and prefixing the status message with it because the other protocols we have to support support the full emoji set. i suppose we could have xmpp send the events in 0107 if the user picks an emoji that matches those moods but whatever

Also stuff is happening in the sasl/bind area now that you're talking about it. https://blog.prosody.im/fast-auth/

new mech is fine, we built that library to easily add custom mechs if necessary

just skimming but it looks like scram?

Re 0012, 0319 seems to be a replacement if you want to keep a similar feature around. I don't know who does it.

Yeah it's SCRAM. I'm not the best person to talk about it though

SCRAM is the best mechanism for password auth. The FAST stuff uses tokens and is similar to, but not the same as, SCRAM.

It lets you avoid the multiple round-trips that SCRAM requires on subsequent authentications

MattJ: understood, i was just skimming, saw tokens that don't get passed and was like, oh this sounds like a scram challenge ;)

or cool, so it just does first run and then tokens, similar to oauth? i assume there's a ttl as well.. although feel free to not answer i can read the xep later ;)

It's a single round-trip, unlike SCRAM, so actually no challenges. That means it's susceptible to some things that SCRAM isn't, but also tokens aren't passwords and it's always over TLS so it's basically okay.

and yes to all your questions

cool, does it used bound channels or whatever? i need to work that into hasl yet... yes we named our sasl library HASL because both cyrus and gsasl are real hassles..

cool

Yes, it uses channel binding

ok so that's on my list, yay :)

in the rare change anyone is interested, here's hasl https://keep.imfreedom.org/hasl/hasl

it needs more docs and examples and stuff, but right now it just supports PLAIN and EXTERNAL, scram is up next, but if i can work FAST into our prosody instance with our custom auth provider i'll probably lean towards that sooner rather than later

That would be very nice :)

MattJ: yeah i'll probably be bugging you about that at some point :-D

Please do!

well more of how do i make my custom auth provider prosody plugin work with FAST, but yeah

xmpp:prosody@conference.prosody.im?join < :)

i'm already there ;)

Regarding your earlier question about XEPs, in addition to what people already said, this might be useful as an extra indicator: https://data.xmpp.net/explore/xmpp/implementation_counts

that's amazing! thank you for that!

Don't let a "0" stop you from implementing it though :P

If that's interesting for you/your userbase

of course, but it'll let me focus on feature parity first

our user base is a lot more than xmpp, but if we're already implementing something for one protocol and we just have to write the xmpp glue code, then so be it right

which is where this user-mood stuff sits. and maybe that ends up being a new xep at some point, but right now, it doesn't seem worth the effort but it looks like 1/3rd of clients support it..

Sure. In fact just as interesting would be "Hey, we're implementing this feature for N other protocols, how do we map that to XMPP?"

same thing with user tune too

Profanity supports user mood, BTW. 😁

Seems like 13 implementations do.

MattJ: exactly. we're basically taking a signal from discord (feel free to groan), but updating the status message for the song being played, or the users mood via an emoji is a very simple and easy way to implement that stuff for slack, discord, and i forget who else supports it.

WHERE implementation.is_modern == 1

What's is_modern

A flag I invented to annoy you :P

I got that part :P

grim, oh, but don't drag XMPP back into the dark ages just because other platforms haven't understood their terrible design mistakes yet :P

User Tune is obviously superior than spamming full presence changes, since it can be selectively filtered

MattJ: no promises :P

also, channel binding is SHOULD, not MUST? > Finally, if channel binding is used, both sides receive proof that no MITM or relay attack being performed.

We relaxed it to SHOULD because in some environments (such as web clients running in browsers) there is no way to implement channel binding

ah ok, so we'll have to make it an option that defaults to on (in libpurple)

libpurple compiled to JS? :)

that's our new thing too.. secure defaults.. not sure why it took us that long to do it, but basically connecting to irc with secure sasl just requires clicking a box to say "require password" :-D

MattJ: i mean there is a docker protocol plugin that someone wrote libpurple golang bindings for... and people have pulled it into nodejs as well..

so building for wasm isn't out of the question either

docker protocol plugin.. for libpurple?!

pep.: yep, you're containers show up as contact on your buddy list, and then your im's are stdout/stdin

it's really quite something lol

:x

Okay, new XMPP gateway required... :P

adventurous_linus became online

pep.: precisely

MattJ: https://data.xmpp.net/explore/xmpp/implementations implementation_status is missing there, which can be "removed" as well. am I seeing this correctly? or did you remove those beforehand?

No, I didn't do anything

It's just the raw data

But I don't know if I imported that column, I'll check

No, I'll fix that, thanks

Ah, I was pulling '.status' from the JSON but it's '.implementation_status', thanks

There is a status column now

I assume no value just means... "implemented"? :)

yes, some devs didn't fill that column at all

I notice a number of them get the version fields wrong too

Indicating the version of the implementation rather than the XEP

I forgot to tell, but you can check for implementations for specific XEPs on xmpp.org now as well: https://xmpp.org/extensions/ (right-most column)

MattJ: if you tell me which ones, I can ping the author

I noticed it with Metronome, but I think it's not the only one

It's clear on https://data.xmpp.net/explore/xmpp/outdated_implementations

A number of rows claim to have implemented XEP versions that don't exist

perfect, thanks! really useful, this tool!

okay, i know pidgin isn't listed on a lot of xmpp client lists, but this is one i really expected to see pidgin or purple on... https://data.xmpp.net/explore/xmpp/outdated_implementations

grim, do you have a DOAP file at xmpp.org?

Link Mauve: i'm going to guess and say no

grim, add it there then: https://github.com/xsf/xmpp.org/blob/master/data/software.json#L1295

On the next website rebuild it’ll be part of that data.

cool, now i just need to learn doap :-D

XEP-0453 should explain most of it.

XEP-0453 ?

yeah cool

this probably isn't the right muc for this, but is there a tool i can use to verify my data before hand?

and i see the right muc for it, joining now

Probably building xmpp.org manually.

oh derp, that'd make sense :-D

I once wrote some tooling around it, but never managed to do the last parts of making use of it…

i'm not volunteering but and xsd or dtd could be enough..

RDF usually uses different tooling than XML schemas.

hm, okay

Because effectively you can add any additional RDF thing in it.

https://www.xmlvalidation.com/ works for starters

also, no need to build manually. GitHub CI will do that for you

i'd just run xmllint on the command line honestly and I have no issue building locally

> wurstsalat: > 2023-03-20 12:56 (GMT+01:00) > https://www.xmlvalidation.com/ works for starters have we listed this somewhere?

It's a pretty generic xml validation tool.. we don't need to catch all of these either really ✏

ok

but still one asked about it right?

They asked about a way to validate DOAP specifically

ok

MattJ, if one were to have a data export, can you import it with https://migrate.modernxmpp.org/ without exporting from somewhere?