We've also created a little example tool that uses it to allow users of a Mastodon instance to self-provision an account on a chat server using the new token-based registration flow (this is just an example, don't use it in prod): https://github.com/mellium/fediverse-xmpp-onboarding
different private key than the one used by user invites so that I can see how many users from the conference registered.
The whole crypto part looks iffy to me. Why does it not leverage existing crypto the user is already using? @mellium - 2/2
@0 the token isn't opaque to the server, just to the client and this doesn't change. The server could already do all of this if it wanted (eg. import tokens issued using a different key at a conference). I don't understand what you mean about the crypto; it does use existing crypto. Having a shared secret is fine; this is just a simple signed token and a classic use of symmetric signing (think JWTs on the web which often work similarly).
@0 And the server can revoke credential-issuing privileges by changing the secret or just not accepting tokens signed with a particular secret.
> I want to use a different private key than the one used by user invites so that I can see how many users from the conference registered.
The whole crypto part looks iffy to me. Why not leverage existing user-related crypto? In particular #XEP0374?
Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.