Change how profile data are stored

[RiccardoM]

Context

Currently the profiles are stored using a custom keeper and they are saved using the following data structure:

type Profile struct {
  DTag         string         `json:"dtag" yaml:"dtag"`
  Moniker      *string        `json:"moniker,omitempty" yaml:"moniker,omitempty"`
  Bio          *string        `json:"bio,omitempty" yaml:"bio,omitempty"`
  Pictures     *Pictures      `json:"pictures,omitempty" yaml:"pictures,omitempty"`
  Creator      sdk.AccAddress `json:"creator" yaml:"creator"`
  CreationDate time.Time      `json:"creation_date" yaml:"creation_date"`
}

However, since a profile is just an extension of a Cosmos account, I think we should merge the two concepts into a single one.

Solution

In order to achieve a better organization of the code, what we could do is extend the Cosmos Account interface with the data that are currently defined inside the Profile structure. To do so, we could simply define a Profile as being the following:

type Profile struct { 
  *BaseAccount 
  DTag         *string        `json:"dtag" yaml:"dtag"`
  Moniker      *string        `json:"moniker,omitempty" yaml:"moniker,omitempty"`
  Bio          *string        `json:"bio,omitempty" yaml:"bio,omitempty"`
  Pictures     *Pictures      `json:"pictures,omitempty" yaml:"pictures,omitempty"`
}

This would have the following pros.

• No need to have a custom saving mechanism
  By extending the Account interface, we could allow the auth module to take care of storing the profiles data.

• No duplicated data
  Since the Account interface already contains an Address field, we would not have to include that inside the Profile structure (currently the Creator field).

• Easier future extension
  If other fields are going to be added in the future to the Account interface (eg. different types of keys), then we would have them directly inside the profiles as well. An example could be the address defined inside Adding withdraw address to Profile #258

• Easier data retrieval
  Since a profile would be a simple account, one single API call (/auth/<address>) would be sufficient to get all the latest info about a profile

What do you guys @kwunyeung @bragaz think about this?

[leobragaz]

I think this is a good improvement, so if I understood well the profile struct will implements the ExtendedAccount account you mentioned in #258 right?

[RiccardoM]

@bragaz Exactly, the complete inheritance chain would then be:

x/profile/Profile -> x/auth/ExtendedAccount -> x/auth/BaseAccount

This would allow the Profile to be stored using the x/auth/Keeper as well

Edit

The above depicted inheritance chain should be the final one. However, I think it would be better to first implement the following:

x/profile/Profile -> x/auth/BaseAccount

And then, during #258 implementation, extend this as well to match the above described one.

[leobragaz]

@RiccardoM After closing the stargate PR this could be done in the next milestone