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

[UX] Account ownership verification process consolidation [draft] #23

Closed
neruthes opened this issue Apr 22, 2019 · 5 comments
Closed

[UX] Account ownership verification process consolidation [draft] #23

neruthes opened this issue Apr 22, 2019 · 5 comments
Assignees

Comments

@neruthes
Copy link
Contributor

neruthes commented Apr 22, 2019

Background

It can be hard to ensure that the automatic verification posting mechanism can work, so we need some saturation measures to ensure that the public key is posted, in bio or in post.

Some basic change on setup

Screen Shot 2019-04-24 at 12 09 59

Screen Shot 2019-04-22 at 06 27 43

Measure 1: Just-in-time Self-checking

As soon as the setup is completed (proof(s) automatically added), the extension shall immediately check if the proof is really added to bio and really posted on timeline. If no proof is online, the user will receive alert message like "automatic proof failed, please add manually", and will be guided to post the public key.

Error handling: User bio may have no enough space for the public key. This will lead to failure of bio update and the other method of proof is the only possible way. In the best case, we can detect the available space in user bio so we can ban the option when it is not possible.

Measure 2: Continued Self-checking

The extension shall periodically check the proofs of claimed accounts of the user to see if they are validly connected.

If the proof is no longer available, the user will receive alert message like "proof broken, please re-add". This alert should appear only when the user is logged in as the Facebook account.

@neruthes neruthes self-assigned this Apr 22, 2019
@yisiliu
Copy link
Member

yisiliu commented Apr 22, 2019

  1. Editable after posting? What's the point of creating such a post instead of adding to some random database if the proof post is not considered the "PROOF POST" that can be accessed for future reference?

  2. If the user chooses both, how do you guide them? We have two different payloads for two methods. How do you solve this?

----- My suggestion:
Instead of insisting on your saturation family, we should stay the same options for posting the public proof for users to choose. Make this process an easy and concise one.

@neruthes
Copy link
Contributor Author

  1. What "editable"?
  2. The user can choose both when and only when the user is at Automatic Mode. If the user chooses Manual Mode, the user will be directed to bio. (Why prioritize bio? Because it is more efficient than proof post.)

@neruthes
Copy link
Contributor Author

I see. The "editable" appeared in the second option box in Automatic Mode.

I may adjust the wording.

@yisiliu
Copy link
Member

yisiliu commented Apr 22, 2019

  1. The user can choose both when and only when the user is at Automatic Mode. If the user chooses Manual Mode, the user will be directed to bio. (Why prioritize bio? Because it is more efficient than proof post.)

Automatic mode may not be accepted by users since it will create a post without the user's permission

@neruthes neruthes changed the title [UX] Account ownership verification with saturation measures [draft] [UX] Account ownership verification process consolidation [draft] Apr 24, 2019
@yisiliu
Copy link
Member

yisiliu commented Apr 24, 2019

👍Let's keep this design for now

@yisiliu yisiliu mentioned this issue Apr 25, 2019
1 task
lucasespinosa28 pushed a commit to lucasespinosa28/Maskbook that referenced this issue Dec 13, 2021
amritkumarj pushed a commit to amritkumarj/Maskbook that referenced this issue Feb 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants