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

Automatically restore all IDs on restore #1550

Open
jeffdomke opened this issue Jul 23, 2018 · 12 comments

Comments

@jeffdomke
Copy link
Member

commented Jul 23, 2018

No description provided.

@jeffdomke jeffdomke created this issue from a note in 0.31 (To do) Jul 23, 2018

@wbobeirne

This comment has been minimized.

Copy link
Contributor

commented Jul 25, 2018

Relevant forum discussion: https://forum.blockstack.org/t/proposal-auto-fetch-ids-with-activity/5658

I think this task me be too large to fit into this sprint, and I don't think the forum solution addresses the main issue that most users will run into, which is that their ID doesn't resolve while it's still processing.

@larrysalibra

This comment has been minimized.

Copy link
Member

commented Jul 26, 2018

Really excited about this - it's been a long time coming for legacy/power users.

@jeffdomke jeffdomke moved this from To do to In progress in 0.31 Jul 30, 2018

@jeffdomke jeffdomke moved this from In progress to To do in 0.31 Jul 30, 2018

@wbobeirne

This comment has been minimized.

Copy link
Contributor

commented Jul 30, 2018

This issue is somewhat blocked by #1496 due to moving related functionality into blockstack.js

@larrysalibra

This comment has been minimized.

Copy link
Member

commented Jul 30, 2018

Also depends on
blockstack/blockstack.js#433 in blockstack.js

@jeffdomke jeffdomke added this to To do in 0.32 Jul 30, 2018

@wbobeirne wbobeirne changed the title Automatically restore IDs on restore – post solution in forum and decide on path fwd. Automatically restore all IDs on restore Aug 3, 2018

@MichaelFedora

This comment has been minimized.

Copy link

commented Aug 3, 2018

Why does it have to be a complicated "activity" to solve this issue, when a short term solution could be made by just storing the number of ids to generate in the profile.json? The larger solution is cool but if it's being blocked by so many other issues and keeps getting pushed back then why not do something smaller for now and implement the rest later?

If it's a privacy issue (with putting the number in the profile.json) then just encrypt it with the bip39 mnemonic & AES or the encrypt() function you have in the library (though, preferably with AES-192 to be more compatible with 3rd party browsers).

@larrysalibra

This comment has been minimized.

Copy link
Member

commented Aug 4, 2018

Introducing more state in the system doesn’t help anyone that already has multiple ids & is a bigger change than automatically searching.

We’re blocked by these other issues because we want the functionality in a library so that other developers can use it and not in the browser where it doesn’t belong.

“Temporary” solutions have a tendency to become permanent and expensive to change as other people start to rely on the temporary solution.

@wbobeirne

This comment has been minimized.

Copy link
Contributor

commented Aug 6, 2018

#1577 is a short term triage of this issue to make it more clear to users how to recover additional IDs.

@zone117x

This comment has been minimized.

Copy link
Member

commented Apr 19, 2019

The current UX for multiple IDs is still poor. I read through the linked issues and forum posts, and I'm not really understanding the problem with just restoring all names/identities on account restoration.

Perhaps with a limit of around 10-20 due to how slow our crypto appears to be when restoring (haven't debugged / profiled completely yet, idk if this would actually be a problem or not).

If a user creates an ID they no longer want, let's say at the second index (identity number 2), and has a few identities that they do want after the second index, then they still have to deal with that unwanted ID with the current UX when doing the manual "add new ID" weird UX that restores one at a time. So we wouldn't really be making this issue worse.

Also, it seems easy to add an x/remove button on the ID list page, which would tell the browser to no longer present that ID. The prompt would be something like "Remove this identity so that it no longer appears?".

@larrysalibra

This comment has been minimized.

Copy link
Member

commented Apr 19, 2019

I don’t see any problem with automatically restoring - it just never got done.

Another approach to unwanted IDs could be to hide IDs that don’t have names associated with them.

If the user wants to delete the ID they’d have to revoke the name. (Send a revoke transaction)

@zone117x

This comment has been minimized.

Copy link
Member

commented Apr 19, 2019

We should just get it done then. I didn't know about revoke transactions. That makes it even easier.

@moxiegirl

This comment has been minimized.

Copy link
Contributor

commented Apr 22, 2019

Is this button actually destroying the IDs or is it simply hiding them? I wasn't aware they could be removed. If they are being hidden the button should be Hide and we would need a Reveal Hidden IDs UX in case people had some question against these IDs.

@larrysalibra

This comment has been minimized.

Copy link
Member

commented Apr 23, 2019

@moxiegirl

IDs can be revoked on the blockchain level by sending a revocation transaction. There's no mechanism for doing this in the current browser. It would cost money to send such a transaction. I'm not sure how (if?) revocation works for subdomains. cc @kantai

They can also potentially be hidden at the browser level:

If they are being hidden the button should be Hide and we would need a Reveal Hidden IDs UX in case people had some question against these IDs.

+1 to this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
7 participants
You can’t perform that action at this time.