6044 wallet voting #6077
6044 wallet voting #6077
Conversation
|
@dckc draft with current state. Hope to find time later today to add the tests with a committee vote invitation. |
| }), | ||
| slots: ['offerResult:1'], | ||
| }); | ||
| t.deepEqual(context.unserialize(cap), val); |
There was a problem hiding this comment.
it's important that unserialize preserves identity, so this test should be t.is(...)
| @@ -50,7 +50,7 @@ const makeOnChainWallet = board => { | |||
| }); | |||
| }; | |||
|
|
|||
| test('makeImportContext preserves identity across AMM and wallet', t => { | |||
There was a problem hiding this comment.
I think we still want a test that makeImportContext preserves identity across the AMM and wallet; that was its original motivation.
There was a problem hiding this comment.
Happy to revert. I thought I was executing your suggestion in #5883 (comment)
Or are you suggesting to keep this change and add something like test.todo('makeImportContext preserves identity across AMM and wallet') ?
There was a problem hiding this comment.
oops... that "better phrasing" suggestion wasn't all that clear; it was about the t.throws() message, not the test() description.
| @@ -187,6 +192,8 @@ export const makeExportContext = () => { | |||
| * @param {IdTable<number, V>} table | |||
| */ | |||
| const makeSaver = (kind, table) => { | |||
| // XXX table passed in to simplify type inference | |||
| assert.equal(table, walletObjects[kind]); | |||
| @@ -197,6 +204,7 @@ export const makeExportContext = () => { | |||
| }; | |||
|
|
|||
| return harden({ | |||
| saveOfferResultActions: makeSaver('offerResult', walletObjects.offerResult), | |||
There was a problem hiding this comment.
The Actions part of this / these names is a little iffy. hm.
There was a problem hiding this comment.
Yeah. I opted for consistency with the others, but I don't understand why "Actions" is part of any of them. Cool to remove from all?
There was a problem hiding this comment.
I think so. @michaelfig ?
are the other 2 used? @samsiegart ?
| @@ -17,6 +17,12 @@ import { QuorumRule } from './question.js'; | |||
|
|
|||
| const { ceilDivide } = natSafeMath; | |||
|
|
|||
| /** | |||
| * @typedef {{ | |||
| * castBallotFor: (questionHandle: Handle<'Question'>, positions: Position[]) => Promise<void> | |||
There was a problem hiding this comment.
@Chris-Hibbert I just realized that in order for committee members to be able to put questions as well, the "charter" contract should be a different shape:
Our design for raising debt limits involved using a method on a public facet, which assumed users had access to zoe and E(zoe).getPublicFacet().
https://github.com/Agoric/inter-protocol-bootstrap/blob/56de1ed1821e19828a6f74ff10b7fce27b3f2cb7/vote-raise-debt-limit.js#L177
I think life will be simpler if the new charter contract you're building uses methods on an offer result instead of methods on a public facet.
There was a problem hiding this comment.
... if the new charter contract you're building ...
There isn't a task corresponding to that description on my radar. Can we make an issue?
I presume we want a variant of econCommitteeCharter that serves PSM only. If the capability to invoke votes is carried by an offer result, should the various committee members each invoke a separate invitation, or is an invitation exercised once in bootstrap, and the offer result handed out from there?
There was a problem hiding this comment.
Can we make an issue?
Yes, we can; I more or less expected that was part of "Do The Right Thing" that you said what you had what you need for. The capability to vote is taken care of by the committee contract. My concern here is for posing questions. You're right that this raises a question of how the invitations get to the committee members. I suppose we can use the same mechanism as we did for the voting invitations, but it's worth some thought / discussion.
|
For now, achieving voting with continuing invitations in #6084 |
closes: #6044
refs: #XXXX
Description
Security Considerations
Documentation Considerations
Testing Considerations