jdev - 2025-04-11

> Is there some XEP or a draft already regarding silent messages? (I wonder if it's even worth a separate XEP or just an extension to XEP-0334). Why not something like a priority indicator? High priority notifies always when received, normal does the current jazz, low priority never does. Seems to fit your use-case and to generalize into something easier to discover and to use.

(having "high priority" messages probably enables cleaner semantics and UI compared to the @all @channel ways some clients resort to)

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

cal0pteryx: iirc, that sounded like MSN's "wizz" last I read it

It's exactly what you need for sending high priority

MS teams has this also with important messages

It does not help you if you want to send low prio messages

Does anybody know whether an issue was sent to Gecko or WebKit about DOAP files and XSLT?

https://xmpp.pimux.de/file_share/067f8f67-344f-7008-a8b7-b32a0a0c0924/doap_xslt.tar.bz2

Some browsers do not render it, and some would, only if the filename ends with "xml". ✏

Hi all, do we have any spec (or set of specs) for delegating the server registration process to a custom component?

I'm thinking of taking on Prav's goal of implementing standards-based phone number login: https://codema.in/d/SN2zQyPT/-priority-feature-3-sms-based-signup-login-with-any-xmpp-app-not-just-prav-app-/28

Starting with a less ambitious "sign up with email" module (maybe for Prosody to start with) and adding corresponding support to a client (tentatively Gajim) ✏

XEP-0389 allows for customisation of the registration process but it has to be from the server end, making it implementation-specific

Wouldn't registration always be server specific?

So my idea is, if we define a mechanism for the server to forward `jabber:iq:register` stanzas (or their equivalent in the new XEP) to a component, then someone can write a generic component that'd work across servers

i know matrix is trying to transition to server webpage and app specific auth, which might be interesting honestly

Basically https://github.com/mathiasertl/django-xmpp-account but using XMPP (and therefore accessible in-client) instead of doing it via HTTP or other outside mechanisms

> i know matrix is trying to transition to server webpage and app specific auth, which might be interesting honestly What's app specific auth? ↺

Okay one sec let me summarise what I came up with yesterday

> What's app specific auth? you know how google (and most big tech) have that system where you "log in with google" and it take you to a google page to log in and then you give it permission to do x y z and its registered as a specific app ↺

Ah yes

and then under my accounts you can controll "authorized apps"

similar system to that

The megacorp version of OpenID

yea, though ig in this case more just generate an auth key per client

since its all to one server and not for remote service auth

My idea from yesterday was a bit different; basically we need a component (already exists) that talks the register spec (already exists). The missing pieces are (a) make the server relay all jabber:iq:register queries to that component instead of handling them itself, and (b) some way for the component to say "okay now you can register the user" (maybe borrow user management commands from XEP-0133?)

Any thoughts on that?

App specific auth is what fast xep is for

My focus is more on custom registration (but let me read up on app specific auth, now I know that's a thing) ✏

Okay, just read xep-0484 and I think that's something that'd happen at a later stage?

You can forward stanzas to a component fine there are things that work like that already. But for registration you need to control the auth store etc. Unless you also forward login stanzas etc. At which point you're reimplemented your server quite a bit

> Okay, just read xep-0484 and I think that's something that'd happen at a later stage? If I understand it right, we'd first handle registration with xep-0389 and *then* provide a FAST token ↺

> You can forward stanzas to a component fine there are things that work like that already. But for registration you need to control the auth store etc. Unless you also forward login stanzas etc. At which point you're reimplemented your server quite a bit People are currently implementing registration by doing stuff in a webpage and then manually running ejabberdctl or prosodyctl commands (or some equivalent like using an API). Can't that be replicated through the component connection too? We can allow the component to send a <command node="...#add-user"/> or something ↺

My aim here is to replace the webform (that many setups use today) with an in-client form

Of course there's the related question of how useful the ability to make generic in-band registration handlers would be if we're moving towards other forms of authentication?

i.e. my plan is still assuming we're using passwords eventually; just adding a few challenges on top. That said that is what XMPP registration pages tend to do (add CAPTCHAs or some other form of verification but eventually register with good ol' username and password)

> App specific auth is what fast xep is for Okay so if I understood this right, the client authenticates with what is usually a password (but can also be an SMS code or something) and then gets a token for all future connections? ↺

> My aim here is to replace the webform (that many setups use today) with an in-client form Should be no problem to do this for single step. I don't think it requires an external component ↺

>> App specific auth is what fast xep is for > Okay so if I understood this right, the client authenticates with what is usually a password (but can also be an SMS code or something) and then gets a token for all future connections? Yes ↺

Was someone looking for XEP-0493: OAuth Client Login <https://xmpp.org/extensions/xep-0493.html> ?

You mean by just directly writing a server specific module?

> Should be no problem to do this for single step. I don't think it requires an external component re that ^ ↺

Right.

Yeah now I'm coming round to your "you're basically reimplementing the server" point

Especially if we're doing FAST as well

the module for OAuth already exists for Prosŏdy

not quite sure what your question is

Not OAuth (that was only tangentially related). What I want to do is customise in-band registration, eg. by making people verify their phone or email (using one-time code) in the process

so you looking to link an email address or a phone number to an XMPP account ?

Yeah but along the way I was wondering whether it'd make sense to have a standard way of delegating such registration to a component (the same way server operators "delegate" it to an external HTTP service that then runs *ctl commands). However it seems like that's probably not worth the effort

i think we haven't got anything of that yet in the community. You're welcome to implement it.

or write a XEP on new way for authentication ✏

Now I think the use-case I have in mind (link email address or phone number to XMPP account) is simple enough that it can just be implemented separately on each server

i know my government and banks here would love it coz they all do this OTP (one-time-password) via SMS to access account

or do whatever to with the account

regular users feel super safe and stuff coz newspaper talks abt it etc

no one cares that SMS is not encrypted and you can setup gears to capture and send SMS

idk if attackers cracks my head open, they still can't get my password

Hmm yeah I'll shelve the delegated registration idea though

If someone else had a more complex registration use-case where it'd help to implement once and deploy across different server software I'd be happy to revisit it

> no one cares that SMS is not encrypted and you can setup gears to capture and send SMS Like I've said before, I dream of the day when they send me these passwords via XMPP instead 💭️ ↺

well: > You're welcome to implement it. or write a XEP

Hah! Even just a `<message>` with a number in the body would have me delighted 😅️

remember this

oops

wron ghcta

We have the xep but need to code it up for whatever use cases

Which XEP?

IBR xep?

Oh you were talking about the phone-number or email linking. Yes ✏

Trung, for broader context my project is part of reimplementing the "sign in with SMS" flow of Quicksy/Prav but in a standards-compliant way. I'm trying to break it down into smaller chunks though, and ideally make code that'd be useful for other setups too (like someone who wants to make their users link email addresses, etc.)

> Not OAuth (that was only tangentially related). What I want to do is customise in-band registration, eg. by making people verify their phone or email (using one-time code) in the process XEP-0077 supports extensibility with XEP-0004…

but '77 doesn't really support flows like "enter an email, then enter the code we sent to that email", but https://xmpp.org/extensions/xep-0389.html was meant to allow that kind of thing

Though 0389 is basically a reinvention of ad hoc

> ‎11/04/25 | 17:34:20 ‎badrihippo‎: > no one cares that SMS is not encrypted and you can setup gears to capture and send SMS Like I've said before, I dream of the day when they send me these passwords via XMPP instead 💭️ Would it work if you're out of traffic though? Incoming SMS are free, for me even in roaming.

When the aim is to log in on mobile, you'll already be using data to request the code, and then presumably chatting afterwards

non american focused services already offer verification code over whatsapp so doesnt seem that perturbed to me