Decentralized Round Table - Openchat Bot

Developers
1

Status: Just an idea
Name: Decentralized Round Table (DRT) Chat Bot
Platform: Openchat & Internet Computer
Purpose: Allowing chat room administrators to transform their rooms into a DAO, by adopting a versatile pet bot. Based on its ability to vote-proxy IC calls the bot will be able to create & upgrade multiple canisters, have a treasury, swap on DEXes, and even become an NFT collector.
Timeframe: A week or two - hackathon-style project. Anyone can join
Scenario: A developer creates OC chat group/server and invites their community to it. They get the open-source bot code and deploy it on the IC. Once deployed the bot joins their chat. The admin adds trusted chat users to the round table and the rest are observers. The trust circle decides to use their new DAO as a Recovery DAO for various projects that like immutability, but aren’t ready for when the cookie crumbles unexpectedly.
Why a chatbot in OC and not a web app: No need to create interfaces. Should be easy to make and fun. Others can see what’s happening & get notifications. Ages well.

Inspired by recent events.

DRT
DRT1920×2728 363 KB

Core Features:

  1. Simple & Versatile: Simple Arthurian governance that can wield immense prowess in its rawest form, culminating in ultimate power.
  2. Immutable deployment: The bot will be deployed as an immutable canister (smart contract) on the ICP. Each server owner deploys their own bot, and once deployed, it is made immutable.
  3. Open-source and contribution-friendly: The bot’s source code will be hosted on a popular version control platform like GitHub, encouraging community contributions and improvements.
  4. OC User identity management: Openchat manages user identities, and the bot trusts Openchat, which is a decentralized DAO itself. The bot starts with one owner, the person who set it up. Additional users must be added and accepted through proposals to participate in the DAO.
  5. Proposal system: The bot has a set of chat commands to create proposals. Default settings require at least 50% of users to vote ‘yes’ for a proposal to pass and be executed. There is a configurable time limit for voting, with a default of 3 days.
  6. Proposal throttling: To prevent spam or malicious proposals, a proposal throttling or rate-limiting system will be implemented, limiting the number of proposals a user can make within a certain time period.
  7. Configurable voting thresholds: The bot allows configurable voting thresholds to cater to the specific needs and preferences of different DAOs.

Chat Commands:

  1. settings: Propose an update of the bot’s settings, such as voting thresholds and time limits.
  2. add user: Propose adding a new user to the DAO.
  3. remove user: Propose removing a user from the DAO.
  4. execute: Propose the execution of multiple IC calls. The proposal includes a text field and a list of commands the bot has to execute. Each command has the following parameters: target canister id, function, and arguments. the target canister ID, arguments, and a hash of the arguments for verification. Users who call this command will receive a token to upload all commands to the bot. Once uploaded other users can start their voting.

Any thoughts? Would you use it?

7 Likes
2

I think this is really interesting. It sounds like your proposal is to use this only as a last resort if something goes wrong with the canister, but I think this could be really powerful as the primary interface for a DAO to discuss and vote on proposals.

Social projects like Taggr actually have an advantage in that they can deliberate on their proposals in-app, but not every app will have social features built-in. Creating something generic that any app could use would really benefit projects and OC has great infrastructure in place for this.

A thought about inviting the community to the group though, I think it would be cool if users automatically gained entry to the group based on their tokens. So users would automatically gain or lose access as they buy or sell their governance tokens. I think this would be easier to achieve if this was deployed separately from OC and the deployment includes the II alternative origins.

I know it’s easy to say immutable, but none of these canisters would really be immutable. No matter what you do, if its deployed on the IC then its possible for it to change. The changes to this page are still a work in progress but there’s more suitable language here: portal/trust-in-canisters.md at e68bd04b0f1d7509b5762a8444dec6f916739a70 · dfinity/portal · GitHub

2 Likes
3

Using a chat instead of a web interface has its pros and cons. Worked for Midjourney. It’s something fun to try and I suppose also allows an app to get more decentralized earlier before it’s ready for the SNS.