-
Notifications
You must be signed in to change notification settings - Fork 48
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
Implement expiration data for application links #516
Comments
The implementation looks good for me but I was actually wondering if it can be done by:
I'm thinking this because maybe it become tedious to let the re-link the apps when they expires. |
@bragaz The problems does not sussist with DTag transfers. An application is linked to a profile using the address, not the DTag. This means that DTag can change whenever they want and application links will still be valid for the linked profiles since they are verified by signing something with the profile private key. The idea of expiring application links is to solve the current situation:
In this case, the link should expire at some time so that she is required to verify again and does not keep having associated to her profile a Twitter account that she used to own and she does not own anymore. |
Oh then I misunderstood at the start, I was thinking about the |
Just I have a question. After centralized applications username is switched and sold, the user can send a tx to unlink the By your proposal, Desmos should check all app-links in the |
This isn't enough cause we can't rely on users to perform these kind of actions. They might simply forget to do it or stop using Desmos before changing their application username. This would cause Desmos to expose a way users can use to impersonate other people.
You are right, it might become too expensive. Thanks to your idea of adding a field, I have thought about another implementation. Instead of using a time (which is hard to deal with inside our chain), what we can do is set a validity time in blocks. This way when a link gets created we can store a new entry that is something like
This way, inside the
This should be very efficient by iterating and editing only the links that are supposed to be changed. what do you think? |
There is an issue that the There is a way to solve the problem, building a key manager for application link, like: struct ApplicationLinkKeyManager type{
UserApplicationLinkKey []byte
ApplicationLinkClientIDKey []byte
ApplicationExpirationKey []byte
} Within this solution, all the key can be deleted and created easily by manager, so does the application expiration key. The other way is to add expiration block height into ApplicationLink, it is much easier than the above proposal. I would go with it first. (7/16 Upadated) What do you think? @RiccardoM @bragaz |
## Description This PR introduce the draft of the 4th ADR related to Expiration time of application links. Discussed before here: #516. ### Author Checklist *All items are required. Please add a note to the item if the item is not applicable and please add links to any relevant follow up issues.* I have... - [x] included the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title - [ ] added `!` to the type prefix if API or client breaking change - [x] targeted the correct branch (see [PR Targeting](https://github.com/desmos-labs/desmos/blob/master/CONTRIBUTING.md#pr-targeting)) - [x] provided a link to the relevant issue or specification - [ ] followed the guidelines for [building modules](https://docs.cosmos.network/v0.44/building-modules/intro.html) - [ ] included the necessary unit and integration [tests](https://github.com/desmos-labs/desmos/blob/master/CONTRIBUTING.md#testing) - [ ] added a changelog entry to `CHANGELOG.md` - [ ] included comments for [documenting Go code](https://blog.golang.org/godoc) - [ ] updated the relevant documentation or specification - [ ] reviewed "Files changed" and left comments if necessary - [x] confirmed all CI checks have passed ### Reviewers Checklist *All items are required. Please add a note if the item is not applicable and please add your handle next to the items reviewed if you only reviewed selected items.* I have... - [ ] confirmed the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title - [ ] confirmed `!` in the type prefix if API or client breaking change - [ ] confirmed all author checklist items have been addressed - [ ] reviewed state machine logic - [ ] reviewed API design and naming - [ ] reviewed documentation is accurate - [ ] reviewed tests and test coverage - [ ] manually tested (if applicable)
Feature description
Currently when a user links their centralized application with the Desmos profile, the created link contains a timestamp of when it has been created. Since centralized applications username can be switched and sold, we should implement a sort of "expiration date" on links. This means that after a certain amount of time passes, the link will be automatically marked as invalid, and the user has to connect it again in order to keep it valid.
Implementation proposal
The implementation should be very simple. What we can do is:
x/profiles
parameters set, identifying how long a link should be considered valid from when it has been created.EndBlocker
, check for links that are expired and update their state to set them as such.Please @bragaz @dadamu tell me if you see any problem with this implementation or better alternatives.
The text was updated successfully, but these errors were encountered: