jdev - 2021-06-13

As I just recently discovered the JID header ( https://wiki.xmpp.org/web/Jabber_Email_Header ): Does anyone know of more mail programs supporting it? Would be nice if they feature it more prominently. Also for Thunderbird supporting email and xmpp this one could be used for suggesting to add the xmpp contact if the header is present in an email. 🙂

👍

emus: Already added a short german blogpost for the next newsletter. 😁

even more 👍

Earlier in here (I think?) someone was talking about self-provisioning Matrix accounts based on an existing Mastodon account and it made me realize we didn't have an easy way to do something similar so I started experimenting with https://github.com/xsf/xeps/pull/1068

Anyways, now here is an example of the new protoxep that does what the Matrix thing someone linked does. You can auth with mastodon then it gives you a signed URL to click that can be used by a client to provision an account on an XMPP server: https://github.com/mellium/fediverse-xmpp-onboarding

TL;DR of what the flow looks like would be appreciated

I take it this is different from the thing where you point your XMPP server at an existing user database, which is a common method AFAIK

TL;DR — user clicks "verify" button and gets redirected to a mastodon auth page. They log in. They get redirected back to a page with a barcode/link that contains a token. They click the xmpp: link (or scan the barcode) and their client provisions an account on the servere using easy onboarding. They have an account!

I should also have said "server verifies that the token sent to it by the client is valid", that's important.

Ehh, maybe that was covered by "using easy onboarding"

https://share.samwhited.com/sam/jV7E8PhJUjn6tPC9/flow.png

Neato

Sam: sounds far more complicated than them just having an account?

Like my email accounts are XMPP accounts, I create them with mypostfixadmin and prosody is using mod_auth_sql

The whole point of this is that you don't have an account but you need one

Why wouldn't you just have an account instead?

I think I'm misunderstanding something. If you don't have an account and need one, how can you just have an account already?

This is something the mastodon+xmpp server admin sets up?

Yes. Mastodon isn't the point though, that's just an example.

The point of the protoxep is to allow users to self-provision accounts with some form of authorization instead of having to ask the server admin for an account.

In this example we use Mastodon as that form of authorization. If you have a mastodon account you can also self-provision an XMPP account.

Right, so all you need is the xmpp server to be able to authenticate against a different account back end? Which has existed forever?

Sure, you can do that too if the backend is shared or you don't mind giving both things access to your database or writing server specific code for each one, etc.

For at most 1 right?

Also if you even have access to the authorization thing. I might allow my fedi friends an account on my server, but I don't have access to my fedi instance.

For both pleroma+mastodon you are talking 1 SQL query

If I have access to their database, yes. But I don't run my mastodon instance. Also that's not the point. Again, this is just an example.

You could always write an extension and run it on the server. The point of this is for when you don't want to run the thing on the server.

We might be talking about different things...

I guess so

User onboarding already exists, that's all this is.

It's easy user onboarding except we get rid of the link between the website showing a barcode and the XMPP server.

If easy user onboarding has a point, this has a point as well.

I'm talking about you sign up for a mastodon account nick@example.com, and you can use that username+password to log into your XMPP account nick@example.com

That is not what this example does

This example just uses mastodon for authentication and to authorize the user to access IBR. It's a self-provisioning portal.

If you have access to both the mastodon instance and the XMPP server you could make it a single shared account with the same database and you wouldn't need self-provisioning.

this is more like "Sign in with Facebook"

OpenID Connect ?

jonas’ sort of. It's not signing in, it's authorizing you to use IBR.

A bit like https://modules.prosody.im/mod_invites_api.html with 3rd party authentication instead of a fixed API key

Maybe that's a better way to explain it: "it lets you do invites except you don't have to be able to talk to the XMPP server to generate one"

https://share.samwhited.com/sam/ZdzPyW19NvOIqE2R/sequence.png

Here is the new invite flow that the protoxep enables.

I wonder if MattJ has the arguments for opaque tokens issued by the XMPP server written down somewhere.

I should add a thing being like "these tokens are opaque, clients don't look inside the base64"

Maybe an implementation section.

Even if the server doesn't plan on ever allowing a third party to create tokens, it might use this token format itself just so that it doesn't have to store anything in the database and deal with a cronjob to clean up expired invites and what not (depending on the system of course, in some things that's not a problem)

One of the tradeoffs here involves revocation.

Indeed; you can't revoke a single token, only a single shared secret and all tokens created with it.

With the shared key method you'll have to store revocations.

You can revoke a single token by the XMPP server adding it to a database.

Oh yah, sorry, that should have been qualified with "without adding back on all the database stuff"

The opposite from opaque tokens directly issued by the XMPP server, where revocation is done by deleting them from the XMPP server.

So. Trade-off.

*nods*. And of course it should be noted that this format doesn't replace anything. Servers could issue opaque tokens themselves and only use this to allow third party trusted applications to generate tokens.

Probably not that hard to have the 3rd party application ask the XMPP server for a token either.

Tho you avoid having to invent _that_ API by using a shared secret signed token method. ✏

Probably not, but then you have to create an account for them and figure out how to do XMPP stuff and long lived connections and it may take time to connect, etc. this is pretty much instant and probably easy using most languages standard libraries.

(the whole point of this for me was actually to make it easier to do this without having to connect to XMPP in the thing I was working on)

The IQ to request a token does exist already though if you wanted to do it that way. It could be one of these tokens, or it could just be a random string or some opaque server-specific proprietary token. The client wouldn't know the difference either way.

Indeed

Sam [16:02]: > Maybe that's a better way to explain it: "it lets you do invites except you don't have to be able to talk to the XMPP server to generate one" People have argued for this in the past, but I've yet to hear any convincing argument for it

Probably not a problem for most XMPP servers but at HipChat it was about how much storage in the database we could do. Things like this tended to be difficult and have too many rows that had to be pruned when they expired (I don't think we did invites specifically, but we used this strategy for some API tokens and the like)

Also I just didn't want to jump through all the hoops of dealing with XMPP things and the slowness of connecting to the server before I could return a page to the user in the thing I was working on; this avoids all that and the pitfalls don't matter for my case ¯\_(ツ)_/¯

And I didn't want to figure out how to make an admin account that had all the right permissions but no more (if that's even possible). Basically I don't want to deal with server specific things because I am not an ops person.

Yeah, sure, if the overhead is an XMPP connection, I get your point

(mod_rest to the rescue!)

As for storage... not sure how realistic that is. I'm pretty sure invites are going to be the least of storage concerns for a large-scale server

And for the parameters attached to invites... that's tricky, it's been evolving continuously since our first implementation

e.g. the most recent addition (I think) was a field to say which shared roster group an invite is to

which is used for the "circles" feature in Snikket

That's fair, this could probably be more flexible in that regard

I suggested [CJ]WT for this before.

Huh, TIL: CWT. I guess that was an obvious next step since JWT exists. But yah, that would probably be a good idea

I was trying to keep it simple, but it makes sense that servers might want to be able to sneak some other data in there.

Or maybe it's worth keeping it simple and just having a "server defined" opaque area. I dunno, I'll have to play with it and think about it some more.

I've observed an odd situation between Dino (some old version) and Prosody (0.11.2) now: with stream management enabled, Dino sent an "unavailable" presence, disconnected, then reconnected, resumed the session, and stayed at "unavailable" presence (so the user wasn't receiving messages until the next reconnect). It's wrong for Dino to try to resume that session, as well as for Prosody to resume it, isn't it?

XEP-0198 seems to imply that cleanly closed sessions shouldn't be resumed, but I don't see it written clearly.

Disconnected how?

Ah, with a read error. So it appears that it was about to close the session cleanly, but then an error happened. Then Dino should have handled it by sending an "available" presence after reconnecting, I guess.

I would like to point out that Prosody does not support XEP-0198, unless you add a 3rd party community supported module.

What matters is whether `</stream:stream>` was sent.

If it didn't close the stream then I see nothing wrong with resuming it.

Sounds like a race condition of some sort in the client. But since you say it's an old version you should probably test with a more recent version.

Also Prosody 0.11.2 is 2½ years old. I sure hope it's the Debian version that includes all the security fixes.

It is, 0.11.2-1+deb10u2.