(epic) User verification

[XertroV]

We need a way to verify users sometime soon.
We can do this via an oauth connection to the Flux backend.
We can send stuff like whether their details are valid (and when they were validated last) via oauth scopes.

This thread is for talking about the practicality / implementation / go-ahead-status of this idea.

Implementations required:

• Add oauth2 resource provider to Flux backend
• Add a client app (digipol) to dev and prod backends
• Add oauth2 handshake stuff to digipol app

[KipCrossing]

@XertroV very epic

I suppose there are a few things to consider regarding verification.

If we are doing it via the flux backend, I assume it will be limited to flux party members. Obviously membership is free and therefore this will be a good hook to get more members. The alternative is to allow verification for anyone on the electoral roll.

Under the assumption of flux party members only:

The app should still be able to be used by non-flux party members (non-verified users), but with limits. The question is, what should those limits be?

1. Non-verified users simply can't vote.
   "you need to verify with your flux details" - This would be easy to implement client-side and become a good hook to get more members.
2. Non-verified users can vote, but their votes won't be counted off the blockchain.
   This will allow more user participation and their votes can be counted at a later date after verification. May require updates to the smart contract though @voteflux/devs_solidity.

[BenBallingall]

I think this is number one most important discussion to have. Verification/electorate results are the rocket fuel in this DigiPol space journey.

While I know DigiPol having a direct positive correlation for Flux is, really, the whole point of launching this app - but I'm really, really against requiring people to be a Flux member to use DigiPol.
It's just... Not the members we want, and we don't people begrudgingly joining.

Especially in States where we haven't registered a branch yet and want clean member lists.
But, I mean - if we put them through Flux database as DigiPol users and that ends up an email list, well that's just good business 🤩

So in summary, as long as they're not forced to be members - I think option number 2 above. You get given a private key anyway currently, your vote will just be in a "non-verified" boo hiss results list... And everytime you vote unverified you get an annoying pop up box asking if you want to register 😁

[XertroV]

If we are doing it via the flux backend, I assume it will be limited to flux party members.

I'm really, really against requiring people to be a Flux member to use DigiPol.

That's not a requirement / limit. Some implementation is required, but it's less-than/equal to doing it from scratch. Plus Flux already has a deployed API so it can keep costs lower (which are about $300 a month atm between Flux and DigiPol).

I think we've talked about this multiple times on discord before.

The app should still be able to be used by non-flux party members (non-verified users)

Keep in mind some members don't have verified details.

But, I mean - if we put them through Flux database as DigiPol users and that ends up an email list, well that's just good business 🤩

We shouldn't do any of this by default, but we can have a simple "become a member" one-click button thing.

Non-verified users can vote, but their votes won't be counted off the blockchain.
This will allow more user participation and their votes can be counted at a later date after verification. May require updates to the smart contract though @voteflux/devs_solidity.

I think the right way to handle multiple groups of ppl is to have multiple jurisdictions. WRT to updating the chain-code, the more time we sink into improving the basic one we have the more we replicate what already exists in SV-Light (which can do most of this already, or has much lower implementation overhead if you consider the benefits of the other stuff we get for free)

[BenBallingall]

• Use Flux API for electorate verification
• any user, new or Flux, with unverified details gets pushed through the same "verify your details to unlock electorates/personalise" in DigiPol (win-win)
• unverified vote in a seperate pool only related to total vote (default hidden for verified users, option in the app settings to "show/hide unverified voter results")
• unverified can't comment (greyed out), can still share

That's my thoughts how it would/could work. I think.

[XertroV]

Use Flux API for electorate verification

Roughly. More specifically it's approx extending the flux membership app+backend to:

1. support non-members (relatively easy)
2. support oauth
3. support making making claims via oauth about validity of electoral details

any user, new or Flux, with unverified details gets pushed through the same "verify your details to unlock electorates/personalise" in DigiPol (win-win)

DigiPol doesn't need users in the normal sense here, it just needs to use oauth login via Flux. It's similar to the "do you want this app to: *) know your name *) know your email *) know the status of your electoral roll details".

So we separate the processes of:

• registration (flux members already good, other ppl use new signup form)
• verification (via existing methods)
• attestation (via oauth2)

then the digipol backend:

• get's an auth token + refresh token for the user (which allows the digipol backend to get the electoral roll status + refresh this status)
• stores that in a secure DB (note: the flux API oauth stuff works via lambdas + DDB so we can use that do most of the boring stuff and then just patch it to do what digipol needs)
• just manages oauth->validity->authorize user voting address
• once every ~3mo -> prompt user to re-validate details -> digipol backend renews "certificate" for voter addr

unverified vote in a seperate pool only related to total vote (default hidden for verified users, option in the app settings to "show/hide unverified voter results")

We're only considering verified users in this. Unverified stuff doesn't mean anything.

Maybe it's a bit interesting to separate flux/non-flux votes, but that reduces privacy and I'm not sure there's that good a reason for it.

unverified can't comment (greyed out), can still share

This is fine, but I think it's important we still allow for anon posting (like the flux QAndA app does)

[KipCrossing]

Related content: https://youtu.be/0Os1OAL4acE

[KipCrossing]

Haven't worked with oauth2 before. @XertroV does this library look like the go?