rchain-community / rho-bot

MacRhoLang robot on discord
1 stars 0 forks source link

overlap with liquid democracy / rho-bot approach? #3

Open dckc opened 4 years ago

dckc commented 4 years ago

@jimscarver I'm starting to think my o2r approach is more trouble than it's worth given that we have rho-bot.

https://github.com/jimscarver/rho-bot/blob/master/allowalltovote.rho https://github.com/jimscarver/rho-bot/blob/master/allowalltovote.rho

Trusted + Liquid Democracy+ Prototype in RhoLang - Google Docs

dckc commented 4 years ago

I started to review the rho-bot stuff but issues seem to be turned off.

I would want agreement to establish and stick to ocap discipline to collaborate on the code.

I'd like to migrate from require(...) i.e. commonjs to import ... i.e. ES6 modules.

I think we can replace the c preprocessor with a pure-js work-alike: https://www.npmjs.com/package/preprocessor

The use of echo and sed and such seems out of place.

jimscarver commented 4 years ago

I see issues using rho-bot for high security use cases since keeping private keys securely is an issue. I believe we will still need o2r to authenticate coop members. As it stands rho-bot requires private keys for all the users. To fix this each user would need to run their own rho-bot.

I turned on issues in rho-bot. I don't know why they were turned off.

I agree to following the ocaps discipline and ES6. It is the right way. Hopefully I won't have too much trouble working with that. I do worry that could require significant effort to retrofit ocaps on everything.

Getting rid of cpp, sed, etc. would be nice but requires significant effort without improvement to functionality..

The liquid democracy implementation is not anonymous voting it is intended to be a decision making tool which might be validated by anonymous vote later so I'll move this issue to the rho-bot repo.

It may be rho-bot is only well suited for prototyping rholang and we should create browser based apps for actual deployment.