Decentralized profile

[RiccardoM]

Context

As a social network enabling blockchain, one core feature that we should have is the possibility for users to create their very own decentralized profile.

In the current era of social networks, profile are most of the time made of the following user data:

• Name
• Surname
• Moniker
• Mobile phone
• E-mail address
• Address of residence
• Date of birth
• Sex

Also, a part from these privacy-related stuff, people can often also set

• A profile picture
• A cover picture
• A bio/description

Personally, I would avoid putting any privacy-related information on-chain as this can lead to leak of data and spam/scam actions.

For this reason, I propose to create a profile that contains only the following information:

Field	Constraints
Moniker	Optional, unique
Profile pic	Optional
Cover pic	Optional
Bio	Optional
Name	Optional
Surname	Optional

On the other hand, I would exclude the following data:

• Mobile phone
• E-mail address
• Address of residence
• Date of birth
• Sex

Also, as other social networks already exist, I propose to allow the users to connect such socials to our profile, saving a list of social network connections.

Implementation proposal

Based on the considerations written above, the implementation I propose is defined by the following structures:

// Account represents a generic account on Desmos, containing the information of a single user
type Account struct {
	Name     string       `json:"name,omitempty"`
	Surname  string       `json:"surname,omitempty"`
	Moniker string       `json:"moniker,omitempty"`
	Bio      string       `json:"bio,omitempty"`
	Pictures *Pictures    `json:"pictures,omitempty"`
	Links    []SocialLink `json:"links,omitempty"`
}

// Pictures contains the data of a user profile's related pictures
type Pictures struct {
	Profile string `json:"profile,omitempty"`
	Cover   string `json:"cover,omitempty"`
}

// SocialLink represents a single link to another social network
type SocialLink struct {
	Social string `json:"social"`
	Uri    string `json:"uri"`
}

Social links constraints

As we live in a world where catfishing and identity stealing is increasing over time, I suggest we adopt a series of precautions about other social network connections.

Restricting accepted social networks

I would suggest we create a system inside which we do not accept all social networks to be linked to Desmos but, instead, only a subset of the existing ones. This is due to prevent hardly-verifiable social networks to be linked, which would cause possible identities steals.

The list should be done on-chain and managed thought an on-chain governance. The following actions should be supported:

1. Adding a new social network
2. Removing an existing social network

Specifying the authenticity controls

For each future supported social network, there should be a document defining properly how the authenticity of a connection to such social network can be proven. This document should be approved by the overall community before the social network itself is marked as fully supported on Desmos.

[kwunyeung]

I prefer we use Moniker instead of Nickname to give a sense that users don't need to provide their real life identity.

I don't think we should encourage them to add existing social media. Consider this is an entirely new universe. We may instead ask them to add their keybase, *iov address, etc.

There is another question always in my head. Should we link a single profile to different addresses of a user? Can this profile represent the identity of the same user on Desmos, Cosmos, IRIS, Kava when the user has different addresses on different networks? Or doing it similar to StackExchange? When you register on a new SE site, you can choose to copy the profile from any SE site, for example from StackOverflow. I have this question as I also consider the profile of a validator. Tbh, I found it quite clumsy to edit validator on all networks with the same information, but still there might be a slightly variations on different networks. I would like Desmos profile can encounter this issue. In a sense that when a validator created a validator on a new network, it can specify a Desmos address with the profile. Explorers can read from Desmos Chain to get the profile and know that's from the same validator on different networks. And when a validator wants to have specific description on a network, it can have different description.

@terencesflam do you have any comments on the use cases of user profile?

[RiccardoM]

I prefer we use Moniker instead of Nickname to give a sense that users don't need to provide their real life identity.

Replaced nickname with moniker.

---

I don't think we should encourage them to add existing social media. Consider this is an entirely new universe. We may instead ask them to add their keybase, *iov address, etc.

While proposing this solution I was not thinking about encouraging them to link their socials. Instead, linking such information could be seen as an additional proof of ownership of such accounts.

I avoided using Keybase as you told me there has already been some impersonating there. However, if you think it's better I'm more than willing to delete the social links and replace them with other more specific stuff.

---

There is another question always in my head. Should we link a single profile to different addresses of a user? Can this profile represent the identity of the same user on Desmos, Cosmos, IRIS, Kava when the user has different addresses on different networks?

I think this will be solved using the IBC accounts which will provide a chain to retain control of an account while making it available for use to other chains too.

If not using this, we can simply add a new field called accounts and specify the steps that needs to be done from the user side to confirm such address.

---

Tbh, I found it quite clumsy to edit validator on all networks with the same information, but still there might be a slightly variations on different networks. I would like Desmos profile can encounter this issue. In a sense that when a validator created a validator on a new network, it can specify a Desmos address with the profile. Explorers can read from Desmos Chain to get the profile and know that's from the same validator on different networks. And when a validator wants to have specific description on a network, it can have different description.

This can be done from explorers and other chains. I don't think it's strictly related to us as we cannot change how other chains work.

[kwunyeung]

I think this will be solved using the IBC accounts which will provide a chain to retain control of an account while making it available for use to other chains too.

Yes, seems the IBC Accounts is the solution. Let's keep an eye on this and see how this can be implement on Desmos.

This can be done from explorers and other chains. I don't think it's strictly related to us as we cannot change how other chains work.

With the decentralized profile, explorers and other dapps can choose to get the profile or setup their own structure. For validators, they can use the Bio field as suggested here. User may store a json in the Bio field and let the explorers read them.

[RiccardoM]

Second implementation proposal

After all the above discussion and having studied how IBC connects the chains between one another, I've thought to what it might be a better implementation.

Types

The Account type should be changed thinking about the following things:

1. As @kwunyeung said, we should not consider connecting to existing social networks. Instead, this should be a brand new start.
2. We should allow multiple chain accounts to be linked to a single profile, to better increment the verification.
3. We should allow for external services to be linked to further improve the verification level.

In order to satisfy these requests, I've thought about the following Account type:

// Account represents a generic account on Desmos, containing the information of a single user
type Account struct {
    Name             string        `json:"name,omitempty"`
    Surname          string        `json:"surname,omitempty"`
    Moniker          string        `json:"moniker,omitempty"`
    Bio              string        `json:"bio,omitempty"`
    Pictures         *Pictures     `json:"pictures,omitempty"`
    VerifiedServices []ServiceLink `json:"verified_services,omitempty"`  // List of all the trusted services linked to this profile
    ChainLinks       []ChainLink   `json:"chain_links,omitempty"`  // List of all the other chain accounts linked to this profile
}

// Pictures contains the data of a user profile's related pictures
type Pictures struct {
    Profile string `json:"profile,omitempty"`
    Cover   string `json:"cover,omitempty"`
}

// ServiceLink represents the data that have been used to connect a verifiable trusted service 
type ServiceLink struct {
    Name       string `json:"service_name"`  // Name of the trusted service (e.g. keybase) 
    Credential string `json"service_credential"`  // Credential to be used to verify the user (eg. the Keybase identity)
    Proof      string `json:"service_proof"`  // Proof to verify the user (e.g. the 
}

// ChainLink represents the data that have been used to prove an external chain account is owned by this user
type ChainLink struct { 
    Name   string `json:"chain_name"`  // Name of the chain on which the tx has been performed (eg. cosmoshub-3)
    TxHash string `json:"tx_hash"`  // Hex representation of the tx hash used to verify the ownership
}

Services and Chains listing

In order to properly support services and chain verification, we should also store on-chain a list of services and chains that we recognize as valid and for which we define a proper verification procedure. Such procedures will be used inside CLI commands execution.

CLI commands

The following CLI commands should be implemented:

Add a service.

By specifying the name of a supported service and the proper credential and proof, the CLI commands performs the actions needed to execute the verification properly.

For example, the following procedure might be adopted to verify Keybase:

1. The user specifies:
   • a message encrypted with the Keybase private key
   • the public key id associated to the Keybase account
2. We fetch the data of the keys associated with the specified account.
   This can be done using the Keybase key/fetch API
3. We decode the message encrypted with the private key using the public keys.

If the decoding works, we can make sure the user controls that account and so we can safely store it on chain.

Add a chain

To make things easier, we can initially support only Cosmos-based chains. Once IBC is out, we can swap the implementation to use that instead.

A possible procedure for this would be the following:

1. The user specifies the chain name and the transaction hash.
2. We lookup to get the previously registered LCD endpoint that needs to be used to connect to the specified chain.
3. We use the /txs endpoint to fetch the specified transaction.
4. We verify that the transaction has been signed using the public key associated with user's Desmos account.
5. We verify the content of the transaction to make sure it matched the requirements.

If the verification is successful, we store the chain as a verified chain inside the user's profile, saving the transaction hash.

Conclusions

This is just an example implementation that we might want to have as the first version of integration towards third party services. Please @kwunyeung and @bragaz let me know what do you think about this.

[leobragaz]

Seems good to me.
I've got some doubts about the verifications of service and chain:
Will these verifications be made off-chain? Do we need another layer for them or we can just perform them inside the CLI commands?

[RiccardoM]

@bragaz the verifications can all be made off-chain, without the need of a middle layer application, simply using Go's HTTP client.

[RiccardoM]

Superseded by #192