jdev - 2025-06-10

Good day. Would it be worth to revamp "rtv" to support XMPP? https://github.com/michael-lazar/rtv

> 🦔 ejabberd The author must be slav

> 2025-06-10T04:59:49Z - doge: > > 🦔 ejabberd > The author must be slav > 📱 PDA And that too. Who else boycotts the merger of notions of "smartphone" and "PDA phone", and argues that modern "smartphones" are rather descendants of PDAs, while smartphones are dead? I'm still not sure where did the word «коммуникатор» come from. Possibly somehow related to French «PDA Communicant». ↺

(and the word itself is also a result of a merge of notions, because it also means UMPCs akin to Nokia 9000 Communicator, which pioneered the class, along with the clamshell Star Trek Communicator. PDA phones somehow got merged into this class)

> I'm still not sure where did the word «коммуникатор» come from. https://en.m.wikipedia.org/wiki/Communicator_(Star_Trek)

> 2025-06-10T07:53:11Z - doge: > > I'm still not sure where did the word «коммуникатор» come from. > https://en.m.wikipedia.org/wiki/Communicator_(Star_Trek) You missed the point, I wonder how did it start to denote PDA phones, even though this didn't happen beyond Slavic languages. ↺

Is there a way to remotely invalidate an existing XMPP session?

Like I have client A logged in. Can I, through client B or some admin page, tell the server to close the existing connection with client A?

depends on the server. ejabberd has this: https://docs.ejabberd.im/developer/ejabberd-api/admin-api/#kick_session

I see. That looks like an admin feature though. So there's no XEP that standardises a way for users themselves to do it?

The server could implement it via XEP-0050

yup

> Like I have client A logged in. Can I, through client B or some admin page, tell the server to close the existing connection with client A? Even if you had this client A will just automatically log back in no? ↺

logging in to client b with the same account with the same resource kicks client a off, as well

FAST has per client credentials so that could be a way to actually permanently log out another client

>> Like I have client A logged in. Can I, through client B or some admin page, tell the server to close the existing connection with client A? > Even if you had this client A will just automatically log back in no? usually. it depends what the reason you wanted this is ↺

> FAST has per client credentials so that could be a way to actually permanently log out another client Yeah I was thinking FAST + "kick out the current session" to de-authorise a client ↺

so that missing "kick out the current session" is what I'm looking for ✏

> logging in to client b with the same account with the same resource kicks client a off, as well Oh lol I'd forgotten about that 😅️ ↺

There would be a fight though when A tried to log back right?

may or may not need to change password too even with fast, they may have password stored or just have it somehow

> usually. it depends what the reason you wanted this is Right now we were discussing what happens if a device is lost/compromised ↺

Then I'd definitely change pass and *then* kick them all

("we" = some of us in Prav, not this room)

Wondering if current FAST impls invalidate and/or kick existing sessions when pass is changed 🤔

hopefully changing pass kicks all sessions anyway

Ah, I should test that

> Wondering if current FAST impls invalidate and/or kick existing sessions when pass is changed 🤔 And that ✏ ↺

I wonder if it's worth mandating this in FAST (if it isn't already). I'd assume that if I'm invalidating a token, I'd implicitly want to invalidate existing sessions using that token as well (especially since this token is targeted to a specific device)

sounds right for a token for sure is it right for the password though?

I don't think it's a spec issue since we're talking about out-of-band invalidation methods for after a device is lost

Seems like a spec hole to have a way to issue but not revoke per-device tokens, does it not already support that?

it supports revoking your own token taht you auth'd with

but anything else is an account management issue so out of scope for an auth spec

and easily implemented with no spec at all

isn't the only point of per-device tokens that you can revoke them when you no longer own/trust that device?

100% of applications I've seen with per-device tokens support this

it's not the only point, but it's a useful part of the point yes. and there are implementations around this and even some xeps (or protoxeps?) around account management that also mention such things of course

other parts of the point include making 2fa possible and not storing passwords on device

Now I'm curious if a compromised device can change the account password, kill other sessions, and fully take over the account 🙃

usually yes. that's always been the case

there are some efforts to make that less possible as well

No way around it before FAST, but FAST should probably make it impossible

IIRC FAST doesn't define what the cliens logged in through that mechanism are allowed or not allowed to do?

well that's more of a session acl issue, but I agree it's something sasl2 makes easier at least since we can identify session now

So it's as good as having a regular, fully-authenticated session

Unless we change other things as well

> A client can choose to invalidate a token before its expiry. > > For example, a client might implement a "log out" mechanism for people sharing a web browser or system. Explicitly invalidating the token with the server ensures that even if an unauthorized user managed to recover the token from the system, it would be useless. From the FAST XEP

But it seems to be only by the client itself, not remotely via other clients: > To invalidate the token, the client MUST successfully authenticate using the token as normal, but include an 'invalidate' attribute on the <fast/> element with a value of '1' or 'true'. > > Upon successful authentication with the 'invalidate' attribute set, the server MUST immediately invalidate the token and prevent its use for future authentication attempts. The server MUST NOT include a new token in the response (even if the token was due for rotation), unless the client also included a FAST <request-token/> element in its authentication request.

Also, > The client MAY close the stream after the server acknowledges successful authentication, or it MAY proceed with the session as normal. so there's no automatic logging out (which makes sense because so far the "logging out" action is being initiated from the client that's holding the token, not some other client, so it presumably knows what it wants to do

right. that's a different case than we're talking about here

Yeah

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

or just ad hoc commands would be better, but this exists too

~Would it make sense to have an XEP for logging someone out (maybe "FAST Token Management" which lets you see what other devices are logged in and also invalidate the ones you don't want)?~ I was just going to ask pose the above question but you might have answered it

> https://xmpp.org/extensions/xep-0494.html > If the identified client has previously authenticated with a password, there is no way to revoke access except by changing the user’s password. If you request revocation of such a client, the server will respond with a 'service-unavailable' error, with the 'password-reset-required' application error: That XEP has thought of everything! ↺

Well not everything: I see it doesn't mandate the server close the existing stream as part of the revocation process. Or is that supposed to be implied? I'd be happier if it were made explicit

> or just ad hoc commands would be better, but this exists too But then each server could end up returning things differently right? Or are you saying that's fine ↺

I suppose it's a way for the server to expose all that functionality without the client having to make changes

yeah. ad hoc means when the server implementation changes we're good. like a web app, etc. there's a reason so many people implement account management stuff in web app instead of in app but ad hoc fixes that

I wish there was some kind of augmented ad-hoc, i.e. it's standardised in a way that clients can use in specialised ways but also works as a regular ad-hoc commands as a fallback

The idea we were discussing for Prav is to log out the user as part of a trust revocation process (distrusting OMEMO keys through ATM, etc.) so it'd be better to have something more standard than ad-hoc for that

I think the pieces are there? For example Data Forms are already standardised to some degree in the sense you can assign semantic meaning to the different fields

> I wish there was some kind of augmented ad-hoc, i.e. it's standardised in a way that clients can use in specialised ways but also works as a regular ad-hoc commands as a fallback yes, this is done all the time ↺

> The idea we were discussing for Prav is to log out the user as part of a trust revocation process (distrusting OMEMO keys through ATM, etc.) so it'd be better to have something more standard than ad-hoc for that why? why is ad hoc not enough for that? ↺

How would we detect where to find the "log out other devices" ad-hoc command for whatever server we happen to be running on?

the node could still be in a standard place specified by a XEP

(which would also allow clients to implement only that, even if they don't have full ad hoc command support)

Is that what singpolyma meant by "this is done all the time"?

Can you give me an example of an XEP that does this?

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

> How would we detect where to find the "log out other devices" ad-hoc command for whatever server we happen to be running on? Why do you need to detect that? You can't just show the list and the user can see it? ↺

> https://xmpp.org/extensions/xep-0401.html Ohh nice ↺

This changes things

> Why do you need to detect that? You can't just show the list and the user can see it? It was because the plan was to have a combined button saying "I don't trust this device" that triggers distrusting (through ATM) as well as logging out the user. So it's multiple things happening at once ↺

But if it can be defined using ad-hoc commands like XEP-0401 does that'd be one way to solve it

why not have a command that does both those things?

Because ATM revocation happens client-side?

yeah

has to happen client side because you need to sign it or whatever right?

Yeah and then it's basically just a "X device doesn't trust Y key any more" that gets relayed to everyone else

As far as the server's concerned it's just another series of messages

> > 📱 PDA > And that too. > Who else boycotts the merger of notions of "smartphone" and "PDA phone", and argues that modern "smartphones" are rather descendants of PDAs, while smartphones are dead? > I'm still not sure where did the word «коммуникатор» come from. Possibly somehow related to French «PDA Communicant». [Slight necroposting, yep] Modern smartphones are not, in fact, descendants of PDAs, as PDAs don't have cellular modem ↺

My laptop has a cellular modem as do many laptops today. Does that make my laptop not a descendant of laptops