Invite flow for users

[emilvincentz]

currently the flow looks like this:

User A send email to user B with instructions on how to sign up + send them the token

When user B has created profile, they should send their userrname to user A.

User A can then invite user B to a space

User A will have to notify user B that they now are invited and need to accept

User B accept invite and can start using Acter.

[emilvincentz]

@MirekKolaja here is the issue and current flow

[emilvincentz]

@gnunicorn sorry if i've asked this before, but would it not be possible to create a unique invite-link for spaces (like we have it for chats)? So that after the user has downloaded the app and logged in can click on that link and auto join?

[gnunicorn]

as a rule, everything is possible (in tech), it is always a question of how much you are willing to pay for it. In this case: this is not possible straight away because: 1) our apps are not having what is called "deep linking" implemented yet: a feature by the operating system around, that when a particular type of link is clicked, a specific app is opened (think a zoom-link). 2) our app to react to any of those "deep links" at all 3) the ability for our app to show and offer options for reading remote room information 4) from the matrix-protocol "invite-links" are only possible for publicly accessible rooms .

So that after the user has downloaded the app and logged in can click on that link and auto join?

For public groups that are in our room directory, a user can go to the room-directory and search for the room name/ space via Dashboard -> My Rooms -> Add (on the top right).

[gnunicorn]

Okay,

so. https://github.com/acterglobal/synapse-super-invites reached 0.8 stability now (within integration tests) proofing it can be done. Now what it does it the following: it is an extension to synapse (our matrix-server) with matrix-server-controls. Among other things that means it can control room-membership in the name of users and it allows to associate some token-name with a set of rooms that a user wants the others to be invited to. Upon redeeming that token the extension adds the user - regardless of how visible that room is. It provides json-API endpoints that the App can directly use upon registration and explicit calls.

In terms of actual user flow - and that is the integration in the app I am working on next - I image it to go something like this:

1. User Liam create a new token, associates a few rooms with that for e.g. 2 spaces and 3 chats rooms (and can optionally say, they want to be auto-invited into a DM with that user upon redeeming) from within the App.
2. That token is used as the registration token (the extension can be configured to also create them as registration token), and after registration the app automatically attempts to redeem that token against the API as well.
3. As a result the User is immediately invited (/added*) to the rooms configured by Liam and (optionally) automatically started a DM with Liam.
4. A token can only be redeemed once (we keep track, so we know who came through which token), but it can also be done after the registration via some other invite-interface. The same as 3 takes place whenever a token is redeemed.

How does that sound?

* I am currently investigating if I can only invite users (that seems to work) or whether I can directly add them as well from the extension (if so, I might make that the default).

[emilvincentz]

Sounds really great @gnunicorn !

Two quick questions:

1. When inviting/addting, can we also make them admin of a space?
2. When you say that a token only can be redeemed once, does that mean that you have to create a new token for each member you want to onboard?

[gnunicorn]

When inviting/adding, can we also make them admin of a space?

I have to check, but potentially yes - if the token-creator is admin themselves. Just a question how we manage to allow for that in the UI. But I suppose that is mainly for you to create the infrastructure and then allow someone to have a token and directly be taking that over, correct?

When you say that a token only can be redeemed once, does that mean that you have to create a new token for each member you want to onboard?

Sorry, that was phrased misleading. Redeemed once by each user - they are currently unlimited in use count and don't expire, until the owner removes them again (we keep the record around though, they just aren't valid anymore).

[emilvincentz]

Well with those clarifications, I think this sounds solid!🙌

[gnunicorn]

since we have a first iteration of #1160 merged now, I consider this closed for the time being.