Allow users to change their DTag

[RiccardoM]

Feature description

Currently after a user has registered a profile, the DTag value will be de-facto immutable, forcing him to build a whole new profile if he wants to change.

Since the only constriction about DTags is that they should be unique, and they should be used when tagging a user as a human-readable references to the tagged person, I think we can safely allow any user to change his DTag at any time.

Implementation proposal

To implement this feature, I think it's sufficient to change the checks inside the HandleMsgSaveProfile, by removing* the condition that checks whether the provided DTag inside the message is equals to the exiting one.

Thanks to this change, and the fact that we already have in place a check to make sure that the provided DTag is not already associated to another user, the trick should be done.

Clients tagging consideration

About tagging, I think that the clients should not rely on the DTag values when tagging users. Instead, they should always replace the DTag with the user Address value to make sure it never changes in the future.

So, suppose the user writes the following post inside the client:

Hello @desmos!

This should be translated from the client into:

Hello @[desmos1...]

Then, when rendered, the [desmos1...] part should be replaced with the user tag, allowing to click on it properly.

What do you guys think @kwunyeung @bragaz?

[kwunyeung]

@RiccardoM for "client" do you mean like Mooncake has to do the DTag <> Address conversion before broadcasting the message and convert it back when displaying the content? I think this way will generate a lot of unpredictable data inconsistency.

Can this be done by converting the DTag to Address in NewMsgCreatePost and return a correct value with addresses before handling the message and then convert the Address back to DTag in querier? Then the client will always read the correct DTag. Will this create a lot of overhead if possible?

[RiccardoM]

About tagging

@RiccardoM for "client" do you mean like Mooncake has to do the DTag <> Address conversion before broadcasting the message and convert it back when displaying the content?

Exactly

Can this be done by converting the DTag to Address in NewMsgCreatePost and return a correct value with addresses before handling the message and then convert the Address back to DTag in querier?

As far as I can see, there are a couple of problems with this approach:

1. NewMsgCreatePost defined inside the chain code, is never called from the client. Clients should define their way of creating messages, signing them and then broadcasting them.
2. Even if 1 was possible, it would mean that either:
   1. we have a middle-man service that performs the conversion;
   2. we store inside the chain a data different from what the user has specified inside the message (DTag -> Address)
3. In any case, if the DTag of a user would change, we would have to search through all the references inside posts and replace that DTag with the new one. Such replacement could also break the posts limit (if the post was 300 chars long with a DTag of 10 chars and the user changes using a DTag of length 11).

Then the client will always read the correct DTag.

Suppose we solve all the above mentioned problems, this is also not true.
Since we parse the chain data using DJuno and store them inside a PostgreSQL database, we do not read the data from the chain. This means that the conversion logic should also be implemented either inside the implementation of the GraphQL layer, or at the client level.

As a reference, this is what Twitter returns for a Tweet:

{
  "created_at": "Mon Jul 13 12:33:39 +0000 2020",
  "id_str": "1282654421466468358",
  "full_text": "@SlackHQ is the [at]here mention disabled by any chance? It's not working properly right now",
  "display_text_range": [
    0,
    92
  ],
  "entities": {
    "user_mentions": [
      {
        "screen_name": "SlackHQ",
        "name": "Slack",
        "id_str": "1305940272",
        "indices": [
          0,
          8
        ]
      }
    ]
  },
  "source": "<a href=\"https://mobile.twitter.com\" rel=\"nofollow\">Twitter Web App</a>",
  "in_reply_to_user_id_str": "1305940272",
  "in_reply_to_screen_name": "SlackHQ",
  "user_id_str": "347727501",
  "retweet_count": 0,
  "favorite_count": 0,
  "reply_count": 1,
  "quote_count": 0,
  "conversation_id_str": "1282654421466468358",
  "lang": "en"
}

They return the plain text, but also they use the entities.user_mentions array to define the start and end indices of all the tags, as well as the related user.

I personally think that we can go with another approach, which would be:

1. the user inputs the message inside the dApp as it would on Twitter (using the @tag notation);
2. when creating the MsgSavePost instance, the dApp converts that @tag notation into @[address];
3. when DJuno parses the posts, it extracts all the @[address] notations, and converts that into a structure which is similar to the one used by Twitter, with the plain text message and an array of mentions.

This way we:

1. require the client to only perform one conversion when creating the message (DTag -> Address);
2. do not use the DTag inside the message body, so that if the user changes it the chain will do not have to perform additional tasks;
3. perform the Address -> DTag conversion on a middle main layer (Djuno) so that it will always return the last DTag used by any user.