Token Controlled Permissions


(Auryn Macmillan) #1

UPDATE: There is now a bounty US$250 +10ETH for this feature.


UPDATE: below is a more detailed spec of what we are looking to build. In short, this consists of two separate features - (1) Ability to associate Ethereum accounts with DAOhub account and track user token balances. (2) Include/exclude users from a group based on token balance.


Problems:

  1. Currently no way to distinguish DAO token holders (DTH) from non-DTH on DAOhub. This is important information for users when weighing an another user’s opinion.
  2. Currently no way to gauge a users level of investment in the DAO. This is potentially important information for users when weighing an another user’s opinion.
  3. Noise from non-DTH.
  4. Spam (not really an issue as of yet, Discourse does a pretty good job of taking care of spam)
  5. User requested feature. Not a problem in and of itself, but this is a feature which has been requested by users from day one.

Proposed Solution:

Users should be able to associate any number of ethereum addresses with their account by proving they control the respective addresses. This could be achieved through the following challenge response mechanic.

  1. User is given some single use unique information (hex code) and presented with a DAOhub Ethereum address.
  2. User includes unique information in transaction to the Ethereum address.
  3. Address that sends unique information to the DAOhub address is registered with the user’s DAOhub account.
  4. Repeat for multiple addresses.

DAOhub should monitor registered addresses, watching the tokens corresponding to the DAOs listed on DAOhub.

if user’s DAO balance > 0
addUser to group DTH
else
removeUser from group DTH

The DAO’s hub will have the following security permissions:
Admin: Create, Reply, See
Mods: Create, Reply, See
DTH: Create, Reply, See
Everyone: See

Cost benefit analysis:
The solution proposed above inplicitly assumes that the cost of problems 1-5 above is greater than the beneficial contributions that non-token holders are making at TheDAO’s hub, (2) the sum effort that it will take for token holders to link their tokens to their TheDAO’s hub accounts (and minus future benefits of token holders who decide not to go through that effort), and (3) the cost of implementation.
This feature will also be required in order to enable some of the more advanced features further down the roadmap, including: token weighted polls, DAOhub reputation, liquid democratic moderation, etc.



Hi everyone, were looking to implement a feature we’re calling “token controlled permissions” over on our discourse forum (forum.daohub.org). Below is a quick rundown of functionality we require. Any feedback, advice is appreciated, I would love to hear from anyone with experience in solidity and discourse plugins. If your interested in helping out, reply here or drop me a PM. This project will be funded by The DAO, so it could likely turn into an ongoing relationship/job for the right dev.

Users should be able to associate an ethereum address with their account by proving they control the address (by signing a message, or some other yet to be determined mechanic). DAOhub will then monitor those addresses, watching the tokens corresponding to the DAOs listed on DAOhub.

In order to create topics and post replies in a DAO’s hub, users will have to be holding a minimum threshold of that DAO’s tokens.

This feature should be achievable via a custom discourse plugin which automatically adds users to a the DAO’s token holder group when the DAO token balance in their associated addresses exceeds the minimum threshold.

Users not holding the DAO’s tokens will have read privileges only.

Workflow

  1. User is given some single use unique information and presented with a DAOhub Ethereum address.

  2. User includes unique information in transaction to the Ethereum address.

  3. Address that sends unique information to the DAOhub address is registered with the user’s DAOhub account.


(Tom Newsom) #2

I think your best bet is to handle the token system in the DAO code, driving Discourse via the API to promote and demote users from a Group.


(Auryn Macmillan) #3

Yes this is along the lines of what I was thinking.


(Kane York) #4

So basically, to participate in the forum, you need to place a certain amount of currency in escrow? Seems interesting.

I think you can accomplish this with a single Discourse group, call it paid or similar.

You may need to turn on Discourse as an SSO provider to hand out the addresses, or send them in PMs.


(Auryn Macmillan) #5

So basically, to participate in the forum, you need to place a certain amount of currency in escrow?

We don’t actually want to handle anyone’s tokens, so not quite escrow. Essentially we want users to prove that they control an address that controls a balance of DAO tokens. Proving that they are a member of the DAO.

We’ll use token balance to include/exclude users from a DAO token holder group which will have elevated permissions in The DAO’s category (we call categories hubs for branding purposes).

Later we also plan to use token balance as part of a reputation metric.


(omfg) #6

There are no (email) addresses.
Users aren’t necessarily identifiable by anything except their platform address (e.g. bitcoin address), so the problem goes back to the many discussions about what constitutes identity and the Discourse stance (which may be correct or not) that identity equals email address is why no one has done this yet.
It can be done, but it’s complicated when email address must be used. Additional changes to the code or more complex coding on external servers would be necessary to make this easier to execute.


(Auryn Macmillan) #7

Knocked up a quick flowchart showing how I envision the whole process working. I’ve divided it into three separate processes.


[PAID] (US$250 +10ETH bounty) Custom plugin which queries the Ethereum blockchain
(Auryn Macmillan) #8

I’m now offering a US$250 bounty, plus potential for further pay, for this plugin.


(Tom Newsom) #9

All the data and logic in that system is about a non-discourse system.

That entire flowchart can (and probably should) be implemented outside of Discourse, with the final two boxes in the flow (promote to group and demote from group) being handled by the API. Much easier to maintain full control of the code and you can pretty much guarantee it won’t break in a future Discourse release. It would also end up being portable to permissions in other 3rd party systems.


(Auryn Macmillan) #10

Would a non-native system be able to check token balances on longin and every x number of minutes while active? I imagine this is something that would have to be initiated internally via a plugin. Also would we not need to use a plugin in order to implement the user interactions and token information into the UI?


(Tom Newsom) #11

You could push the token count to each user’s Title. Not sure why that should only be updated while the user is logged into discourse though?

As for user interactions, (ie associating accounts), why not do this externally?

I admit I have absolutely zero knowledge of the system you’re trying to integrate here, it just seems to me that you’re not actually doing anything to discourse that involves data or systems in discourse.


(Auryn Macmillan) #12

This seems to be the approach a couple of the guys that are writing in it are taking.


(barry) #13

Does anyone know if any progress was made on any such extension?


(Auryn Macmillan) #14

Unfortunately, we abandoned this effort a long while back.
We did have a very early prototype made at one point.
I’ll see if I can track it down.


(Erlend Sogge Heggen) #15

Our Discourse Patreon Integration works in a pretty similar way to what’s described here, albeit for a completely different use case.