Yes, it is possible to resume the process at step 2 (if there’s enough allowance and no contribution) and 3 (if there’s a contribution but no votes).
1 Like
I think a modal window would look better because there’s not enough content to fill a new page. Here’s a quick preview:
@markop If you have a better idea for this part of UI, could you create a mockup?
My preference would be to have this in some persistent element on the page, rather than a modal.
For example, this whole flow could replace the cart UI, meaning you could continue to use the rest of the page (browse projects, etc) while you wait for your transactions to confirm.
That said, the modal that you made looks fine as well.
I don’t think handing people a chunk of bytecode to send at a later date for their vote is the right UX (because of reasons*). But it’s probably fine for the test rounds.
Reasons
- This pattern will almost certainly lead to phishing scams stealing people’s money, since the bytecode is pretty opaque to most users.
- There is a really good chance people will lose that text and/or forget to post the transaction, so their votes wont count.
Currently there are distinct contribution and voting periods so we can’t send tx immediately after making contribution.
The final version of the UI for Milestone 3 was described in this post: Making contributions to a funding round
Right, but this will change at some point, no?
Yeah, I think this UX is fine for this milestone. But it can’t be the long-term solution.
So we did! Thanks for the reminder.
Defaulting to handing people a a chunk of bytecode and telling them to wait.
Nowhere in that post I did say that we should tell people to wait. Users will probably need to wait for transactions to confirm at steps 1 and 2, but that’s a normal situation for dapps.
The bytecode should be displayed somewhere at steps 4 and 6 in the scenario with a bribe because user may want to submit transaction from another account instead of sending it to relayer.
It says right here “please send this transaction… after 2020 Aug 28”
This is telling users to wait.
The bytecode should be displayed somewhere at steps 4 and 6 in the scenario with a bribe because user may want to submit transaction from another account instead of sending it to relayer.
I agree, this is probably a necessary evil. But the happy path probably has no need to hand user bytecode.
In the case that the user is being bribed, couldn’t we give the user all of the parameters they would need to submit from another address, rather than the bytecode? This could even be a json file or something that the app facilitates sending. So the user can switch accounts, pass it to a friend, or give it to a relayer to send.
We’ll use this kind of UI only for testnet rounds. I already explained why we can’t submit tx immediately at the current stage of development and gave you a link to the description of how the final version UI will look like at Milestone 3. If you have further questions, ask them in chat.
What parameters? To send an ethereum transaction user needs a contract address and raw transaction data, and that’s exactly what we are giving them. A user just needs to copy-paste tx data and contract address to the wallet UI.
Yeah, that modal is fine as well, everything is on the same screen and moving forward through steps seems faster. I’d be ok leaving it as is but definitely consider revisions based on the discussion below (handling bytecode, waiting time etc.)
1 Like
@markop What do you think about placing the wizard inside right side bar as Auryn suggested?
This would make sense if we deploy clr.fund to mainnet where transactions can take a long time to confirm. But if we deploy to sidechain/rollup we probably won’t have this problem. If moving through the steps happens quickly I would prefer modal because it better captures user’s attention.
1 Like
The cart could easily be replaced with the modal and it will grab the same user attention since it will replace something already existing on the screen, have a loader etc. soon after that user already knows things are happening in that area.
Similar to MM modal when you have to multiple times approve something (view wallet, approve spend, sign transactions).
I’m ok for keeping it as is now in the modal if it’s going to be deployed on a sidechain, or if it’s not much of an effort to move it to the sidebar Cart right away. I’d let you make that decision based on dev other priorities.
2 Likes
@barryWhiteHat recently suggested a better solution to the problem of vote buying. The idea is that we allow users to vote immediately after signup but we delay the processing of messages submitted at signup until the end of the voting period. Even if briber gives user a private key and asks her to vote and then invalidate the key, a user can override these commands later during the round:
This solution should give us better UX while keeping MACI safe from vote-buying attacks.
What does this look like in practice for someone who has been bribed?
It should look like this:
- Contribute to the round using your own key.
- Submit message with the vote and change the key to invalid key as the briber demanded.
- Show proofs to the briber and get the money.
- Return later, change key you used at signup to another valid key and vote for the projects you prefer, overriding the previous votes.
But you can’t change the key until the voting period, right?
Doesn’t this just create a race condition between you and the briber?
There are still two periods, signup period and voting period (though this naming is not quite correct). A user can submit messages during the signup period, but these messages are processed after the messages submitted during the voting period. So when signup period ends, user can secretly change the key and everything submitted during the signup period becomes invalid. I think the briber can still try to force user to vote and invalidate key again immediately after the beginning of the voting period, but it is hard to do and the current MACI implementation is also vulnerable to it.
Right, this is what I’m suggesting. The briber would just force the user to create a valid message that they can broadcast in the first block after the voting period ends. In which case, there is a race condition between the briber and the user to get their transaction into that block (and ordered first in the block). The briber is probably better equipped to make that happen.
1 Like
great! , It would be a great idear, I support!