Copied from: okTurtles/group-income#3139
Problem
We currently are using identity contracts that have somewhat flimsy semantics:
- We have no way for apps to contact users outside of the app (e.g. via email) about important events like "running out of quota/$$" or "inactivity - your account will be deleted in ~60 days"
- We're currently updating profile properties like display name and profile picture in the chain when they should be part of the KV
- They're scoped to a GI-specific namespace like
gi.contracts/
Solution
Create a new okTurtles.contracts/identity contract that primarily relies on the new KV API to manage its properties. Unless for some reason a history is needed, properties should go in the KV.
This will be used for demo apps and can be used as a standard contract type. Its KV names should use a standardized key slot for things like email, one that the Chelonia server checks by default. We should come up with a way for the values to be encrypted so that the server is able to read them and so can others who are given access. This way people cannot scrape emails but the server is still able to contact users with important expiry and quota-related messages.
Then we should use these contracts going forward. It will probably require recreating groups, so we should bundle this with other issues that require recreating groups.
Copied from: okTurtles/group-income#3139
Problem
We currently are using identity contracts that have somewhat flimsy semantics:
gi.contracts/Solution
Create a new
okTurtles.contracts/identitycontract that primarily relies on the new KV API to manage its properties. Unless for some reason a history is needed, properties should go in the KV.This will be used for demo apps and can be used as a standard contract type. Its KV names should use a standardized key slot for things like email, one that the Chelonia server checks by default. We should come up with a way for the values to be encrypted so that the server is able to read them and so can others who are given access. This way people cannot scrape emails but the server is still able to contact users with important expiry and quota-related messages.
Then we should use these contracts going forward. It will probably require recreating groups, so we should bundle this with other issues that require recreating groups.