user-creation-flow.md (1791B)
1 # Technical documentation on User Creation 2 3 This document details user creation in Zenflows. 4 5 The basic principle is end-to-end encryption: secret keys are not held by the server backend, but created on the frontend side. 6 7 ```mermaid 8 sequenceDiagram 9 participant B as Backend 10 participant F as Frontend 11 participant E as Email 12 F->>B: request create/claim <name, email> 13 B->B: create OTP token 14 B->>+E: send token to email, listen until expiry 15 B->>F: ACK request, waiting confirmation token 16 E->>-B: confirmation link, hit before expiry 17 B->B: create/claim user 18 B->>F: ACK creation, request public keys 19 F->F: create keyring 20 F->>B: send public keys 21 B->B: save user pub keys 22 B->>F: OK, confirm creation 23 ``` 24 25 ## User create/claim 26 27 User **creation** should create a new corresponding Agent in Valueflows (User and Agent coincide) 28 29 User **claiming** should happen if an **Agent with the same Email** already exists in the database, then the Agent is filled with the new information from this process (public keys, name, etc.) and becomes valid for login. 30 31 ## Public keys 32 33 The public keys are created in the [keygen.zen](zencode/src/keygen.zen) script and they are structured as follows: 34 35 ``` 36 ethereum_address = octet[20] , 37 pubkeys = { 38 ecdh_public_key = octet[65] , 39 eddsa_public_key = octet[32] , 40 reflow_public_key = ecp2[192] , 41 schnorr_public_key = octet[48] 42 } 43 ``` 44 45 They values stated above are specifying their binary format in Zenroom, however both the Frontend and the Backend do not need to decode them and access them in binary format, all they need to do is to save them as encoded strings, each in their own respecting encoding (most base64, some hex).