Automatically restore all IDs on restore

[stackatron]

No description provided.

[wbobeirne]

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]

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

[wbobeirne]

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

[larrysalibra]

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

[MichaelFedora]

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]

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]

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

[zone117x]

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]

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]

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

[moxiegirl]

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]

@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