[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 "[email protected]". 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

[email protected]"

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: <https://www.youtube.com/watch?v=VxIKy8hyWeo&t=2s>

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 <https://mattermost.com/> 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

<https://github.com/zevlg/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 <https://primedao.eth.link/#/>

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 <https://prosody.im/> An XMPP server, written in Lua and

easily extendable.

+ CryptPad <https://cryptpad.org/> CryptPad is a collaborative office

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

+ Taigao <https://www.taiga.io/> Agile, Free and Open Source Project

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

tracking

+ Jitsi Meet <https://jitsi.org/jitsi-meet/> Open Source Video

Conferencing Solutions

+ Gitea <https://gitea.io/en-us/> A painless self-hosted Git service.

+ Onionshare <https://onionshare.org/> 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 <https://etherpad.org/> Etherpad is a highly customizable

open source online editor providing collaborative editing in really

real-time.

+ PrivateBin <https://privatebin.info/> PrivateBin is a minimalist,

open source online pastebin where the server has zero knowledge of

pasted data.

+ Mumble <https://www.mumble.info/> Mumble is a free, open source, low

latency, high quality voice chat application.

+ PeerTube <https://joinpeertube.org/> 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:

<https://medium.com/1kxnetwork/how-to-grow-decentralized-communities-1bf1044924f8>

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

[email protected]. 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 [email protected]. They can

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

connects to [email protected], 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.

[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