Profile changes

[RiccardoM]

Feature description

Inside the x/profile module we currently use the following structure to store the data of a user:

type Profile struct {
  Moniker  string         `json:"moniker" yaml:"moniker"`
  Name     *string        `json:"name,omitempty" yaml:"name,omitempty"`
  Surname  *string        `json:"surname,omitempty" yaml:"surname,omitempty"`
  Bio      *string        `json:"bio,omitempty" yaml:"bio,omitempty"`
  Pictures *Pictures      `json:"pictures,omitempty" yaml:"pictures,omitempty"`
  Creator  sdk.AccAddress `json:"creator" yaml:"creator"`
}

After a couple of users have created their profile, I've noticed some things particular:

• the Name and Surname are used incorrectly, often filled with fake data in any case;
• the Moniker is the one that truly identifies a user, and most users have set monikers to be their usernames.

I think that we should probably revisit some of the functionalities and checks that we currently have in order to give this object a proper meaning.

Implementation proposal

What I suggest to do is the following.

1. Remove the Name and Surname fields.
   These data will be collected in any case in a middle layer managed by dApps if they want to have it. No sane user will publish his/her name on a blockchain project in any case.

2. Rename the Moniker to be Tag or something similar (proposals accepted).
   This will be used to properly tag (@) people inside posts and/or photo.

3. Add a validation process to the new Tag field.
   I think we should probably take what other social networks (like Instagram, Twitter, etc.) do to make sure tags are valid. This means no white spaces and a short max length allowed (further researches should be done on this point).

Please @kwunyeung and @bragaz let me know what do you think about this.

[leobragaz]

Even if I feel comfortable with the current one I understood your concerns about it.

1. I don't think users who approach dApp like Mooncake will put their true identity in the profile, especially if they come there because they are interested in all the privacy features.
2. I think that tag could be too generic and we could call it UserTag(like Xbox Live does calling gamer usernames Gamertag). Also it could be cool if we can query a user's tag with a case insensitive approach like twitter does. (e.g Both https://twitter.com/leobragaz_ and https://twitter.com/leobragAz_ lead to my twitter profile).
3. I think we should only these check you mentioned, maybe an extra one to avoid special characters?

[kwunyeung]

I agree the Moniker is the value for being used for tagging, like the unique username on other networks. We don't really need Name and Surname as we don't suggest users to give their true identities. The real life example is Christine. Her moniker is Chjango Unchained and her handle on Twitter is @chjango.

I agree with the points @RiccardoM suggested in the proposal. And I also agree @bragaz 's concerns which we better use another term instead of just Tag and the character checking.

To also serve the First join ... on the Mooncake profile,

https://xd.adobe.com/view/078b798a-9afc-407a-67c4-15748a11be5b-71ba/screen/dc311156-0c7e-4a5e-ab38-1ef0768352d2/7-1-settings

we may record the date of the profile creation date. At the end it will not be First join Mooncake since ... but Desmos profile since....

The Tag should be immutable as we are using it to refer the profile. Users can change their usernames on FB, IG and Twitter as they are using another id to identify the users. The Tag can only be created once and can't be changed forever like the validator change_rate and max_change_rate in staking. This helps keeping the data integrity when we have posts being tagged.

What term should we use for the Tag? @mention? or @dag like a Desmos-Tag?

[leobragaz]

Something like DesmosTag should be good I think

[RiccardoM]

I'm ok with @bragaz's observation and renaming Tag into DesmosTag (or even DTag is fine).

@kwunyeung's proposal about tracking the creation can be also achieved by using the ctx.BlockHeader().Time field while handling the message.

I'll take care of implementing these changes.