User communication concepts and naming

documentation

#21

StatusAccount indeed is not really explainful, and actually those accounts are all user-owned, they are standard ethereum identities.

What you could have is “Status-compatible Public Profile” or other derivates, however the Account which controls this public profile is not related to Status. StatusIM only provide the interface to certain standards.


#22

Our main privacy concern is that we use the wallet key to directly derive the chat identity as the wallet public key.
As feature and privacy concern we have that any chat identity can derive the wallet of user.

We had the discussion of having one identity per dapp, this might be done with Identity, which new dapps could have its own key to access funds from an Self Sovereign Identity. This still don’t fixes privacy, as we always need to fund the key from somewhere.

For Dapps which don’t require inchain transactions, but requires an Identity, it would be possible to add the dapp-specific public key hashed in keccak256 listed in the Self Sovereign Identity.
As example, Status Chat could read a message signed from a key, and this message could contain in its payload the user-public-identity, where clients could query in the smart contract to check if key is listed as a key. For Messages that pay the network, this key could be allowed to sign payments.

Currently most of in-chain actions are “pull based”, users pull the transaction to queue and incentivize the mining by posting a gas fee. With Identity contract it’s possible to have a “push based”, where transactions are authorized in a smart contract action key, which could control subscription rules.
Instead of using a regular external owned account as key, the User would set an smart contract as key, which would contain the rules for the subscription, where subscriber could push funds based on those rules.


#23

We also need to define a standard way of displaying Identities. There is a proposal of standard here https://github.com/ethereum/EIPs/issues/928

We can propose our own standard, but what is important is that in all Status related stuff this is coherent. I’m doing some experiments in how to display addresses data in a more human way, such as using colors.

This should build an “Identity Input” component, which could support both public key or address, but might require public key in some cases (Contact Code needs full public key, transactions only need address).
Within this Identity Input we can also support universally the ENS resolver, and public avatars, such as suggested in ERC 928.
Identity Component would intelligently query the Identity for needed information regarding the it’s value, where if it’s a contract, it could support ERC780, former ERC725 and ERC735 ABI to badge with known claims/signers, e.g. Status GMBH badge/unbadge addresses to get a “support team”, “core dev”, “etc” badges to some identities which are “certified as trustful” to the badge they hold.