TEST - Research: DAO Chat Bot

Research: DAO Chat Bot

Proposal Information

Proposal description:
research feasibility of a ‘chat bot?’ that would update social media channels (discord, telegram etc) when properties on chain are updated. Such as proposal metrics like CRUD operations on dao properties or even metrics on the status of related tokens

Proposal Rationale
Not everybody is at their laptop and people can subscribe to a specific channel for notifications on mobile if they like, or silence the channel if they want.

Bot could also be open sourced on teCommons github (gitlab for ci?) as the same solution could possibly suit multiple Aragon and 1Hive projects.

Expected duration or delivery date (if applicable):
research needed in order to measure a proper eta. Depending on resources could be 4 days to 3 weeks

Team Information (For Funding Proposals)

here ye here ye calling interested parties (@daithiC is in)

Skills and previous experience in related or similar work:
will reveal itself after some research/measurement. Most likely only web-dev and jsonrpc experience needed.

Proposed Resources

** most likely will be a small app running on a server, connecting to the chain using websockets to watch address’s for specific events, and forwarding formatted messages to a social media channel**

Funding Information (For Funding Proposals)

Amount of tokens requested: 0 xDAI


More detailed description of how funds will be handled and used:
Getting to Venus before Musk gets to Mars.

Nice it passed! Great work!

1 Like

Here is the working document on this project: https://docs.google.com/document/d/1IQhBVIay1y3w6EG7165ryZdRHfUX8uyUIFNDv9nQUoU/edit

Here is the code currently:

its in a branch on a skeleton repo I was creating. Am thinking goroutines are becoming the best option for event based solutions, industry is stuck in nodeJS though (which is personally my main stack).

Also after chat with @kris in discord, it makes sense to have the chat-bot working in Discord as well as Telegram. Am thinking going down this route is the best option and may lead to two instabilities:

  1. Plugin API. Should be extensible to work with all types of DOA’s, eg aragon/compound/ocean etc
  2. Cover multiple ‘social media’ platforms, eg Telegram & Discord

^ also, building out those two points may be ‘cleaner’ in go then in node (mixing ts/vanila/es6 etc).

… another point that has come up in research is whether to use GraphQL (the future) or JSON-RPC (the most available to all users/teams/orgs).

GraphQL (future)
Con: If we use GraphQL (eg thegraph.com) then the application is stuck ‘almost’ vendor locked to thegraph.com etc (good service, crap docs) or alternative. I say ‘almost’ because users can install their own graphQL.
Pro: It links IPFS with the ETH Protocol, basically they handle the logic and we just consume the result.

JSON-RPC (most available)
Con: We might have to do our own IPFS client.
Pro: If we use JSON-RPC (with websockets) then it is easier for a user/team/org to setup a quick client node themselves.

… also, … also; graphQL with thegraph.com is fighting my websocket implementation in go, disconnecting and EOF instead of an error :face_with_symbols_over_mouth: (will need to unpick their wss calls as their docs are just meh lol).

1 Like