mariapao
commented
5 years ago Hi @JoseOspina thanks a lot for submitting your proposal. This is an ambitious and interesting project. However, it might not be a fit for the program for the following reasons:
-
The funding range of nest is between $50K and $150k. Proposals and or requests for funding that fall below that range are handled through bounties.
-
You say:
If deemed appropriate, the Ethereum implementation of _ could include a native governance token. If so, an ICO could be conducted and the Aragon NEST fund could receive pre-mined tokens.
Is the token key for the protocol? In any case, Nest is a grants program, not an investment fund. We fund public infrastructure and dev tooling. The program doesn't fund pre-ICO projects or startups.
I wonder if there is a way to simplify this project? Other than the validation of the proposal ($20k)
pepoospina
_ protocol
like GIT, but for conversations and ideas
Table of Contents
Abstract
Organizations are conversations and thus, new types of organizations will need new types of communication tools.
Platforms for digital conversations, from WhatsApp or Telegram groups to Slack workspaces or Discourse forums, are already changing the way people organize together. In addition, when used in combination with "shared content" platforms like Trello or GSuite, they are creating new patterns of collaboration and co-creation.
CollectiveOne's is developing "_" (just an underscore *), a communication and co-creation protocol (not just an app!) that enables people to
_ generalizes and extends the communication and content creation patterns typical of conversation and content co-creation tools by adding three new functionalities:
is designed to be a powerful tool for open, distributed and cross-border collaboration. Its vision is closely related to the vision of the Aragon network, which is why we think there will be interest within the Aragon ecosystem to help make a reality.
The links with Aragon are very clear: #contexts should have the possibility of gradually evolve into Aragon organizations. And, at the same time, Aragon organizations should have the possibility of using as a communication, governance and content co-creation tool.
A prototype showing the basic functionalities of #contexts as a flexible tool to organize and aggregate conversations and content is openly available at www.collectiveone.org. A first draft of the specification of the _ protocol can be found here.
This proposal to the Aragon NEST program is framed as an answer to the issue better communication tools for effective governance #49.
The scope of is a bit broader than the one specified in the issue. However, distributed governance is hard and is the simplest, yet complete, set of features that, in our opinion, are needed to start cracking the problem. We dont think governance is a problem about voting, but a problem about communicating.
* The name is purposely the closest thing to not having a name. In , the name of channels and documents is also part of their content, and thus, in each user can rename them the way they want. You can rename as you please.
This proposal was developed using the current proof of concept of the _ protocol. You can check it here. There is also a slides deck available in case you would like to have a fast overview of the concept.
Deliverables
Grant size and Timeline
Eventually, USD$320k, 70% ETH 30% ANT, but starting with just USD$20k to validate the proposal.
Payment is split into chunks paid out over achieved deliverables. If deemed appropriate, the Ethereum implementation of _ could include a native governance token. If so, an ICO could be conducted and the Aragon NEST fund could receive pre-mined tokens.
(Note: All these specifications will naturally be the result of many proof-of-concept developments, also provided in the delivery)
September 2019 ($150k)
January 2020 ($150k)
Detailed description of _
CollectiveOne's is developing "_" (just an underscore), a communication and co-creation protocol (not just an app!) that enables people to
Human civilization is built on top of communication technologies, and _ opens new ways in which people can communicate.
Moreover, if powered by cryptography-based platforms (like Ethereum or RChain), it can radically change the playing rules with which a person can participate in the society, either by influencing his or her immediate surroundings and organizations or by participating of more distant political participation processes.
These, of course, are big words. However, if you think about it, the power of a piece of written text can be astonishing, depending on things like:
As a provocation, consider what else is the legislative branch of the government other than a collaborative document edition process, or what else is the executive branch of the government other than the only one with write access to the official government's gazette.
In summary, if you have a new process for creating content with new, previously unexisting, possibilities, it's natural that you will get new, previously unexisting, ways in which the society organize itself.
Governance is not about voting, its about communicating.
Platforms for digital conversations, from WhatsApp or Telegram groups to Slack workspaces or Discourse forums, are already changing the way people organize together. In addition, when used in combination with "shared content" platforms like Trello or GSuite, they are creating new patterns of collaboration and co-creation.
_ generalizes and extends the communication and content creation patterns typical of conversation and content co-creation tools by adding three new functionalities:
1) It introduces the concept of #contexts and their interconnections to facilitate conversations and content creation at scale. 2) It adds a version control system for each #context similar to GIT that facilitates multiple perspectives on a piece of content to coexist and nurture each other. 3) It includes formal governance processes that can be used to update the content of these #contexts.
1) It introduces the concept of #contexts
A #context in _ is a conversation channel and/or a content container, and it can be linked and nested relative to other #contexts with a few key characteristics:
The content of each #context can be of three different types: messages, cards, and assets.
A few examples of how teams are already using #contexts are:
The power of _ is that users can flexibly create #contexts to have conversations or hold content (or both) and nest these the way they want.
This would be like having a Slack with channels and sub-channels or a Trello with sub-boards. But is not just that, it also allows things like having one slack channel present in two different workspaces, two boards in Trello to have one column in common, or one section or paragraph in a Google Doc, to be present in two documents. In addition, each Trello board is also a Slack channel and a Google Doc section, for free.
To compensate for this level of flexibility and the complexity that might derive from it, the user interface has two key functionalities:
2) It includes a version control system
On top of this generalized concept of #contexts, in _, the static content in a #context is added as batches of increments similar to how GIT works, so that users can easily branch the contents of a context, perform some modifications and eventually recombine these with the original branch. The power of this is that of having, with a minimum overhead, multiple coexistent perspectives on one #context. We think this can boost co-creation of ideas, just like GIT branches boosted co-creation for code.
Some examples of how version control and branching could help content co-creation and governance are:
One important aspect of version control for _ #contexts is that they are intended to be nested and flexibly interconnected among them. The logic used by GIT for version control of files needs to be extended to handle a network of repositories of data (not files), each usually having many links to others in a flexible manner.
Monotonicity is key for software development, but it does not fit well for ideas. That and the fact that is not focused on files is why cannot be implemented using GIT itself but requires a new implementation.
3) It includes governance rules
The combination of #contexts to create scalable sets of content and conversations and the possibility of having multiple perspectives on them is also an extremely powerful tool for effective distributed decision-making processes (also referred to as governance). For this, users can have configurable “governance rules” per #context such that one perspective requires, for example, voting to accept “pull requests” from other perspectives.
Other alternatives for governance rules include liquid democracy (vote delegation per #context) or quadratic voting.
Voting features are part of _, but only at the latest stage of a co-creation process. We think that thanks to the existence of #contexts, proposals and decisions are automatically contextualized (hence the name) so that they can be both complex and very concrete at the same time. This is similar to how pull requests work for code co-creation and is a powerful tool to focus discussions around their practical implications.
#Contexts and Unstoppable Organizations
The links with Aragon are very clear: #contexts should have the possibility of gradually evolve into Aragon organizations. And, at the same time, Aragon organizations should have the possibility of using as a communication, governance and content co-creation tool.
The vision of CollectiveOne is that of having very flexible and cheap ways for creating "organizations". In fact, we would like the "organization" concept to vanish a little bit. Our vision for the future of the Aragon network is that of an ecosystem of unstoppable organizations with complex and extensive interconnections among them, instead of being isolated giant tribes competing with each other. We have nothing against competition, but we think that competition should be between different concepts and approaches and preferably not between groups of people.
Accordingly, we would like Aragon to provide tools for the interaction and interconnection of open "organizations", and not just to focus on recreating "old style closed organizations but in the blockchain". For this, we think that the process of creating an organization should be very cheap. In fact, we propose that a "slack channel" or a "shared google document" can be the starting point that gradually evolve into "an organization" as formal governance processes and value recognition systems (tokens) are added to it.
Current State
We have a web 2.0 MVP that enables users to create #contexts, freely interconnect them, and hold conversations and add content to them as explained above.
This prototype is online since July 2018 and we are now starting to test it on a few organizations willing to play the role of beta testers. No revenue has been generated, yet.
Based on the feedback we are receiving from the beta testers, the current prototype already seems like a good alternative for Slack and Trello and even Google Docs. We are already starting to refactor the code to include version control systems and governance processes as described above.
It is a prototype also in terms of technology because DB queries in CollectiveOne are relatively complex and the current solution will require further improvements to be scalable.
The figure below shows the current prototype as it is being used to describe the #contexts specification.
Regarding implementation on decentralized technologies, _ is a protocol that enables the content to be stored on different platforms, even if updated independently of each other, but without losing the connecting points that would enable future recombination of the content.
This is similar to how GIT works, where one repository can live in many different local machines and remote servers at the same time.
_ contents can, therefore, be stored both on web 2.0 technologies that focus on flexibility and privacy, and, also, on decentralized web 3.0 networks that give additional meaning to the content of some #contexts and their governance processes thanks to their decentralization and immutability,
Looking to reimplement GIT may sound very ambitious, but it's actually well within reach. The power of git relies also on its simplicity and, as a proof, you can find reimplementations on many languages like Javascript, Go, Python.
A bigger challenge is likely going to be extending the protocol to focus on a network of interconnected repositories and not just one root folder.
We have kept aside the development in web 3.0 networks for some time for a few reasons:
However, because the protocol design is starting to become more clear, and new web 3.0 platforms are emerging that seem to be better at handling applications with large sets of data (like Ethereum 2.0 or RChain), we are now willing to start developing and testing on these platforms too.
How it solves Aragon NEST issue #49
This proposal to the Aragon NEST program is framed as an answer to the issue better communication tools for effective governance #49.
In this section we provide an example of how contexts and perspectives can help discussions and governance within Aragon organizations.
Using #contexts
The figure above assumes that #contexts are already being used within the Aragon One organization.
#Aragon One is itself a #context that, at the same time, is backed by an Aragon smart contract (that's why it has the Aragon shield mark). Other visible #contexts like #Pando or #Planning App are also Aragon organizations backed with smart contracts and have their own governance, tokens, etc. The rest of contexts are powered by a standard web server.
Links to #subcontexts of a #context are just content of that #context, and thus they are associated to a perspective. There is a perspective of #Aragon One, let's call it "official" which includes the official #subcontexts (links from this perspective are marked in blue).
* Note that one #context (#Liquid Democracy) is a #subcontext of two other #contexts at the same time, so there is no need to find the perfect hierarchical decomposition.
* Note there is a #context called #My Aragon with a single perspective that is private. This context was created by the current user and is used to keep track of the #contexts relevant to him or her.
* Note that the fact that #Aragon One is the top #context is arbitrary. Other users might prefer to have other #contexts as their top ones without being forced to having to see or listen to other parts of #Aragon One.
This is important because it highlights the fact that all #contexts are equal. There is no special level called "organization", or "project", or whatever, as is the case in almost all other collaboration tools. Everything is a #context.
Now imagine Luis decides to make a proposal by adding a new perspective to the #Aragon Governance #context (this branch is marked in green). Lyricalpolymath sees it and makes a few variations of the proposal by branching it again into a new perspective and modifying some paragraphs.
The discussion goes on while the proposals are clear and evolve. At some point, Luis decides to merge some of the portions of Lyricalpolymath's perspective in his own.
Eventually, the team can vote which perspective is merged into the "official" #Aragon One one. In any case, perspectives need not be deleted after the vote, and the different perspectives can coexist as long as deemed useful.
Running Actions
Issue #49 ask for the possibility of having discussions around a given action.
Our proposal to solve this problem is to allow Aragon actions to be added as part of the content of a #context and, so, special logic will run the actions once a perspective is merged into another branch.
Continuing with the previous example, imagine that the work with the #Aragon Governance proposal evolves and, at some point, it is necessary to write the formal legally-binding agreements that represent the agreed governance.
This is a professional work that needs to be paid. For this reason, Luis adds a new perspective in which he adds a new #subcontext named #Legalization, include some text to it and attach two actions (why just one?). He then proposes to merge that branch into the "official" branch.
Merging to the "official" branch will require a vote, which in this case, if successful, will trigger the actions.
So this is it! We had to introduce the concept of #contexts, version control and governance just to reach to this point!
The key difference with this approach, compared to just adding arguments "for" and "against" a given action is that the discussion about whether or not to run the action is not held around an independent issue of the type "transfer 10,000 ANT to 0X5464165", but is held within the #Legalization context chat, and so all the history and process that lead to that point can be derived from the rest of the content of #Aragon Governance, making it easier for others to participate in the decision.
Team
Open Project
We propose to create an Aragon organization and use an internal token to recognize contributions for the development of . The tokens would be minted and given to contributors of , and will be then redeemable for the funds allocated to the project by the Aragon NEST fund as milestones are reached.
Base team
Pepo Ospina
Founder and core developer of CollectiveOne. Electronic Engineer with a Ph.D. in dynamic control systems, full stack web developer and B9Lab certified Ethereum developer. Fully committed to make the goals of _ a reality: soon and no matter what.