Managing user permissions and wallet funding with Colony


#1

Hi everyone!
I was wondering it’d be possible to implement some kind of market (buyer/seller) features into Colony ?

For instance, imagine a non-profit organization getting food from store and redistributing it to people in needs. This organization would give X quantity of its own ERC-20 Token to every member, so that those people could claim the food they need each week.

  1. How would you manage to register this group of people who’d need to get some “approval” ? There could be a system of Waiting-list / Black-list / White-list for example.
  • I was thinking of separating these user into separate Domains, but how to do the register process with user permissions ?
  1. How could we allow White-listed users to spend their credits ? Can we send a native Colony Token (not the CLNY token) to approved users’ wallets ?
  • If it’s possible, what are the required steps to allow sending tokens from a colony to users’ wallet ? I tried the TokenClient.transfer.send and TokenClient.transferFrom.send methods but that did not work.
  • If that’s not possible, I was thinking of creating a sub-domain and pot to each user, then move funds from the global funding pot to each user pot. However, can we allow only one specific user to move funds from a specific pot to another ?

I know it sounds a lot like District0x but let me know if we could manage to implement this kind of features using Colony’s native features :wink: !


Multiple task types
#2

Interesting project idea!

Hmmm… what if people volunteered their time with the store or organization in exchange for a token payout that could be used to claim food? Each week volunteers have a task to volunteer for X amount of time in exchange for Y amount of tokens. The signup list would be off-chain and the organization would approve their request by assigning them a task.

This way the organization could run with the help of volunteers and volunteers could gain reputation with their tokens (which would mean gaining some ownership of the organization if the organization was governed by the colony). Also, if some people were unable to volunteer, there could be a separate signup list where an approval would also be the assigning of a task.

This would eliminate the need to separate users into domains and simply someone approved for the week is someone assigned a task for the week, someone on the waitlist is someone who signed up but has not been approved, and someone on the blacklist is someone who signed up but was never approved.

This was just my first thought! Maybe a bit of a digression?


#3

Also, we don’t have any plans to implement market specific feature per se but I suppose you could use a task for an exchange.

For example, the “seller” is the “manager” and “evaluator” and the “buyer” is the “worker”. The seller creates a task, which describes the item they are selling and how much they want. The buyer submits some kind of proof that the funds are being held in escrow and the seller has access. The seller finalizes the task, they rate each other, the item is delivered and the funds are released.

This is just a rough sketch with plenty of holes and questions but some food for thought.


Multiple task types
#4

In response to the question about sending tokens, you should be able to send tokens from your colony to any account if (1) the colony is the owner of the token (2) the token contract has tokens available and (3) the account sending tokens has the approval and authority. So… it looks like you found a bug!

I opened an issue in colonyJS (#282). I also posted your question about the required steps to allow sending tokens from a colony to a user in the “Support” category here for a quick reference just in case someone has the same question. I will follow up and answer there.


#5

It’s a bit of a digression but I like the idea!
We could totally use an off-chain signup list then assign volunteers a task for a specific amount of time, meaning some could be “volunteers” or “simple members” and they’d need to renew the task every N months to keep their status.

That would work, but imagine many buyers want to buy the same good from one seller, i.e. rice. That would mean the seller has to create many tasks with specifications like {"title": "Rice", "description": "I am selling 500g of rice for N tokens"} ?
For instance, Bob is a a rice producer and he has 30kg of rice to sell each month. Alice, Tom and John want to buy 500g of rice.
In order to sell all his rice, Bob would have to create N tasks to sell all his rice ? Couldn’t that be done with only one task ?

Furthermore, in this process, how do you see the escrow system working along the task funding system ?
If Alice holds 100 tokens and spends 10 tokens to buy some rice, she will send her 10 tokens to the escrow, then the seller finalizes the task and the escrow system sends the tokens to the seller. However, how does the seller gain reputation if the payout isn’t set through the task details ? i.e. if the task payout is set to 0, the seller gains reputation * N tokens payout, but that would be zero in this case ?

Thanks again for your help :wink: !


#6

If the purchases were an ongoing subscription of some sort where each month Bob distributes a specified amount of rice to each buyer, this could be done with one task per buyer. Although, with their current design, Colony tasks would not be ideal for a large number of small exchanges. Tasks are designed to be flexible and we are definitely interested in exploring more use-cases as well as how they might work alongside contracts of your own, but again, probably not the best fit for this situation. Maybe a new feature?

In this situation, the task funding system would be more like a rewards program where the colony token would act like points and the funds in escrow would be a form of payment agreed upon by both parties. I am not sure how it would work otherwise off the top of my head but I will try to give it some more thought.

Also, I went ahead and created a #features category. These project threads seem like they will give rise to ideas for new features that other projects could benefit from as well. If you have any specific requests, post them there.


#7

I don’t have a solution for this just yet, but I want to acknowledge that I believe this to be a good idea. It was feedback we received when we did our last round of beta testing, too. See here.

We like the idea of ‘task types’. For example, you could have a type: persistent that specifies some X requirements for Y payout and allows many people to complete said Y requirements and receive X payout without the task closing.

This isn’t on the roadmap yet, but it’s in some distant backlog and it just may get pushed forward if we get enough feedback to do so.


Multiple task types
#8

I see, that way, the task payout would be more like a complementary reputation! But we would need then two different tokens, one used as rewards, and one used as money token. Can a Colony own multiple Tokens ?

I like the idea of persistent tasks and I’d love to see this kind of feature implemented!


#9

I hope this answers your question:


#10

Also, let us know if you start building something. We would love to follow along and help out however we can. If you need any help getting started, please don’t hesitate to reach out.


#11

Yea, either using a database or hardcoding some task types into your project that you can reference by id would both be potential solutions while you build out a prototype.

You could create a new task every time a task of the same type is finalized by checking the task type id, which you’ll want to save in the task specification.


Multiple task types
#12

Hardcoding some task types isn’t going to work out for me, I guess I’ll go for a database for now :wink: .
It’s a good solution though.


#13

Hey, I’m using HashiCorp Vault and its unofficial plugin vault-ethereum to manage users’ wallets.

However, since private keys aren’t available, I’m considering building a ColonyJS Adapter for Vault to sign transactions straight from the vault-ethereum plugin. Do you have any guidelines for building the adapter ?


#14

Interesting! I’m not too familiar with Vault but because it’s a REST server and it’s not recommended to use in a production environment, this is not something we plan to support in colonyJS.

We intend to be fully decentralized with our developer tools, but that doesn’t mean you can’t fork the repository and experiment with your own solution using a plugin such as Vault.

Also, have you checked out our new developer tool Purser. It doesn’t solve the problem that Vault seeks to solve (lost or compromised private key) but it simplifies interaction with Ethereum based wallets.


#15

No I haven’t checked Purser but I’ll try ASAP !
In the meantime, maybe there’s a workaround in the ColonyNetworkClient ?
For instance :

  1. initialise the ColonyNetworkClient with the EthersAdapter and my private key
  2. get raw TX data from whatever method I need
  3. send the raw TX to Vault
  4. sign TX from Vault and send it with the EthersAdapter

#16

Again, I’m not too familiar with Vault and this is not something we plan on providing support for in colonyJS but, if this is something you want to build into your project, I would be interested in seeing what you come up with!

What are you hoping to accomplish with Vault? Why not use an Ethereum wallet and connect with Purser?

There seems to be a lot of warnings in regards to using Vault in a production environment and some security risks if not configured correctly, therefore, I am a bit hesitant to provide any feedback on configuration. ; )


#17

Sorry I haven’t explained what I was doing !
Basically, we’re building a crowdsourcing platform allowing anyone having knowledge about companies (analysts, employees, students…) to contribute to KPIs, metrics and reviews about any company.

We don’t want our users to bother with the process of creating an Ethereum Wallet, neither installing plugins such as MetaMask, so we’re using Vault and vault-ethereum to manage their accounts (with secured ACL policies). What we’d like to do is sending all raw TXs from the ColonyJS Client to Vault (the colony-js-adapter-vault I talked about earlier) so that the private key never leaves Vault.

In the meantime, I modified vault-ethereum to return the private key when reading an account so I can use the colony-js-adapter-ethers but I know this is bad and unsafe practice.


#18

Awesome! This is a really exciting use-case!

I think building a colony-js-adapter-vault could work and who knows, if other projects are interested in this, we might consider including it in colonyJS, but that would be a later discussion.

Do you have some code to share for either your project or the colony-js-adapter-vault? I would love to check it out and maybe help out where I can.