jdev - 2021-06-13

  1. Martin

    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. 🙂

  2. emus


  3. Martin

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

  4. emus

    even more 👍

  5. Sam

    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

  6. Sam

    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

  7. Zash

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

  8. Zash

    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

  9. Sam

    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!

  10. Sam

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

  11. Sam

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

  12. Sam


  13. Zash


  14. moparisthebest

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

  15. moparisthebest

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

  16. Sam

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

  17. moparisthebest

    Why wouldn't you just have an account instead?

  18. Sam

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

  19. moparisthebest

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

  20. Sam

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

  21. Sam

    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.

  22. Sam

    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.

  23. moparisthebest

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

  24. Sam

    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.

  25. moparisthebest

    For at most 1 right?

  26. Sam

    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.

  27. moparisthebest

    For both pleroma+mastodon you are talking 1 SQL query

  28. Sam

    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.

  29. Sam

    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.

  30. moparisthebest

    We might be talking about different things...

  31. Sam

    I guess so

  32. Sam

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

  33. Sam

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

  34. Sam

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

  35. moparisthebest

    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

  36. Sam

    That is not what this example does

  37. Sam

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

  38. Sam

    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.

  39. jonas’

    this is more like "Sign in with Facebook"

  40. Zash

    OpenID Connect ?

  41. Sam

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

  42. Zash

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

  43. Sam

    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"

  44. Sam


  45. Sam

    Here is the new invite flow that the protoxep enables.

  46. Zash

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

  47. Sam

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

  48. Sam

    Maybe an implementation section.

  49. Sam

    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)

  50. Zash

    One of the tradeoffs here involves revocation.

  51. Sam

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

  52. Zash

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

  53. Zash

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

  54. Sam

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

  55. Zash

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

  56. Zash

    So. Trade-off.

  57. 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.

  58. Zash

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

  59. Zash

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

  60. Zash

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

  61. Sam

    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.

  62. 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)

  63. Sam

    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.

  64. Zash


  65. MattJ

    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

  66. Sam

    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)

  67. Sam

    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 ¯\_(ツ)_/¯

  68. Sam

    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.

  69. MattJ

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

  70. Zash

    (mod_rest to the rescue!)

  71. MattJ

    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

  72. MattJ

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

  73. MattJ

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

  74. MattJ

    which is used for the "circles" feature in Snikket

  75. Sam

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

  76. Zash

    I suggested [CJ]WT for this before.

  77. Sam

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

  78. Sam

    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.

  79. Sam

    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.

  80. defanor

    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?

  81. defanor

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

  82. Zash

    Disconnected how?

  83. defanor

    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.

  84. Zash

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

  85. Zash

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

  86. Zash

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

  87. Zash

    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.

  88. Zash

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

  89. defanor

    It is, 0.11.2-1+deb10u2.