Invitations #307
Replies: 3 comments
-
(old proposal by: @da2ce7) Proposal for invitation specification:
There is NO secret data that is stored on the server for making a Invitation.
Making a Token.
Using a Token.
Upon Successful registration the server allocates:
If the Registration somehow fails or has a time-out, the Server unlocks the Invitation Slot Rust Blake3: https://docs.rs/blake3/latest/blake3/ A Invitation-code is encoded with: Bech32m.
The Bech32m Encoding is both Encoded and Decoded on the Fronted. |
Beta Was this translation helpful? Give feedback.
-
(old proposal by @da2ce7), but superseded by: Signed Invitation CodesThis is an alternative specification for making Invitation Codes. This specification has a specific advantage on-top-of the Normal Invitation Codes: Non-Interactive Code Generation. Non-Interactive Code GenerationNo-interactive code generation allows for a user to create new invitation codes without any additional communication with the server. This would allow for example an invitation server or bot to give out codes without needing to continually connect to the Torrust Backend API. Signed Invitations Overview
Technology UsedUsing standard schnorr signatures for secp256k1. Used by Bitcoin in the recent Taproot Upgrade. BIP340 - Schnorr Signatures for secp256k1 (The Signing Algorithm) SpecificationIntroductionUsers of Torrust should easily be able to invite their friends to also use Torrust. One option, when public facing registrations have closed, is that uses are granted a certain amount of 'invitation slots' that their friends may use. Users who invite other users should be linked, so that the Torrust Administrators can easily resolve issues when invitations have unfortunately brought unfriendly people into the community. Power-Users may want to setup systems that allow them to automatically generate new invitations. It is convenient for these systems to run independently without need of a connection to the Torrust-Backend API. The Torrust-Backend should not store any secrets from the users. Just like the use of appropriately implemented hashed passwords, likewise invitations should not rely on secrets held by the backend. Backend DatabaseInvitationsTABLE
Invitation SlotsTABLE
User Public KeysTABLE
UserTABLE
Invitation Format
Encoded Formats.
The invitation is encoded and decoded by the frontend. |
Beta Was this translation helpful? Give feedback.
-
(old comments by @WarmBeer) I made an activity diagram of what happens when the backend receives a user registration request. We talked about how to store pending user registrations in the database and how to clean them up. The ideas we discussed were: 1. Create a separate DB table "pending_users" and store new users in that table until they are verified (on which they will move to the "user" table). The table will also have a scheduler to automatically expire rows that didn't verify in time. Pros:
Cons:
2. Keep using the "emailed_verified" flag in the "users" table. The backend will then have to run a cronjob to remove users that took too long to verify their email. Pros:
Cons:
While working on the activity diagram, I thought of another solution: 3. Store unverified accounts in memory (with something like Redis) and only submit them to the "user" database on verification. Pros:
Cons:
Let me know what you think :) |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Related to Fronted Discussion: torrust/torrust-index-gui#285
Beta Was this translation helpful? Give feedback.
All reactions