Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change how relationships are represented #266

Closed
RiccardoM opened this issue Sep 1, 2020 · 4 comments · Fixed by #269
Closed

Change how relationships are represented #266

RiccardoM opened this issue Sep 1, 2020 · 4 comments · Fixed by #269
Assignees
Labels
kind/enhancement Enhance an already existing feature; no "New feature" to add
Milestone

Comments

@RiccardoM
Copy link
Contributor

Context

With #168 we've introduced user relationships as a simple sdk.AccAddress -> []sdk.AccAddress map. This was done in order to allow applications to handle their relationship however they wanted on their level.

With the current system the following is possible:

  1. A relationship between Alice and Bob is created on Mooncake.
  2. Another application comes in place and uses the same relationship.
  3. Mooncake decides to delete the relationship.
  4. The relationship is deleted from the other application as well.

The blockchain should represent the data storage. Since Desmos is a protocol, applications should not see the data they use changed if they don't want to.

Solution

To fix this error, I think that we should revisit the relationship definition in order to include the subspace of the application for which the relationship is being created as well:

type Relationship struct { 
  Recipient sdk.AccAddress `json:"recipient" yaml:"recipient"`
  Subspace  string         `json:"subspace" yaml:"subspace"`
} 

Then, the storage can be a simple sdk.AccAddress -> []Relationship.

@RiccardoM RiccardoM added this to the v0.12.0 milestone Sep 1, 2020
@RiccardoM RiccardoM added kind/enhancement Enhance an already existing feature; no "New feature" to add module/relationships labels Sep 1, 2020
@kwunyeung
Copy link
Contributor

I guess we could open an opportunity for users to decide whether they would like to add the same relationship when they open another dapp. This could be done on the dapp level. For a more dapp-scope environment, CosmWASM provides a contract scope state. We may consider adapting it.

@RiccardoM
Copy link
Contributor Author

@kwunyeung

I guess we could open an opportunity for users to decide whether they would like to add the same relationship when they open another dapp

This can be done even better by tracking the subspace of the other relationships. The user could decide to add all of its relationships coming from Facebook but not from Twitter.

For a more dapp-scope environment, CosmWASM provides a contract scope state. We may consider adapting it.

I don't see in which cases this might be useful to us, could you please elaborate on how smart contracts might be interesting for this feature?

@leobragaz
Copy link
Contributor

I originally suggested to add a subspace field here so I'm totally fine in doing so. I will adapt this after I've finished the user blocking feature.
I'm also curious on how we can handle scope with WASM.

@kwunyeung
Copy link
Contributor

AFAIK, CosmWASM provide a contract-scope state. For example, if the relationship of Mooncake is controlled by the Mooncake contract, then there is a state which can only be accessible by the contract itself. In this particular case, it's just the same as storing subspace as we only need to differentiate the relationship for a particular dapp. I think smart contract will be more interesting when the are some dapp specific features which can be done on-chain but not provided in protocol level.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement Enhance an already existing feature; no "New feature" to add
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants