zulip supports LDAP

same issue as #31 ? separate?

reported by @otomplodomo and @nutzipper

See also #25

@jimscarver and co proposed a timeline Apr 7 (cfdfb3c), revised Jun 10 (7b48c20)

updated timeline is below in #26 (comment)

earlier
I'm not aware that anyone has agreed to do the work to deliver by then, so I'm taking this out of the readme on the main / master branch.

I suggest using github milestones to negotiate due dates between customers and developers.

it's kinda the obvious name. I find very little competition for this name; we'd come out on top of web searches right away.

I propose renaming this repo.

We could get more creative and use some name suggestive of honeybee democracy... rhive ... but that gets kinda obscure.

#60 (comment)

I don't (yet?) see a way through these constraints:

• each member should get at most one vote; no double-voting
• a member wants to vote without disclosing their choice to other members
• a member wants to vote without disclosing their choice to the coop secretary
• the coop secretary should not disclose membership email addresses to other members
• losing a private key should not result in loss of membership voting rights

I have read some articles that do seem to meet many of these constraints, but they seem to involve elaborate use of elliptic curve cryptography; in particular, they start with the voters having key pairs, not just email addresses.

This is an approach to one-member-one-vote #31 : an on-chain inbox where a "capability to vote" can be sent.

• write / insert cap goes insertArbitrary in the registry
• read cap goes @ deployerId
• if that key is compromised, ask secretary to revoke it and issue another
• if that key is lost
  • K-of-N voting to replace

a la

All you need to know about uPort Identity management

#60 (comment)

tabs for use in demo today... saving before upgrading my browser... tabcopy FTW

Ballot Experiment - RChain: https://rv2020-m3.netlify.app/ballot.html
local valiator dev tools (with registry support) · Issue #17 · rchain-community/liquid-democracy: rchain-community/rgov#17
rchain-community/rchain-docker-shard: RChain network on a local machine: https://github.com/rchain-community/rchain-docker-shard
tallying votes - members, secretary, board · Issue #35 · rchain-community/rv2020: #35
RChain web: https://tgrospic.github.io/rnode-client-js/
FastAPI - Swagger UI: http://kc-strip.madmode.com:7070/docs
rnode-client-js/ballot.js at ballot-ui · rchain-community/rnode-client-js: https://github.com/rchain-community/rnode-client-js/blob/ballot-ui/src/web/ballot.js#L240-L271

@leithaus suggests this is straightforward to support and notes there was such a question in last year's ballot (from @steverosstalbot ).

In the demo I gave in early June, RChain was mirroring traffic on a zulip that was only on my desktop. Nobody else could log in. So not much governance was going on :)

update: zulip is running at https://zulip.rchain-dev.tk/ with github auth, but we're requiring Zulip invitations for now. The mirror is not yet reliable due to a number of issues (#42, #44, #45, ...).

@leithaus would prefer not to use metamask; is comfortable giving a private key to software he can audit.

@dckc sees too much UX risk to take on the coding

custom deploy with @tgrospic 's tool remains an option

The board decides on the ballot of questions and the secretary sends them to the membership:

his or her vote will be counted only if (a) it is submitted on the form of ballot furnished by the Secretary for use in connection with the meeting
-- II 6. Voting

How would this work via zulip or the other methods?

How do members vote?

Related: how should members collaborate on proposing items of business?

• initial prototype
• a9b5607 * explicit oppose (aka withold); no / abstain / yes in columns
• add explicit abstain rev addresses
  • vote for abstain on each ballot option by default
• document how to make the agenda #94

(tally related checkboxes moved to #35 )

I'm trying to use es6 modules and no build step - just ship them straight to the browser.

I thought I had a conflict with grpc-web, which hasn't made the jump from commonjs grpc/grpc-web#535

But @tgrospic clarified that I don't need to use gRPC. Just protobuf for signing deploys.

Meanwhile, elliptic and blakejs are commonjs.

snowpack will almost make up the difference, but commonjs modules only export a default, and @tgrospic/rnode-grpc-js does import { ec } from 'elliptic'. Snowpack has a namedExports work-around, but it's only working in snowpack dev mode, not snowpack build mode.

I think I can avoid importing @tgrospic/rnode-grpc-js...

See also: tgrospic/rnode-grpc-js#8

cc @TheoXD

The ballot and registered voters set uri's are not constant. We need an way to specify them when deploying a particular ballot for a particular purpose.

Last Saturday @OPNO suggested a multi-page UI. I said sure, some slides to look at would be great. I suggested playing "calendar bingo" and as I was leaving I heard "let's work on it right now."

The next I hear is today... I hear from @jimscarver that not much happened in that session. Subsequently he and @SteveHenley got together and tried at the HTML level. They had some build issues.

@TheoXD and I are not convinced that a multi-page UI is likely to be easier to use, but I encourage exploration.

I'm disappointed that build issues got in the way of what was expected to be slideware.

earlier we noted that the list should not go out until voting is closed, else people can do tallying while voting is open
#35 (comment)

@jimscarver points out a risk that a registered voter will mistakenly pick the wrong address and that the voting tool could prevent this if the list of registered REV addresses went on chain earlier.

Now that we have two implementations with no known critical problems, let's separate the remaining QA from issue #35 so that we can land #101 .

progress:
423e269
dde055d

@leithaus says exercise of coop membership is going to be conditioned on associating a REV address with each membership.

Connecting this with zulip accounts should help with one-member-one-vote.

For example, @jimscarver suggested we could somehow use metamask to sign something for authentication.

nifty idea by @TheoXD

The secretary counts the votes (section II. 6 Voting) and majority rule etc. determines the outcome of each question.

How does this work? On chain in rholang? Off-chain? Is there a process for amendment?

How are the results communicated to the membership? Is there a process for appeal?

• index transactions
  • given a ballot, find all transactions to the addresses it contains
    • write transaction set to JSON file for use in various implementations #101
    • send transaction set to RChain for use in rholang implementation postponed as #105
• initial prototype bash script
  • handle list of voters in bash
  • limit timestamp for valid votes in bash
• multiple implementations: port to js / py / sql
  • handle list of voters in sql
  • limit timestamp for valid votes - partly done; for follow-up, see rchain#8
• port to rholang postponed as #105
• handle change from yes/no to abstain
• tally only the most recent yes/no/abstain vote in tally.sh
  • tally only the most recent yes/no/abstain vote in a second implementation (tally.sql)

need list from secretary
read list
check each voter is registered

#60 (comment)

I think it's availble in the browser console, so it's possible to treat this as a doc / training issue, @OPNO . But that seems kinda awkward.

#29 (comment)

In our July 11 meeting, @leithaus suggested I draw some flow diagrams to clarify some of the options we were discussing.

Let's start with the Dust approach, as it's most clear about how it addresses the issues critical for use in a coop annual meeting.

Dust (#29)

editable source

This addresses the one-member-one-vote issue (#31) by counting only votes from registered addresses. A Jun 3 board resolution requires all members to provide a REV address to the coop in order to vote in the annual meeting.

Tallying the votes (#35) involves non-trivial software development to pore over the contents of the chain and extract the relevant transfers. Regarding the secret ballot stretch goal (#18) this approach allows the coop to discover how each member voted and puts all votes on the public record so that should anyone ever discover which address a member registered, they can look up the member's vote.

This approach addresses the zulip store-of-reference issue (#24) by leaving it out of the picture.

With regard to questions and answers (#34), it's reasonably clear how the board would decide the agenda and the secretary would assign a unique target address to each option on each question. While it's clear how a member's vote is represented on chain, the UX for getting it there is a little less clear. It's possible for a member to manually do a transfer to each target, but that seems arduous. The diagram here suggests an html/js app deployed via IPFS or the like (some content addressable store where the content can't be changed once a URL is announced) that lets the members use normal web forms with radio buttons and one "submit vote" button.

So the role (#33) of the board and secretary are clear. The governance committee could perhaps help the members give feedback on the UX.

Write questions in Zulip; Vote using FE (#28), Dappy (#30)

editable source

I gather each voter generates their own key pair as part of a dappy app. How we ensure (at most) one vote per member (#31) is not clear to me.

My understanding of this approach is that it involves development of a govbot that allows the membership to collaborate on questions; for an AGM, the board would approve the final agenda of questions and answers (#33, #34). The govbot would compute links that include enough information for a dappy app to present the ballot form with questions and candidate answers (#34). Members would take responsibility to see that their votes, in encrypted form, make it to (the right place on) the blockchain.

The strength of this approach is that anyone can, in theory, tally the votes (#35). And votes remain anonymous (#18). The board and secretary take responsibility for the tally, so I suppose they should be provided with some software to do it along with some assurance that the software is correct. Arguing the correctness of C/C++ software is extremely challenging, in my experience.

Write questions in Zulip; Vote in Zulip

editable source

This flow leaves many questions un-answered, as yet:

• #31 how do we ensure one-member-one-vote?
  • #39 is one suggestion: integrate metamask as a zulip authentication mechanism and log using an ETH address correlated to a member's REV address.
• #34 how does the board / secretary choose the questions? how do members answer them?
  • some work on a bot is in progress
• The rchain mirror of zulip (#24) is critical path. The design is reasonably clear but engineering a reliable service takes some work.

• Create 2000 key pairs
• Send them by email to members
• Deploy ERC 1155 contract with 2000 tokens (not associated)
• Provide website or interface to vote (2 options)
  • Dappy - download dappy
  • Tomislav (Metamask) - visit website
  • Command line voting -
• Meta information would be how the members votes
  • Voter can update their vote
• Import data into CSV file to count results (yes/no or integers)
  • Export data tally data
  • Tally data online (involve storing the voting on rchain)
• Real-time voting results

at least a link to how to get some

#60 (comment)

Using** **https://github.com/fentec-project/CiFEr for anonymous voting of form (A, B, C, D… or neither)

1. Co-op generates a master key.

2. Co-op generates an identity vector [1, 1, …., 1, 1] and encrypts it with the master key.

3. Co-op generates member voting keys that are derived from the master key.

4. Co-op sends member voting keys to members through email (or discord) as a link to a dapp

5. Members client compose an array of form [0, 0, …., 1, 0] that represents the user vote.

6. Members client encrypts the vote making it’s content unreadable to anyone else (including owner of the master key)

7. Members client hashes the key to get the unique vote ID hash and uses that to put the encrypted data on chain in a key-value map.

8. Voting period closes.

9. Co-op releases it’s master key to the public and puts it on the blockchain.

10. Co-op (or anyone) takes the key-value map values from the blockchain and does an inner product with its own identity vector to ensure votes have at most one ticked option, returning:

    0: member did not vote for any option (can be made oblivious as well)
    
    1: member voted for one option.
    
    2+: invalid vote, maximum of one is allowed.
    

11. Co-op (or anyone), can calculate the final voting results on encrypted data by taking each individual column and doing an inner product with the identity vector, returning a readable number that corresponds to the number of votes for that option. Individual votes remain anonymous.

@leithaus took the ball on this

@ian-bloom noted there's a small window between when the list of addresses is fixed and when voting opens. @leithaus acknowledged.

• repository reorg, pending tgrospic/rnode-client-js#14
• continuous deployment of this repo for beta testing / review: https://rv2020-beta.netlify.app/
  • we plan for the the coop to have its own fork with continuous deployment; that's out of scope of this issue
• add link / redirect from earlier site(s) (I think it's clear enough that they're obsolete)

So far, I have been using drag-and-drop to netlify after running npm build:web manually after selected commits to deploy https://rv2020-m3.netlify.app/ballot.html.

I'd like to have the master branch automatically deployed (a) to reduce maintenance burden but also (b) to make the process more transparent so that voters can have confidence about what software they're using. This example looks just right:

• Static Site Generators with Node.js

I'd also like to publish release artifacts so that folks can just download the static site and host it locally for increased confidence.

I'm not currently using this repo for the rv2020-m3 source code; I'm using https://github.com/rchain-community/rnode-client-js , a fork of https://github.com/tgrospic/rnode-client-js . The scope of rnode-client-js is evolving; it started before rnode supported sufficiently browser-compatible APIs to eliminate the need for a back end for RChain dApps. (tgrospic/rnode-client-js#14 ) So only a subset of the code there is relevant to the voting dApp.

Meanwhile, I re-used this repo for my rchat mirror-postgres-to-RChain prototype. I suppose that belongs in a repo called pg2rho or rchain-db-sync or rchain-django-sync or some such.

The o2r materials were based on the idea of migrating discord credentials to rchain using OAuth (hence o2r); since the coop is using REV address credentials, that's no longer relevant.

(or chomium-based such as brave)?

One user had to switch from safari to chrome because that's where metamask was installed.
#60 (comment)

@jimscarver asked whether firefox works; I don't know; I haven't tested it.

So far (b5961e0) I just wrote them to a file and used https://github.com/tgrospic/rnode-client-js to deploy them manually.

Each trigger event should go all the way through to the chain. Perhaps batch them until things go quiet for ~5 seconds (or we have N queued up or we've been batching for M seconds).

My earlier attempt (ca21a1b) to do deploys from a service was buggy. But I got it working in 0654a4f.

cc @jimscarver @leithaus @steverosstalbot @TheoXD

thanks, @tgrospic and @zsluedem , for debugging help.

I originally had it at the bottom, but if the questions are long, it goes out of view. Hm.

#60 (comment)

My pitch to the Apr idea workshop was:

1. Short Title: rv2020 - rchain voting with discord integration
2. Short Description: Using discord OAuth integration, we can "springboard" discord identities into on-chain RChain coop membership voting rights, preserving a high degree of privacy.
3. Link: https://github.com/rchain-community/rv2020

But that link actually went to this repo, where the readme discussed all sorts of other stuff. The scope I had in mind was closer to https://github.com/rchain-community/rv2020/tree/o2r-reboot/o2r

But those who voted for this dapp idea were probably voting on what the readme discussed. As the discussion is moving forward, discord integration might not even be relevant.

But in case anybody asks "what happened to discord integration?" this issue will at least document where it went.

some experience: https://github.com/rchain-community/rv2020/blob/o2r-reboot/o2r/gateway/server/main.js dfa3ad4

Authentication methods — Zulip 2.2.dev+git documentation
Authentication in the development environment — Zulip 2.2.dev+git documentation

this is mostly a place to host an image.

On sign-in, check the transaction server for transactions from the voter's address and update the radio buttons to match.

to help, maybe prototype with slide-ware

• brainstorm "slideware"
• visual prototype with bootstrap
• track state in progress bar
• UI tour

• hide by default? no, according to Sep 26 preferences. So the plan is:

  • draft slides explaining the code: Voting in Rholang
  • present to small group of members
  • link slides, recording to voting page
  • edit the video a bit

#60 (comment)

Create an improved UX for rv2020 which is easier to use. Current UX is a template to build upon.

Use Alex Crank to get list of developers to recruit or hire to help accomplish this task.

find >= 3 members and see how they do with the UI

• draft script
• Eric: conduct recorded session, jot down notes, record issues
• Rao
• Daryl
  • add some issues from Daryl's session
• Lilia
  • review Lilia's session for issues
• Nora

secretary role moved to #86

IOU screenshot

Comments from Greg Meredith:

• a REV address is issued to each coop member and is funded with dust.
• The private and public keys of the addresses are emailed to the members
• A REV address is issued for each possible choice of each ballot item.
• The member then votes by using their wallet to send dust to particular addresses.
• Any wallet can be used for voting. Optionally we can create a browser based app to simplify voting.
• All transactions for all ballot choice addresses are extracted from the transaction history by a script.
• If a voter has multiple votes for one choice then their vote will not count.
• The REV will be returned to the voter after all voting has been completed so that they can vote again in future ballots .
• The coop has a list of all addresses that are eligible to vote and removes addresses that are not available by a script.
• The votes can then be tallied by a script

As I discussed with @jimscarver and @SteveHenley last weekend, I hope the governance committee takes an active role in the zulip approach. The scope of the governance committee is advisory. Instructing the members on how to vote is done by the secretary, IIRC (IOU bylaws citations). So the gov cttee could recommend to the secretary that they use this method, once it's developed.

See also issues for

• #34 Deciding on the ballot, done by the board.
• #35 Approving the tally of votes, done by the board.

cc @steverosstalbot @ian-bloom , gov cttee co-chairs (I think)

• code review
  • e.g. @tgrospic reviewing code by @dckc and vice versa
    • #53
• user experience review #60
• administrative burden review
  • Ian, secretary
  • review by members at large

1. Generate random tickets
2. Distribute tickets randomly to coop members by email
3. Election app verifies ticket and deploys the votes anonymously
4. Association of member email and ticket destroyed after vote closing?
5. Map of ticket hashes votes/answer to each question on rchain
6. Provide website or interface to vote (2 options)
   1. Dappy - download dappy
   2. Tomislav (Metamask) - visit website
   3. Command line voting -
7. Meta information would be how the members votes
   4. Voter can update their vote
8. Import data into CSV file to count results (yes/no or integers) or tally in rholang

based on user testing: #60 (comment)

thanks, @jimscarver

In 93114e7 of Aug 2018 I used Apache 2 on o2r, following precedent of rchain/rchain.

Earlier today @jimscarver chose MIT in 98d7b4c . That would probably be OK by me as well, but I'm not sure I hold the copyright to be able to change it. It's arguably work-for-hire that I did while under contract with rchain.coop, so we might need their OK to change the license.