Open malteish opened 2 months ago
Reasons why we need to store the profile in the first place
Reasons why we need to store the profile in the first place
- During the challenge response flow, the Backend checks if the challenge was signed by the users signing key
- When receiving a message the Postmark is signed by the receiver's encryption key DS
Prerequisites: A user can have multiple ens names, e.g. alice.eth
and 0x95222290DD7278Aa3Ddd389Cc1E1d165CC4BAfe5.addr.dm3.network
. They must publish a dm3 profile for every ens name they want to use with dm3 (this is a one-time setup and is NOT done by the delivery service).
Once a profile is published, the user can create an account for that profile with a delivery service through the account
endpoint, which expects an account creation message that is signed with the profile's signature key.
createAccount
and a timestamp to prevent replay attacksAn account can be deleted by the account owner through the account
endpoint. The account deletion message must be signed with the profile's signature key and contain the ens name, the delivery service URL, the topic deleteAccount
and a timestamp to prevent replay attacks.
Plan:
getSession
-> getAccount
setSession
-> createAccount
. Create accounts in backend and ds to store information that exceeds the public profile, including "this profile is registered with this service". Since "account" already exists in postgres db in backend, check if it is needed in redis (and if redis is still needed at all).lib/delivery
to lib/server-side
UserProfile.ts
Keys.ts
Session.ts
profile.ts
from backend and ds can be unified and move to server-sidepersistence
from backend and ds: redis part seems to be duplicated, check every file and extractAccount
account
already exists in postgres-db of backendaccount
is also used as reference to the ethereum account (as in address 0x...), so it might not be the best name to use again. Define account
and accountId
instead?account
, e.g. in the jwtShould an account be identifyable by it's unique ens name? That might be a good idea.
Background
Currently, both backend and delivery service store the user's "profile" in their database. Since the profile should ideally be managed on-chain, only one source of truth should ever exist. There are several options:
Option 1 is the way to go.
Discussion and results
See notes.
Which data must be handled?
Who handles what?
Sessions
The services store information about the user in "sessions", which is a very unfortunate term to use in this context.
Estimate: 3 days