MartinAs 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. 🙂
Martinemus: Already added a short german blogpost for the next newsletter. 😁
emuseven more 👍
SamEarlier 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
SamAnyways, 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
ZashTL;DR of what the flow looks like would be appreciated
ZashI 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
SamTL;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!
SamI should also have said "server verifies that the token sent to it by the client is valid", that's important.
SamEhh, maybe that was covered by "using easy onboarding"
SamHere is the new invite flow that the protoxep enables.
ZashI wonder if MattJ has the arguments for opaque tokens issued by the XMPP server written down somewhere.
SamI should add a thing being like "these tokens are opaque, clients don't look inside the base64"
SamMaybe an implementation section.
SamEven 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)
ZashOne of the tradeoffs here involves revocation.
SamIndeed; you can't revoke a single token, only a single shared secret and all tokens created with it.
ZashWith the shared key method you'll have to store revocations.
ZashYou can revoke a single token by the XMPP server adding it to a database.
SamOh yah, sorry, that should have been qualified with "without adding back on all the database stuff"
ZashThe opposite from opaque tokens directly issued by the XMPP server, where revocation is done by deleting them from the XMPP server.
Sam*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.
ZashProbably not that hard to have the 3rd party application ask the XMPP server for a token either.
ZashTho you avoid having invent _that_ API by using a shared secret signed token method.✎
ZashTho you avoid having to invent _that_ API by using a shared secret signed token method. ✏
SamProbably 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.
Sam(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)
SamThe 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.
> 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
SamProbably 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)
SamAlso 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 ¯\_(ツ)_/¯
SamAnd 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.
MattJYeah, sure, if the overhead is an XMPP connection, I get your point
Zash(mod_rest to the rescue!)
MattJAs 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
MattJAnd for the parameters attached to invites... that's tricky, it's been evolving continuously since our first implementation
MattJe.g. the most recent addition (I think) was a field to say which shared roster group an invite is to
MattJwhich is used for the "circles" feature in Snikket
SamThat's fair, this could probably be more flexible in that regard
ZashI suggested [CJ]WT for this before.
SamHuh, TIL: CWT. I guess that was an obvious next step since JWT exists. But yah, that would probably be a good idea
SamI was trying to keep it simple, but it makes sense that servers might want to be able to sneak some other data in there.
SamOr 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.
defanorI'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?
defanorXEP-0198 seems to imply that cleanly closed sessions shouldn't be resumed, but I don't see it written clearly.
defanorAh, 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.
ZashI would like to point out that Prosody does not support XEP-0198, unless you add a 3rd party community supported module.
ZashWhat matters is whether `</stream:stream>` was sent.
ZashIf it didn't close the stream then I see nothing wrong with resuming it.
ZashSounds 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.
ZashAlso Prosody 0.11.2 is 2½ years old. I sure hope it's the Debian version that includes all the security fixes.