"Official Accounts" mechanism like Twitter of Facebook

[wens]

No description provided.

[chhsiao1981]

Like captcha, it's possible that we can utilize oauth2 mechanism to get the information from Google / FB.

In the "validating-account" flow, we instruct the users to paste the link to the browser for oauth2.

We can put the corresponding email and full name (if available) back to the storage when we receive the results from oauth2 and the account is considered as a valid account.

[wens]

You completely misunderstood. I'm talking about the "blue checkmark" on Twitter or "Official fanpage" on Facebook.

I have no intention of adding Oauth.

[chhsiao1981]

In this case, we can discuss:

1. The emails / information that can be by default considered as "Official Accounts" (ex: emails from official-schoolwise-edu accounts (not labwise-edu or other non-official-schoolwise-edu) may be considered as "Official Accounts")

2. Submissions of images identifiable to a person (ex: from web-cam and from id-card)

3. Does that imply we will remove the original manual account-verification mechanism, and the ones with "Official Accounts" will socially/psychologically get more credits from the users?

4. We may not be able to prevent fake-accounts and unable to prevent account-exploding. It's possible that millions of "non-Official Accounts" trying to occupy the connections. We may need some mechanism to deal with this situation.

[wens]

That is a policy thing and is not relevant to what we're doing here on GitHub.
I am simply adding an option for highlighting such a status for accounts.
How the account people want to do verification is their problem.
If you have suggestions you can take it up with them. I doubt your first 3 points apply.
In the last case, I highly doubt that would ever happen. Login rates have been dropping consistently.
We can deal with it if and when it happens. No need to worry about hypotheticals.

[chhsiao1981]

Then what I would like to discuss is:

1. For the 1st-version of the UI, what's the default policy?
2. What are the possible extensions that we would like to implement in the 1st-version？～

We may incorporate the following policies in the 1st-version of the implementation:

1. All SystemAdmins are with "Official Account"
2. We implement validating the email-accounts with whitelist from a file in this repo (or some storage).
   For the 1st-version, we include all the official-schoolwise accounts from edu (ex: @ntu.edu.tw), and we include as many official-deptwise accounts (ex: @csie.ntu.edu.tw) as possible.
   We welcome PRs to add to the whitelist if other legal entities are interested in putting their email-accounts in the whitelist as well.

[wens]

Just so we're on the same page so, this feature is NOT for people that simply pass the basic account verification, whatever mechanism used. So your comment simply doesn't apply.

I imagine the policy for "official accounts" would be verification by hand.
Probably only used for official government business.

And again, policy making is NOT what we're doing here on GitHub.
If you have suggestions about policy on Ptt, go onto Ptt and visit the PttSuggest board.

[PichuChen]

Hello there,

I want to make sure, what info we should store.

First, we should store a flag to make some account has check sign✔

Second, I think we need a timestamp, note, operator field to record who certificate this account.

Thanks~

===
我想確認一下需要存哪些東西，應該至少會有一個Flag來確定他有沒有勾勾，然後我可以想到的還有三個欄位 時戳 註記 操作人員 來記錄誰認證這個帳號的。

[wens]

At this point I'm not sure there's much need for this feature.