DAO Infrastructure Framework (DIF)

[IMPACT] Please describe your proposed solution.

Table of Contents

_________________

1. Overview
2. Communication Channels
3. Off-chain computation
4. Validation
5. Multi-chain
6. Community Owned Blockchains
7. File Storage
8. Pub/Sub
9. XMPP servers can offer a .onion addres
10. HTTP to XMPP Bridge API
11. Issue Centered Chat Rooms
12. Human Coordination Modules (HCM)
13. Onboarding
14. Front End
15. Cockpits
16. People centric design
17. Inter-DAO communication and coordination modules
18. Non-Distributed Services

1 Overview

==========

 The system is a decentralised infrastructure platform that provides

 communication, computing, blockchain services and storage. It can be

 used by individuals, groups, companies or DAO's, installing only the

 modules that are needed for their situation. The system follows the

 paradigm that an Instant Messaging client should be the main method

 that members interact with a DAO.

 It is designed to free people and DAO's from being dependent on

 centralised services. It aims to provide modern digital services even

 to communities who do not have internet access. Impi can also provide

 an onion address for Instant Messaging (XMPP) clients to connect to.

 This provides Tor level of anonymity.

 The system aims to provide all the services necessary for a DAO to

 operate. These services include communication via Instant Messaging,

 access to blockchain services, verified off-chain computation, private

 IPFS storage and private blockchains to store information important to

 the community and other web related services.

 The system is a platform that others can write programs on top of

 without having to worry about communication protocols or validation

 etc. The system represents it's XMPP contacts as PTY's (pseudo

 terminals) on the GNU/Linux base system. This allows programs written

 in any language to communication with the user by reading and writing

 to the appropriate PTY.

 This allows researchers and hobbyists around the world who are not

 blockchain native to experiment with different economies, different

 governance structures, and different ways of coordinating people in

 their favourite language, with full access to it's libraries and

 packages, as well as a full GNU/Linux operating system without

 worrying about worrying about the underlying tech stack or

 insfrastructure.

 Th system is designed to be simple enough to be setup by someone with

 very little technical skill, and be able to offer a range of services

 to their community. The system will be available as a live distro that

 can be burned to a USB flash drive from which a PC can be booted into

 a Live Environment. The live environment is able to immediately

 provide all the services offered by the system, or they can install it

 on the hardware. The installation will be as automated as possible.

 During the entire installation process there is a chat window

 accessible that is automatically connected to a Group Chat full of

 people who are willing and able to assist anyone who is having trouble

 with the installation or just has a question. The system is

 human-to-human communication centric.

 The system provides a natural path for growth. As more people join the

 network, the more secure the system becomes. What starts off as a

 single computer can evolve into infrastructure that the community can

 rely on, regardless of which members come or go. It is up to the

 community themselves to decide how much security they need for their

 network and their needs. The more nodes that are on the network, the

 higher their level of security.

 Instant Messaging is the primary method of communicating with the

 system. Using something as simple as instant messaging decreases the

 amount of new things that a new member needs to learn. By using an

 interface that people are already familiar with, we are able to

 provide them with access to the benefits of web3 technology.

 The text based nature of instant messages medium makes writing

 interfaces much simpler and quicker than writing HTML base interface.

 The DAO's computing interface is represented by a bot on the XMPP

 network known as the receptionist, and generally has an address

 similar to "receptionist@cardano.org". The Receptionist can either be

 a bot, or the communication can be routed to someone in the DAO who's

 shift it is at that time to greet people and point them in the right

 direction. The direction that they get pointed to might be another DAO

 member, or a service bot.

 Receptionists are just Service Bots with a certain collection of

 features enabled, which is entirely customizable.

 If the system is used by a single person, their bot is called a

 Personal Assistant (PA), which is completely customizable by them, and

 acts as a "Digital Ironman Suit" to take care of all the unproductive

 actions that need to be taken on the internet just to interact with

 different systems.

 A PA can execute any system command (if permitted) on the user's

 machine, allowing for endless possibilities, and remote control of

 one's computer or server. For example, a user could message their PA

 "Send 50 ADA to John". This will then run the appropriate

 cardano-cli command or send a JSON message to an Ogmios bridge to

 send the ADA. TOTP could be added ontop for extra security if need be.

 XMPP is federated, like email, in that anyone can start an email

 server (or join an existing server), and it's users can communicate

 with any other email server's users. There is no central point that

 can be controlled. If one is shut down, another can be started.

2 Communication Channels

========================

 The programs can communicate directly with users via instant messages,

 and vice versa, without having to worry about the technology stack

 underneath. Each user or group chat becomes a PTY on the system.

 Programs can pipe in and out of PTY. This allows a programs to easily

 interact with groups of people, possibly coordinating their efforts to

 achieve a certain goal.

3 Off-chain computation

=======================

 The off-chain computation is provided by the nodes that run the

 system. The computing environment is a complete GNU/Linux system. One

 node does the computation and the others verify that the results are

 correct. Nodes are incentivised to act honestly.

4 Validation

============

 When Impi is running on more than one machine on the network, the

 system can perform verified communication and computation. This means

 that the system can run ordinary trusted code in a trustless

 environment and obtain a certain degree of assurance that what is

 being represented is in fact true and correct. The more machines that

 are connected, the higher the degree of assurance. This allows

 computation from ordinary non-smartcontract code to be verified. This

 would allow an entire governance system to be written in Python for

 example.

 To verify the communication and computation automatically, all data

 between stages move through group chat rooms. This allows multiple

 nodes to observe what data is being sent as input, they can run the

 same computation themselves, and then they can validate that the

 answer given is in fact the correct answer. If a node provides

 incorrect data, they are penalised.

 This is how Chainlink works, which is one of the options to secure the

 system. Unfortunately Chainlink is not available for Cardano yet.

 Until it does become available for Cardano, or an alternative is

 found, the system can be secured on the Ethereum network for scenarios

 that require that form of security.

 The long term goal of the project would however move to more of a

 local reputation system, instead of using the dollar's reputation.

 Reputation could dictate how often you get selected to perform a task,

 and hence how much you earn.

5 Multi-chain

=============

 Impi is multi-chain. It's connects to blockchains either via a Rosetta

 driver module, or via a chain specific driver module. Currently a

 driver would entail Chainlink Network Nodes that verify the data going

 to and from the blockchain.

6 Community Owned Blockchains

=============================

 In addition to connecting to blockchains, Impi can run it's own local

 blockchain of it's choice (if it has the drivers). This allows a

 community to have access to whatever smartcontract functionality they

 want and are able to keep a record of what is important to the

 community (for example the daily temperature can be recorded on a

 community blockchain), and have that functionality at a very cheap

 price, if not free.

 The local blockchain can perform transactions between community

 members on the local chain, and only speaking to the main chain when a

 transaction needs to interact with a mainnet contract or address. Each

 Impi basically becomes a side chain to your main chain of choice. This

 kind of scenario would be perfect for a town for example. All real

 world transactions are kept local, cheap and fast and decrease the

 load on the main chain.

7 File Storage

==============

 A private IPFS network will be used to provide file storage for the

 DAO.

8 Pub/Sub

=========

 Pub/Sub stands for Publish/Subscribe. It allows users to subscribe to

 published events. For example, A user's PA can be set to watch for any

 deposits in a certain wallet, and then use Pub/Sub to send anyone who

 is interested in that wallet a message with the deposit details.

 A DAO could do something similar and place a Pub/Sub watcher on their

 treasury wallet, and all those in the DAO that need or want to keep an

 eye the treasury can subscribe to that Publication. Under what

 conditions the message is sent can also be personalised, for example,

 a certain user might only want to be sent a message if more than a

 certain amount is transferred, or more than a certain amount of

 transactions have occurred within a certain amount of time. Another

 Pub/Sub could be created for an AI that watches for any anomalies on a

 wallet.

 The Pub/Sub model allows a DAO to create their own minnie twitter

 amongst their community members, that filters content and follows

 rules set out by members of the DAO itself. THe DAO's XMPP server can

 connect to any other DAO's XMPP server, allowing minnie twitter

 spheres to join into one large twitter sphere, where communities can

 express themselves freely, but can regulate themselves, and allow

 others to do as best suits them, but at the same time, be able to get

 each other's feeds if they so choose.

9 XMPP servers can offer a .onion address.

==========================================

 This allows for a convenient setup where only your XMPP client

 connects to the onion site through a Tor bridge and all your other

 traffic can flow like normal without any need for a system

 configuration change. Any program that needs to communicate

 anonymously can use the XMPP http api to route their traffic through

 the XMPP/Tor tunnel. Even though the XMPP server connects to it's

 clients via onion, it's XMPP side is still on the clear web with a

 normal JID (Jabber ID). This would allow a DAO to present it's

 receptionist to the clear web, and allow it's members to connect

 completely anonymously, whilst at the same time allow any user from

 another normal server to communicate with the user that is anonymous,

 as well as allow the normal user from the other server to utilise the

 services offered by the DAO (or not, perhaps they are offered

 different services, DAO's choice)

10 HTTP to XMPP Bridge API

==========================

 In addition to these features that the system brings to a single user

 or a DAO, it also provides an HTTP API for external programs to

 interact with the DAO, or the users. For example, instead of Ideascale

 sending an email to all the Catalyst members, they can call the Impi

 API with their message and the group name, and assuming someone in the

 DAO has given them authority to do so, all members will be sent the

 message.

 Members can reply directly to messages sent from the DAO to provide

 their feedback. For example, there could be a proposal that needs to

 be voted on. Ideascale can use the appropriate API to send the

 proposal to the appropriate members. Each member will receive a

 message from the DAO's receptionist containing all the details about

 the proposal, as well as the proposal itself. Each member can then

 read the proposal quickly whenever they have a spare moment available

 and reply directly to the message with a yes or no. The response will

 be sent back to Ideascale as their voting response.

11 Issue Centered Chat Rooms

============================

 A user, or a group of users who are responsible for a system could for

 example have their error logs messaged to a group chat so everyone who

 is interested can join the group chat and be kept up to date with the

 system state. This automatically creates a place where there users can

 coordinate on fixing the issue, as well as allow certain users to

 issue shell commands directly in the chat so that everyone can keep an

 eye on the progress.

 To enable the logs being sent to a group chat, a user only needs to

 run something like "tail -f logfile | xmpp-bridge

 operators@cardano.org"

12 Human Coordination Modules (HCM)

===================================

 Human Coordination Modules coordinate the completion of a collection

 of tasks by the members of the DAO.

 For example, lets assume there are 10 proposals and 100 users. Each

 proposal needs to be assessed by at least by 5 people. Ideascale can

 call an API, pass the system the lists of proposals, and the users

 that are participating, and the system will send each proposal to 5

 members. The members can then rate the proposal by responding directly

 to the message that contains the proposal. Once a member is done

 proposing, they are sent another proposal to validate if there is one.

 If one of the members does not respond within a certain amount of

 time, they are sent a messsage saying their window has closed and the

 proposal is sent to the next member to assess. This could easily be

 changed if you were not on a strict budget and didn't mind having

 additional responses.

 This continues until all the proposals have been evaluated. This saves

 the member having to go to the website, find the proposals, then find

 a proposal to review, review it, and then send the response. The

 system ensures that the next action that the member needs to take is

 ready to be accessed by them whenever they have a gap in time without

 having to waste time and mental effort in getting ready. They only

 have to open a message. The system is designed to be flexible and

 extendable, making it easy for additional coordination modules to be

 added, tested and used. The modules can also be written in any

 language.

 An example of what such a coordination mechanism might look like is

 the Real World Auditor. There is a video showing the flow of the

 system here:

13 Onboarding

=============

 A training module can be used to onboard new users who might not be

 familiar with using text messages as a way to interact with systems,

 as well a teach them how to interact with the DAO, or organisation

 using text messages. As they progress though the program, they gain

 access to more and more commands, access and privileges. And becuase

 it's just Instant Messaging, if a new user gets stuck, or doesn't

 understand something, they can use the help command, which will find a

 more senior DAO member to join the chat and to help the new user out.

 The system allows for as much automation as one wishes, but with the

 option to have people on hand to guide and help when it is needed.

 Besides onboarding and retaining more member, it helps prevent people

 feeling lost,isolated and alone in their digital experience.

 The system is designed to hold peoples hands from the beginning, only

 giving them access to facilities that they have learned about and

 played with in a sandboxed environment. My hope is that this assurance

 that they can't break anything, and that they can play with it in the

 sandbox as much as they want with no consequence, combined with a

 coach on hand that will show you the ropes, that they will be able to

 relax into the system knowing they are safe. Education is key, as many

 older people, and people who come from a disadvantaged background who

 struggle with technology, they land up being prey to scam artists and

 thieves.

14 Front End

============

 Because XMPP is an open protocol, any XMPP client will be able to

 communicate with the server.

 However, MatterMost is an Open Source

 alternative to slack or discord. We will do an investigation into

 whether it will be possible/viable to fork the MatterMost front end

 application and modify it to use XMPP as it's communication protocol.

 The modification will result in a open source and federated

 alternative to Discord and Slack in a nicely packaged client that runs

 on Windows, Mac, Linux, Android, iOS and has a Web Client. If it is

 deemed viable, we will create a proposal to do the conversions in a

 future fund.

 Another investigation will be done into creating a package for Emacs

 that by default mimics the layout of Discord and offers the same

 functionality, except it has Emacs super powers and is text based.

 This could be done as a fork of telega.el

  which is an Emacs Telegram

 Client. We swap out the comms backend to use XMPP and create a few

 layouts that are in the style of Discord/Slack/Mattermost. A

 preconfigured plug and play version of Emacs with the package can be

 sent to members by the DAO's receptionist when they join the DAO, or

 whenever they request it, or they can get it from the DAO's IPFS.

 At the same time, the Emacs Application Framework will be investigated

 for it's ability to integrate PyQt programs into Emacs. This framework

 promises to empower us to create graphical front ends for Emacs. This

 should allow us to mimic Slack / Discord / Mattermost's interface

 almost exactly. In addition, it creates a possible path to offer all

 the services offered by Impi to be accessible from within Emacs, and

 make Emacs look like a modern application. If deemed viable, it too

 will become a proposal for a future fund.

15 Cockpits

===========

 The X in XMPP stands for extensible. The protocol is designed to be

 extended so that it can suit growning needs. A investigation into

 whether a plugin for XMPP that allows a Window Layout to be suggested

 by bot or chat room is a viable idea or not. This will allow

 communities to choose what and how information is shown to it's

 members. In essence, it a pluging to relay a cockpit configuration. If

 the cockpit requires programs or files, the extention will offer a git

 url, or transfer the files directly. This does present some obvious

 security vulnerabilities which will need to be addressed.

 A default layout could make a client application look like discord for

 example with the server list on the far left, then a column with the

 rooms in it, then a big chat window in the middle, and then a column

 on the right that shows who's online.

 A certain DAO might want a news feed to be on the right, and a chat

 window on the left. XMPP is extensible enough to allow this

 functionality to be added in the future.

 If found to be viable, this will become a proposal in a future fund.

16 People centric design

========================

 At any point in any conversation, or interaction with a smart contract

 for example, a user can can execute the help command, which will then

 instruct the system to add another user to the Group Chat. The user

 will be someone who can either offer direct assistance, or will know

 who to contact to find the assistance that is needed. They can also

 teach the user if they are new or are battling with a certain part of

 the system.

 This is the advantage of using XMPP as a method of interacting with

 other protocols. If you get stuck or are unsure of something, you can

 always request assistance and someone can join you in your chat and

 help you out. You can choose how much of the history you want them to

 see, or you can choose for them to see nothing, the choice is yours.

17 Inter-DAO communication and coordination modules

===================================================

 Modules can be written in any language to experiment with what DAO to

 DAO communication and collaboration could look like in a low

 consequence environment.

 DOA to DOA communication and cooperation is being investigated by

 groups like PrimeDAO

18 Non-Distributed Services

===========================

 The system also provides non-distributed services. These are run on a

 single node at a time, but all nodes are able to offer the service.

 Load balancing will split the load amongst the nodes. The data is

 stored on IPFS when possible, else the data will be backed up using

 rsync until an IPFS solution can be found.. All the services are open

 source. Here is a list of the services that will be initially included

 in system:

 + Prosody An XMPP server, written in Lua and

  easily extendable.

 + CryptPad CryptPad is a collaborative office

  suite that is end-to-end encrypted and open-source.

 + Taigao Agile, Free and Open Source Project

  Management Tool It offers Kanban boards, Gantt charts, Issue/bug

  tracking

 + Jitsi Meet Open Source Video

  Conferencing Solutions

 + Gitea A painless self-hosted Git service.

 + Onionshare OnionShare is an open source

  tool that lets you securely and anonymously share files, host

  websites, and chat with friends using the Tor network.

 + Etherpad Etherpad is a highly customizable

  open source online editor providing collaborative editing in really

  real-time.

 + PrivateBin PrivateBin is a minimalist,

  open source online pastebin where the server has zero knowledge of

  pasted data.

 + Mumble Mumble is a free, open source, low

  latency, high quality voice chat application.

 + PeerTube PeerTube aspires to be a

  decentralized and free/libre alternative to video broadcasting

  services.

[IMPACT] Please describe how your proposed solution will address the Challenge that you have submitted it in.

DAO's are tricky to get right. The whole concept is new, Discord is new

to many people, users/members are generally still trying to figure out

this whole web 3 thing. Plus information is scattered everywhere across

multiple centralised services.

It's easy to get lost, and every DAO is different with different

interfaces, utilising different technologies. This creates a massive

learning curve for anyone trying to get into this space, or just

participate in a DAO.

Also, some people are shy. They might have a question but don't want to

ask it on a public channel in fear of looking stupid or ignorant, or

worried someone is just going to say that they should google it first.

This massively decreases their ability to get involved and contribute to

the DAO.

This solution provides a familial text instant message interface, with

more one-on-one assistance to members that prefer not to be too active

in public channels. The member can message "help" to the DAO's

receptionist bot and they will be connected to a more senior member of

the DAO to assist them, whether that's teaching them how to perform the

action they wish to perform, or pointing them to documentation, putting

them in contact with someone who can assist more, teaching them how to

phrase their question so that they can ask it on a public channel on the

subject, or just giving them the answer to their question.

The members who are assisting the new members are members who have been

around for a little bit and know the basic ins and outs of the DAO and

system.

Because programs for DAO's can be written in langauge, more people are

able to participate in writing tools for DAO's. You could run it as a

Jupyter Notebook if you wanted.

A basic DAO template will be provided for the system. The template will

provide tools to the DAO that support flows similar to what is described

in this document:

An example would be to provide a way for a new member to self signal

that they wish to contribute to the DAO. This involves them getting

involved in DAO activities. One such activity is assisting new users.

This serves three purposes.

1. No one ever gets stuck somewhere in the syste

  meaning you don't know how to do what you want to do with the system,

  could result in the new user getting frustrated and abandoning the

  system. Always having a human on hand to come and assist them if need

  be could help ease people into a new way of doing things and keep the

  retention rate as high as possible. This also helps make technology

  more human centred.

1. It provides the member assisting the opportunity to be asked a

  question they don't know the answer to. This allows them to learn

  more about the DAO and the system in a much more broad sense than if

  they were to just go and find out things on their own.

1. It provides a new kind of employment for the digital worl

  shop wants to have an online shop available on the XMPP network. They

  create their receptionist bot, with the address

  receptionist@cookieshop.com. They don't want to be dealing with

  customer queries themselves, because they believe technology should

  make your life easier, not consume all of it. They want to spend

  their time making cookies. What they can do is install the system and

  set up a receptionist bot at receptionist@cookieshop.com. They can

  have a pool of people that are looking for work. Whenever a client

  connects to receptionist@cookieshop.com, the chat is routed to one of

  the people that are looking for work. They then interact with the

  client on the cookie shop's behalf. You can enable a feature to allow

  two other people to join the chat and just observe. They ensure the

  person interacting with the client does so professionally and gives

  them the correct information.

There is also the ever present risk of censorship that comes with

relying solely on a centrally controlled service such as Discord,

Discourse or Telegram. If for whatever reason your Discord server gets

shut down, how do you reconnect with your members. There is no way to

re-establish the same kind of connection again. Some of the members

might re-group through Telegram or Discourse, but you are going to loose

a fair percentage who might not be actively involved, but would still

like to stay up to date with the project in case they need it in the

future. But the main hurdle in getting a DAO back up and running again

after a ban from something like Discord for example is implementing a

replacement and getting people to start using that service or app. Where

do you go? Slack? This new service then involves new applicatoins,

another learning curve, wasting all your member's time.

XMPP is federated, like email, in that anyone can start an email server

(or join an existing server), and it's users can communicate with any

other email server's users. There is no central point that can be

controlled. If one is shut down, another can be started.

[IMPACT] What are the main risks that could prevent you from delivering the project successfully and please explain how you will mitigate each risk?

The main perceived risk is Chainlink not becoming available on Cardano, or taking a

very long time. The current plan relies on Chainlink to provide validation

services to the network. Due to the design of the system, with the validation

engine being a module and the validation itself is abstracted away from the rest

of the system, the rest of the system can be developed in the interim. If

Chainlink never comes to Cardano, then another Oracle and validation solution

will need to be found.

I have not tested HTTP-over-XMPP api yet. This API needs to be investigated

further to find out how viable it actually is for use. This feature is a

nice-to-have for the system and is not on any critical path. If it does not work

correctly, the services offered by the DAO could be presented on onion sites to

help with member privacy.

[FEASIBILITY] Please provide a detailed plan, including timeline and key milestones for delivering your proposal.

Milestones reached by end of month

Month 1:

• Provide a GNU Guix configuration that forms the base of the system.
• Implement containerization system to allow programs to run independently and safely on the host node.
• Architural Diagrams and Documentation
• Investigation done into viable Cardano Oracle solutions

Month 2:

• XMPP clients represented as pseudo terminals (PTY)
• Configure the system to log each new XMPP connection in as a user system user. This could require a password if required. This linux system manages access rights of users and groups for services and resources on the system.
• Understand what is involved in developing a Gajim pluging and creating an XMPP extension.
• A docker container is created as the initial deployment mechanism. This might change to Vagrant. Others will be added later.

Month 3:

• User Flow Architectural Diagrams and Documentation created
• Create a test framework that provides the developer with a suite of tools to mimic real world scenarios. It will consist of a few building blocks that developers can use in their own code. The initial suite of building blocks will consist of:
• XMPP bot accessible via sockets. The bot will perform whatever action is  piped to it through the socket. This is called a Puppet Bot (PB). It allows a generic interface to any bridging application. An example would be an XMPP-to-Email bridge, or it could represent the system in a Group Chat that is used to decide who's doing the next computation.
• Parametric Bot Action Templates for different types of actors that can be  piped to a Puppet Bot to execute the instructions. Besides being usefull for testing, it provides a framework that can be used to perform repetitive tasks.
• A Personal Assistant service bot for users. This is a framework that allows a user to create custom commands to instruct the bot to perform certain actions, or put certain play books into action. An openssh server could be used as service that a PA offers to it's user.
• Create an ssh client plugin for Gajim or another XMPP client that allows auser to log into a remote ssh server using the messenger client as their terminal.

Month 4:

At the end of this month, system management programs and usability features will be added to the system. These programs are designed around using Instant Messaging as the primary method of communicating with the user. The programs will provide basic functionality to the system, and serve as the building blocks for more complex systems. The GNU/Linux system handles all the access control and privileges, and provides read and write access to a user's instant messenger application via pseudo terminals (pty).

Stdin and stdout will be routed by default to the instant messaging user that started the session. This allows normal programs to communicate with a user over XMPP without even realising it. This will hopefull allow more developers to experiment with writing modules as they don't need to learn anything new if they can already program, as well as giving someone access to the entire GNU stack for dealing with users.

 The tools that will be written are:

• Flexible and generic menu system that is configured with Org Mode files
• Sysadmin service bot that provides access and tools to a sysadmin to manage and maintain the entire system.
• An XMPP extention, server side application, and a client extention to provide auto-complete  functionality, populated over XMPP, either directly or via a Jingle session.

Draft system setup and configuration documentation

Month 5:

This month, the following modules will be made available.

• Onboarding and Training Module
• Truth Verification Module
• Human Coordination Module (HCM)
• Task Coordination Module
• Voting Module

IPFS integration will be complete.

Month 6:

• Online Shop Module
• Project Management Module
• IPFS Explorer Module
• Generic monitoring, logging and alerting Module
• Blockchain monitoring and alerting Module
• Blockchain Access and Smartcontract Interaction Module

Month 7:

• Oracle integration
• Live Distro Release
• Arch package release
• Ubuntu/Debian package release
• Draft User Manual

Month 8:

• Documentation for everything
• Man pages

Month 9:

• Map out future road map
• Project plan for road map
• High level system diagrams and documentation for road map
• Investigated feasibility of using MatterMost as a front end.
• Investigated feasibility of Emacs as a front end.

[FEASIBILITY] Please provide a detailed budget breakdown.

Lead Programmer at $70 - $100 per hour

160 hours per month = $16 000 per month

Technical Lead at $100 per hour

160 hours per month = $16 000 per month

Junior Dev at $40 - $70 per hour

160 hours per month = $11 200 per month

Developer Cost per month:

$16 000 + $16 000 + $11 200 = $43200

Developer Cost for 9 mont period:

$338 800

Hardware for experimentation : $12 000

Total Cost: $400 800

[FEASIBILITY] Please provide details of the people who will work on the project.

Roger van Schie

Tech Lead, System Design, System Configuration, System Packaging, Programming.

Lead Programmer Wanted

Looking for a lead programmer with Plutus experience to do project management, implement a Chainlink Oracle or something similar, write the Gajim plugin, and help with the modules.

Testing and Documentation Programmer wanted

Looking for a programmer to write tests and documentation.

[FEASIBILITY] If you are funded, will you return to Catalyst in a later round for further funding? Please explain why / why not.

Yes.

There are several investigations that will take place during this project, such as whether it is viable to use MatterMost's front end to create a Discord alternative based on XMPP. The outcomes of these various investigations will dictate which proposals will be submitted in future rounds.

[FEASIBILITY] Are you or any member of your team working on any other proposals in this Fund9?

[FEASIBILITY] Are you or your team working on any other proposals from previous Funds?

[AUDITABILITY] Please describe what you will measure to track your project's progress, and how will you measure these?

The milestones mentioned in the project plan will be tracked to gauge project progress.

[AUDITABILITY] What does success for this project look like?

An easy to setup, easy to use, intuative DAO infrastructure that allows communities to communicate, coordinate and thrive, even in the most remote locations on the planet, whilst providing them access to modern robust and reliable Web3 services in a way that is easy and familial even to those who struggle with technology.

To provide a framework that makes technology work for it's users instead of it's users working for it.

[AUDITABILITY] Please provide information on whether this proposal is a continuation of a previously funded project in Catalyst or an entirely new one.

No