Committee should have the ability to re-issue invitations

[Chris-Hibbert]

What is the Problem Being Solved?

an intended committee member might do the wrong thing with an invitation, and not be able to actually exercise it. It would be nice to be able to re-issue them.

This shouldn't be needed as long as chain set up is all being done from scripts. Once people are interacting with the chain, that may not be true.

Description of the Design

Currently the committee will re-send the same invitations if asked for them a second time. It should be able to create new invitations that would be connected to the same voters, so if member C got two invitations, they would both carry the same voting rights.

Security Considerations

The ability to re-issue invitations has to be as closely held as the original.

Test Plan

verify that they both vote the same shares.

[erights]

so if member C got two invitations, they would both carry the same voting rights.

What about Fred? If two outstanding invitations carry the same rights, what if both invitations get used? If the second invitation doesn't get to use those rights, can't Alice sell Fred a bad invitation?

Or are both invitations independently good?

[Chris-Hibbert]

These are good questions. My instinct is that selling the ability to vote is hard to justify. But I think invitation safety applies for other kinds of transfers.

My expectation was that it would be as if the authorized voter had shared their voting facet. Two agents would have the ability to vote that seat, and the ballotCounter would count whichever was the most recent.

@dckc provoked this issue by asking how we would recover if the winner of a committee election mis-handled their invitation or otherwise lost the voting facet. Would we have to hold the election over again in order to get them a new invitation?

I don't have a solution to Dan's conundrum that isn't susceptible to the problems @erights points to.

Another approach in similar situations is to revoke the original, but that has the same issues as you posit. Is the solution to make the revocation and re-assignment facet legible, so Fred can tell who has the ability to vacate his voting ability?

[dckc]

I think I heard @dtribble say "if the economic committee does something unacceptable, you [the BLD holders] fire them and elect a new one." AFIAK, that's not a feature that our current design accommodates.

So as things stand, if one of the economic committee members mis-handles an invitation, we may need to discard the economic institutions (AMM, VaultFactory, ...) and start new ones with a new committee.

Perhaps this issue should be re-scoped to fact that the BLD holders can't fire the economic committee and replace them?

[erights]

We should discuss this at some upcoming meeting. Which one?

[Chris-Hibbert]

It touches on invitations and the Fred problem, so I think Zoe/ERTP. I've added it to the agenda.

[dckc]

Let's use the meeting as an upper bound on discussion latency, not a lower bound, please.

In our current design, the BLD holders can appoint the committee, but implicit in the "fire the committee" notion is that the committee is accountable to the BLD holders; IOW, that the BLD holders are delegating to the committee, not making a transfer of rights.

Oh... light-bulb... in the governance design, there's an underlying creator facet that the contract governor uses to change parameters, right? Perhaps it suffices to make that facet available the BLD holders (by way of "big hammer" bootstrap #4642 )...

[dckc]

I got bit by this while working on the demo #4348 : had address 1 in one proposal, but it was buggy in some way. Then I restarted the local-chain and local-solo and tried again. I suppose the invitation went out, but since I restarted the local-solo, I had a new address so the invitation didn't come to my zoe invite purse. So I get to start again...

[Tartuffo]

Since the committee can replace itself with a new committee, this is not really needed. Or it can invite someone new. Moving to Product Backlog.

[Chris-Hibbert]

If someone misplaces an invitation or uses it from the wrong place, there won't be a way to re-issue it, as @erights points out above. The solution is for the committee to reconstitute itself (or if it doesn't have the ability, to get whoever does to do so).

Since committees will need mechanisms to handle the case where a voter resigns or isn't responding to calls for votes, they'll already need to find ways to handle similar issues. Voters and organizers need to be aware of this possibility, and not limit their actions in a way that would leave them without the ability to conduct votes.

Closing the issue. We'll need the ability to handle the related issues, but not the one that's the focus of this issue.

[dckc]

The solution is for the committee to reconstitute itself (or if it doesn't have the ability, to get whoever does to do so).

Unless we specifically code for it, there is no such "whoever does have the ability". I guess this is a hazard that we'll have to be aware of: we often assume that there is.

[Chris-Hibbert]

Unless we specifically code for it, there is no such "whoever does have the ability". I guess this is a hazard that we'll have to be aware of: we often assume that there is.

In my mental model, most mature governance arrangements have a contract that controls creating questions for the electorate. We've only built the one for governing params so far, and it lets anyone with access to the private facet create new questions with pretty arbitrary conditions. I expect the managing contract for a steering committee to set terms for how frequently elections happen, to handle replacement for resigning members, to have a mechanism for proposing candidates or slates of candidates, and much more. But those are not on the short term list to get done.