search

rchain-community / rgov

RChain liquid democracy demo: capability sharing, mailbox, directory, chat, ...
https://rchain-community.github.io/rgov/
10 stars 14 forks source link

"insert 25cents to play" account rather than in-your-face signature at each move #85

Open dckc opened 3 years ago

dckc commented 3 years ago

As in earlier work: support a nearly throw-away account (key kept in localStorage) where the user puts some small-ish amount of rev (say 0.25 REV) once to cover many deploys. Like putting 25 cents into a videogame to play for a few minutes.

Right now, the rgov UI acts like you have to do a full credit card transaction every time you want your videogame character to take some small action.

dckc commented 3 years ago

in another app: https://github.com/rchain-community/RChain-Status/commit/d6ecd92f8de1b064500413075cff868a02851ece

jimscarver commented 3 years ago

There are discussion in governance on handling pre-paid data. from log Rchip needed for prepaid transaction fees; like near.org https://docs.near.org/docs/concepts/gas#what-about-prepaid-gas https://epicenter.tv/episodes/390 https://www.publish0x.com/my-own/near-protocol-an-answer-to-high-gas-fees-xjmvgwy

I think this is out of scope for rgov and this issue can be closed.

dckc commented 3 years ago

I disagree that it's out of scope. I think having to go through the whole digital signature dance for every interaction is onerous and distracts heavily from the experience; makes it borderline unacceptable.

I know for a fact that adding this feature is feasible; as noted above, I've done it before. If made a PR for this feature, would you decline to accept it on the basis that it's out of scope?

Bill-Kunj commented 3 years ago

This may be out of scope for the development interface (although I hate having to sign every move I make). For the overall rgov interface, this seems relevant.

What I don't know is whether our not it's part of our October deliverable.

dckc commented 3 years ago

I don't see it as critical for October.

jimscarver commented 3 years ago

This seems out of scope for rgov as I believe prepaid contracts should be a layer one capability.

The "Internet Computer one" jumper to 35B evaluation https://dfinity.org All transactions are prepaid, the user never pays. That could catch on. @TheoXD has been campaigning for prepaid contracts. Perhaps that could be a layer under DAASL.

I think we need an rchip

TheoXD commented 3 years ago

@jimscarver Near.org also has it https://docs.near.org/docs/concepts/gas#what-about-prepaid-gas

Bill-Kunj commented 3 years ago

This seems out of scope for rgov as I believe prepaid contracts should be a layer one capability.

RGOV certainly is about something besides prepaid contracts, so in that sense it is out of scope. However, someone has to do it eventually. Why not us and make RGOV an example with a usable interface?

dckc commented 3 years ago

@TheoXD writes:

@jimscarver Near.org also has it https://docs.near.org/docs/concepts/gas#what-about-prepaid-gas

No, that's about the developer paying the users' gas. I'm not talking about that.

I'm just talking about a nearly throw-away account (key kept in localStorage) where the user puts some small-ish amount of rev (say 0.25 REV) once to cover many deploys. Like putting 25 cents into a videogame to play for a few minutes. Right now, the rgov UI acts like you have to do a full credit card transaction every time you want your videogame character to take some small action.

jimscarver commented 3 years ago

throw-away account (key kept in localStorage) where the user puts some small-ish amount of rev (say 0.25 REV) once to cover many deploys

Ok, that is useful and not necessarily related to prepaid deploys. My only concern is wasting much of the rev, taking it out of circulation. A prepaid amount might persist for an account and not require a separate user authentication on top of a signed deploy.

w2vy commented 3 years ago

I was reviewing the Power Box features and it mentions a MultiSigRevVault

It sounds like you can authorize transfers with either the Private Key or a deployerAuthKey

https://github.com/rchain/rchain/blob/dev/casper/src/main/resources/MultiSigRevVault.rho

If that deployerAuthKey can be changed (not sure what seal and unseal are) then I could have a (few) MultiSigRevVaults that I give third parties access to and they could collect gas (or other) fees from me as the needed. This makes the RevVault reusable so no worry of leaving lost of dust behind in discarded RevVaults

If the application is an ongoing relationship they could deduct funds monthly, if short termed then more often

It would be nice when creating the deployerAuthKey if a withdrawal limit could be set, needing a new authorization to get more

dckc commented 3 years ago

Please move discussion of fees paid by someone other to the user to a separate issue.

TheoXD commented 3 years ago

Please move discussion of fees paid by someone other to the user to a separate issue.

I think those two ideas are still related. If you insert 25c of your own money into a slot machine on rchain, let's assume it goes into a purse that gets drained by the network to cover for tx costs + possibly profits to the developer. If developer decides to give people who happened to walk by a free try, developer shouldn't have to send them 25c worth of REV so that they can put it right back into a machine, so why not let developer put it directly into the slot machine in the first place?

dckc commented 3 years ago

Because it looks like a research project, to me. I have no idea how to do it.

dckc commented 3 years ago

It doesn't get drained by the network. It gets drained in the normal way, by signing deploys with phlo price and phlo limit set. The main difference from the full in-your-face metamask signing experience is that the page ui can do it for you because it know the private key with which to sign deploys.

This is risky... Anyone who has access to your browser might discover the key and take the funds. But it's a small, bounded risk.

It would be like putting a quarter into a Galaga machine, taking a break, and returning to find that someone else had used up your remaining ships. Oh well. No big deal. Put in another quarter if you want to play some more.

dckc commented 3 years ago

The page ui generates a random key and hence rev address and displays an "insert 0.25 REV to avoid annoying dialogs" button. You press the button and transfer 0.25 REV to this generated account using metamask as usual.

Then the page can make several deploys without nagging you.

The key is kept in localStorage, so if you navigate away and come back (using the same browser) you can continue to have deploys paid from the generated account.

w2vy commented 3 years ago

I think that is a good short-term solution.

Later we can push for a better way, it may take a new transfer type in rchain

Tom

On May 28, 2021 2:10:10 AM EDT, Dan Connolly @.***> wrote:

The page ui generates a random key and hence rev address and displays an "insert 0.25 REV to avoid annoying dialogs" button. You press the button and transfer 0.25 REV to this generated account using metamask as usual.

Then the page can make several deploys without nagging you.

The key is kept in localStorage, so if you navigate away and come back (using the same browser) you can continue to have deploys paid from the generated account.

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/rchain-community/rgov/issues/85#issuecomment-850164677

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bill-Kunj commented 3 years ago

It doesn't get drained by the network. It gets drained in the normal way, by signing deploys with phlo price and phlo limit set. The main difference from the full in-your-face metamask signing experience is that the page ui can do it for you because it know the private key with which to sign deploys.

This is risky... Anyone who has access to your browser might discover the key and take the funds. But it's a small, bounded risk.

It would be like putting a quarter into a Galaga machine, taking a break, and returning to find that someone else had used up your remaining ships. Oh well. No big deal. Put in another quarter if you want to play some more.

@dckc Ugh. I would never play Galaga. But, Defender.... :)

Bill-Kunj commented 3 years ago

For a longer term solution, don't we need to address the loss of prepaid coin when a browser is closed?

w2vy commented 3 years ago

That may be best solved with changes in rchain like receiver pays gas or prepaid gas...

Well beyond the scope of what an application can do

On May 30, 2021 10:46:40 AM EDT, Bill-Keuntje @.***> wrote:

For a longer term solution, don't we need to address the loss of prepaid coin when a browser is closed?

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/rchain-community/rgov/issues/85#issuecomment-851011564

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

dckc commented 3 years ago

For a longer term solution, don't we need to address the loss of prepaid coin when a browser is closed?

localStorage persists in that case.

jimscarver commented 3 years ago

localStorage persists in that case

yes, that answers sufficiently for me. I like it. prepaid doing it may be better but is a long way down the read.

Bill-Kunj commented 3 years ago

For a longer term solution, don't we need to address the loss of prepaid coin when a browser is closed?

localStorage persists in that case.

Agreed.Shall we covert this into a separate issue for implementation?

dckc commented 3 years ago

No, I don't see any reason for a separate issue. This issue is about the feature, which includes implementation, testing, documentation, and whatever else it takes to get it done, just like any other feature/enhancement issue.