Let (unregistered) contributors claim Contributions/Tokens #54

New Issue

raucao · 2018-06-15T13:50:48Z

bumi commented

2018-06-15 13:50:48 +00:00

(Migrated from github.com)

Right now every contributor requires an Ethereum wallet and needs to be added as a contributor before tokens can be issued. This is a bit of an overhead and all contributors need to be convinced using kredits before proposals can be made.

To make this easier we should think of a concept to claim contributions AFTER the voting. So proposals can be created and executed for any contribution even if the contributor is not yet in the system.

Right now every contributor requires an Ethereum wallet and needs to be added as a contributor before tokens can be issued. This is a bit of an overhead and all contributors need to be convinced using kredits before proposals can be made. To make this easier we should think of a concept to claim contributions AFTER the voting. So proposals can be created and executed for any contribution even if the contributor is not yet in the system.

raucao commented

2018-07-27 11:57:16 +00:00

(Migrated from github.com)

I was thinking about this just now, and here's a thought: how about we handle this entirely off-chain for now, and simply queue those contributions in hubot-kredits, with the site and account that it gets the hook from?

We could then listen to contributor creation and update events from the contract and match those to the queued contributions. Meaning when someone's details are added, no matter if for the first time or updating with a new site account later on, the bot can go and create those contributions using the date and time it recorded them at.

This solves a few problems at once, most notably that there's no complex logic on the blockchain that needs to use oracles or other means of identifying contributors. From the blockchain perspective, it's basically a no-code solution. And from the application/user/UX perspective it's much easier than other complex processes. At least as a viable first solution.

WDYT?

I was thinking about this just now, and here's a thought: how about we handle this entirely off-chain for now, and simply queue those contributions in hubot-kredits, with the site and account that it gets the hook from? We could then listen to contributor creation and update events from the contract and match those to the queued contributions. Meaning when someone's details are added, no matter if for the first time or updating with a new site account later on, the bot can go and create those contributions using the date and time it recorded them at. This solves a few problems at once, most notably that there's no complex logic on the blockchain that needs to use oracles or other means of identifying contributors. From the blockchain perspective, it's basically a no-code solution. And from the application/user/UX perspective it's much easier than other complex processes. At least as a viable first solution. WDYT?

bumi commented

2019-01-23 02:36:34 +00:00

(Migrated from github.com)

YES, let's do this off-chain for now.
and we should do any of such blockers off-chain for now until we have enough time to get it working on-chain.

YES, let's do this off-chain for now. and we should do any of such blockers off-chain for now until we have enough time to get it working on-chain.

👍 1

raucao added the

feature

label 2022-07-16 15:25:30 +00:00

raucao commented

2022-10-29 11:52:21 +00:00

Forgot to add a note here, since we changed the architecture to not require accounts/addresses per se, but the addContributor function still does.

So, as a temporary workaround, we just generated throwaway accounts and ditched the private keys without looking at them, when creating a new profile for someone else.

Forgot to add a note here, since we changed the architecture to not require accounts/addresses per se, but the `addContributor` function still does. So, as a temporary workaround, we just generated throwaway accounts and ditched the private keys without looking at them, when creating a new profile for someone else.

raucao added the

ui/ux

label 2022-10-29 12:01:15 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: kredits/contracts#54