Adding withdraw address to Profile

[kwunyeung]

One security concern on Desmos is if a user is using the an account key controlling assets to do social interactions, the key is being accessed too frequently. This is not desired especially when a user would like to store the assets in hardware wallets and use another associated key to operate any social interactions. With the current establishment of Desmos Profile, we can enhance it, make it the core of the social identity which associate different keys on Desmos. Instead of using the account concept in Cosmos SDK, which is a pubkey, we can treat Profile as an Account.

In our tokenomics, users will be rewarded with their social engagements. To isolate the key that is being used to operate social interactions and crypto assets, we can simply add a WithdrawAddress in the existing Profile structure.

type Profile struct {
	...
	...
	...
	WithdrawAddress      sdk.AccAddress `json:"withdraw_address" yaml:"withdraw_address"`
}

When a users request to withdraw the rewards, the rewards will be distributed to the associated address instead of the Creator address. WithdrawAddress can only be associated with a single Profile. This is similar to the Account structure in Flow.

With is structure, we can add more functionalities to an identity on Desmos which different keys can be used in different features. For example, we can add another associate key which is only being used for voting.

type Profile struct {
	...
	...
	...
	WithdrawAddress      sdk.AccAddress `json:"withdraw_address" yaml:"withdraw_address"`
	GovernanceAddress    sdk.AccAddress `json:"governance_address" yaml:"governance_address"`
}

By using Profile as a user identity, we basically solve #45 . When a dapp query the account, it can directly query the @dtag and get all associated information.

@RiccardoM @bragaz @terencesflam please comment.

[RiccardoM]

I really like this idea. However, I think it might be better to act as follows:

1. Implement this new addresses types as a new kind of Account implementation, let's call it ExtendedAccount.
2. Extend the ExtendedAccount object adding our data as defined inside Change how profile data are stored #261

This way with (1) we would also extend the Cosmos SDK (maybe merging our changes into it to make it publicly available, and with (2) we would obtain what you @kwunyeung have described inside the issue.

I've thought about this separation of concerns since I think that adding different addresses will have complications on the Cosmos SDK as a whole (the x/gov module as well as the x/bank one).

[kwunyeung]

Great! That's a better structure.

[leobragaz]

I think this can be closed? @RiccardoM

[RiccardoM]

@bragaz Instead of closing it let's keep it on hold. It might be interesting to still work on in the future

[RiccardoM]

Closing this since it can be implemented using x/authz and different authorization