Initial documentation

.gitignore

@@ -0,0 +1 @@
+/.idea

README.md

@@ -0,0 +1,23 @@
+# The Grid
+The Grid is a fork of the Matrix protocol with a different set of core values and a true community management.  
+It aims to be care more for privacy and much more friendly to self-hosted infrastructures.
+
+## Status
+We are currently putting it all together before official kickoff.
+
+See the [Sunrise](https://gitlab.com/thegridprotocol/home/milestones/1) milestone for the current progress.
+
+## Documents
+The following bootstrap documents explain what The Grid is in more details, how it came to be, differences with Matrix,
+how the protocol will be managed by the non-profit and how documentation should take place.
+- [Project Overview](docs/overview.md)
+- [Governing Body](docs/governing-body.md)
+- [Documentation Principles](docs/doc-principles.md)
+
+## Contact
+Visit us on:
+- Matrix
+  - [#thegrid:kamax.io](https://matrix.to/#/#thegrid:kamax.io)
+  - [#kamax-thegrid:t2bot.io](https://matrix.to/#/#kamax-thegrid:t2bot.io)
+
+- Telegram: [@thegrid_matrix](https://t.me/thegrid_matrix)

docs/doc-principles.md

@@ -0,0 +1,206 @@
+# Documentation Principles
+
+## Scope
+This document aims to:
+- Define the value and importance of documentation for the protocol and in the ecosystem
+- Define key terms
+- Describe the principles of Documentation processes
+- Describe the various types of Documentation
+
+## Concepts
+We strongly believe in documentation, not because of the documentation itself, but because of what it represents, the
+values it upholds and a possibly near universal recognition of worth for the knowledge it contains.
+
+The rest of this document will describe those in details.
+
+### Proof of Work
+The expression ***Proof of Work***, shortened to ***PoW***, will be used throughout this document to represent the effort
+made by someone to articulate and communicate meaningfully about relevant matters towards others. It comes from the
+[Proof-of-work system](https://en.wikipedia.org/wiki/Proof-of-work_system).
+
+There is no restriction on the amount of work itself, which can range from near-to-nothing to extensive amounts of time
+and money. It will directly depend on the situation and the goal of the debate.
+
+Anyone in the community (including from the boards) who wants to participate in a debate MUST produce ***PoW***.  
+***PoW*** does not mean minimal amount of knowledge. Rather, ***PoW*** means minimal amount of effort.  
+We expect back-and-forth argumentation backed by ***PoW*** as people participate in an exchange of some sort, until no
+more argumentation can be brought up, which will settle that particular exchange.
+
+### Documentation
+The word ***Documentation*** will be used as a generic concept throughout this document.  
+Any document that seeks to be recognized as *Documentation* must incorporate at least one ***PoW***.
+
+It is defined as something that:
+- Is available publicly
+- Is directly reachable using a [URL](https://en.wikipedia.org/wiki/URL)
+- Is a standalone piece of work, or directly incorporated in one at the same location
+- Is written in English if text-based
+- Incorporates at least one ***PoW*** from the concepts below
+- Can be re-used by others to build on
+- Provides a publicly accessible channel for feedback
+
+Examples of Documentation:
+- A standalone HTML page
+- A PDF document
+- An [ODT](https://en.wikipedia.org/wiki/OpenDocument) document
+- A Gogs/Gitea/Github/Gitlab issue
+- A comment on an issue
+- A Cryptpad document
+- A Google Docs document
+- A schematic wireframe
+- A fully rendered and styled visual mockup of a GUI
+
+Any produced *Documentation* is guaranteed to be reviewed by the governing body in a timely fashion. *Documentation* will
+therefore become the ideological currency of the project and ensure everyone who worked to produce one will be able to
+"trade" it for something else (e.g. trade it for the review of the documentation).
+
+We make no generic requirements on the format, length or overall wording of *Documentation*, as long as the vast majority
+of the community is happy about it. This is on purpose, following on the issues met so far using a too strict proposal
+process and we’ll rely on a naturally occurring balance with gentle nudges in the right direction.
+
+The Technical Board will produce a list of officially recommended formats, way of sharing and provide sample templates
+for the various fitting use case so people can easily get started. Those will be kept up to date and relevant.
+
+### Implementation
+The term ***Implementation*** will refer to the deliverable or the actual product derived from a given *Documentation*.
+It is a generic term, it's meaning will change depending on the role/occupation of the deliverer.
+
+Examples of Implementation:
+- As a software developer: source code
+- As a graphic designer: Wireframes and mockups
+- As a User Experience engineer: Guidelines/recommendations
+- As a system administrator: Install guides, deployment scripts, etc.
+
+## High-level concepts
+To ensure successful *Documentation*, it is essential to respect some core concepts that reflect the value of the protocol,
+its openness and the recognition of ***PoW***.
+
+The following concepts are how something will be judged as qualifying as a ***PoW***.
+
+### Extract, organize and materialize thoughts
+Our experience shows that the human mind tends to underestimate risks, difficulty level and overall workload.
+Therefore we believe that the act of writing the *Documentation* - regardless how small - simply forces one to think further
+and in more details about what one tries to accomplish and filters the most basic and unconscious biases.
+
+### State functional problem to be solved
+While chat or voice exchanges are good for quick exchanges, it’s easy to lose sight of the actual problem one is trying
+to solve and the involved scope, or simply not really know what problem is currently be solved. By stating up front the
+problem, the scope is set and can be enforced in further exchanges.
+
+### Facts backing
+**This is *Proof of Work***
+
+As this is a technical exercise, it is important that any statement that influences choices, like "it is very likely that
+X happens", be backed up by objective, quantifiable and/or qualifiable facts from an independent source.
+
+### Usage feedback and usability
+**This is *Proof of Work***
+
+Using or testing software/*Documentation* or any kind of item that comes from a ***PoW*** becomes itself a ***PoW*** once
+that experience is documented.
+
+This is typically:
+- Software tests in development cycle
+- Daily usage from end-users
+- Bug reports of software of the protocol specification itself
+- Feature request from end-users
+
+In addition to load testing, pen-testing, etc, usability focus groups (whether remote or in person), feedback via surveys
+and suggestion forms provide an excellent opportunity to gain new and sometimes  unexpected insights. If the same
+feature request or complaint appears frequently, it should be considered actionable. Putting together such a compiled
+list or results of testing provides actionable next steps.
+
+Ad hoc observations such as “my group found this feature difficult to use” can be logged as an issue and may also be
+considered; however compiling quantitative evidence (X% of users could not complete an assigned task) is strongly encouraged.
+
+UX professionals and designers should also be encouraged to submit wireframes, mockups, and process documentation
+for future functionality. (Not just "what’s broken?" but "what can be dreamed and built?").
+In this instance, a well-developed use case is considered ***PoW***.
+
+### Sources linking
+**This is a *Proof of Work***.
+
+As facts must come from external sources, it is critical to include links to those sources, so anyone evaluating the
+document can have access to the same information as the author without having to research the data themselves.
+
+### Proposed solution
+**This is a *Proof of Work***.
+
+Once the problem to be solved and the scope are documented, one will describe the proposed solution that solves the
+stated problem/issue.  
+Next to the description of the solution, one MUST reiterate in a short conclusion how the solution effectively solves
+the problem.
+
+### Rationalisation
+**This is a *Proof of Work***.
+
+As one goes through the proposed solution, one will use the various facts and/or linked sources to justify the proposed
+solution. One CANNOT rely on common knowledge, as this is a cognitive bias. On the other hand, one is free to rely on
+required knowledge.
+
+Example: If describing an HTTP endpoint, one may have to justify the validity of the HTTP choices made (POST vs PUT, etc.),
+but one will not have to justify TCP principles.
+
+### Implementation
+**This is a *Proof of Work***.
+
+This validates the proposed solution with an actual Implementation and ensures that the theoretical outcome is feasible
+in practice, as a real product for real users.
+
+### Peer convincing
+**This is a *Proof of Work***.
+
+Proposals should be written in a way that one attempts to convince others that the proposed solution is the correct one,
+instead leaving the fact checking work to their reviewing peers.  
+One MUST NOT assume they are correct to start with. They MUST convince others of the validity of their claims using the
+elements described above.  
+It MUST be easier to read the proposal than to write it.
+
+## Types
+*Documentation* will be divided into several types, each having their own requirements and goals.  
+Except for The Protocol Specification, any of those *Documentation* can be put forward by the governing body or by the
+community.
+
+Types are not mutually exclusive and a single *Documentation* can be of several types.
+
+The various types will outline the various stages/steps of the overall process which is a recurring cycle:
+1. Guides/Recommendations/Templates and The Protocol Specification allow Implementations to be made
+2. Implementations trigger Issues/Bug reports/User feedback
+3. Issues/Bug reports/User feedback trigger Research/Analysis
+4. Research/Analysis inspire Guides/Recommendations/Templates and Proposals
+5. Proposals aim to enhance Guides/Recommendations/Templates and The Protocol Specification - Back to first step.
+
+### Issue/Bug report/User feedback
+This kind of *Documentation* will mostly rely on [Usage feedback and usability](#usage-feedback-and-usability).
+
+**Example**: Request to clarify recommended setup for synapse (Github issue).
+
+### Research/Analysis
+This kind of *Documentation* will mostly rely on [Facts backing](#facts-backing), [Sources linking](#sources-linking) and
+[Peer convincing](#peer-convincing). It can be produced by anyone and will be the primary backing work for other *Documentation*.
+
+**Example**: Matrix Server ACL addition analysis ([Github gist](https://gist.github.com/maxidor/b25769f1a89c8860b928babe795bbaaf)).
+
+### Guide/Recommendation/Template
+This kind of *Documentation* will mostly rely on [Usage feedback and usability](#usage-feedback-and-usability) and
+[Proposed solution](#proposed-solution).
+
+**Example**: Matrix stack installation guide ([Github repo](https://github.com/PC-Admin/PC-Admin-s-Synapse-Setup-Guide)).
+
+### Proposal
+This kind of *Documentation* will mostly rely on [Proposed solution](#proposed-solution), [Rationalisation](#rationalisation)
+and [Peer convincing](#peer-convincing).
+
+**Example**: Matrix client auto-discovery ([Google Docs](https://docs.google.com/document/d/1vF-uWlUYmf1Xo161m871H1upJbwiIPeikWGWzaE_lrU)).
+
+### Implementation
+This kind of *Documentation* will mostly rely on [Facts backing](#facts-backing) and [Implementation](#implementation).
+
+**Example**: any software implementation following a protocol specification.
+
+### The Protocol Specification
+The Protocol Specification will be one of the final products and the most important deliverable for the Governing Body.
+
+As a special authoritative document, its main Proof of Work will be "delayed" and mostly contained in its ability of
+[Peer convincing](#peer-convincing) and being backed by two independent [Implementation](#implementation), adding to a
+total of three independent *Documentations* (one is the specification, two are the implementations).

docs/governing-body.md

@@ -0,0 +1,181 @@
+# Governing Body
+
+## Scope
+This document will outline the high level concepts and guidance principles of the governing body of The Grid that will
+be used for the articles of constitution.
+
+This document will NOT go into details of how day-to-day management will happen, which will be left to the discretion
+of the Governing Body.
+
+## Legal entity
+The Governing Body will be a non-profit organisation, funded in Luxembourg, as an Association sans but lucratif by Max
+Dor (author of this document), Daily Manager of Kamax Sarl, and two other people (TBC, people that are known personally,
+but not necessarily technical), as legally required.
+
+Non-profit status will ensure that all activities and incomes must be legally targeted to fulfil the missions of the
+non-profit without being subdued by making a profit for its shareholders, as opposed to a for-profit which its sole
+purpose is to make profit and distribute it to its shareholders.
+
+Non-profit gives a better framework for donations or voluntary work, without the need for extensive accounting or legal
+requirements overall, giving much more freedom in the day-to-day running of the organisation and helps keeping management
+costs to a minimum, which would otherwise add up to several thousands Euro per year.
+
+The legal entity will be used to centralize ownership of various protocol IP materials, like Internet domains, trademarks,
+logos. The source code of any tools built by or on request of the legal entity will remain the IP of their respective owners.
+
+## Missions
+The Governing Body will have the following missions:
+
+### Regular protocol specification releases
+A protocol is only defined by its specification, and its delivery in a clear, comprehensive, validated and usable format
+by the widest technical audience is the most important mission.
+
+The Governing Body exists in fine for the sole purpose of this deliverable and should be judged on it.
+
+### Provide adequate environment, tools and hosting
+The Governing Body will provide:
+- A documented vision for the protocol
+- What is reasonably necessary for its boards to fulfill their responsibilities
+- What is reasonably expected from the community about such entity with a similar mission
+- End-users software, tools and services to showcase the protocol usage and goals
+- Development software, tools, documentation and services to ensure independent implementations are possible and straightforward
+- Means and services to discuss, exchange, and learn about the protocol
+- Guidelines and processes for protocol changes and community contributions, ensuring these are always welcoming,
+  as easy as possible, and as rewarding as possible.
+
+### Community management
+Ensure:
+- A Community Manager which will always be available and reachable
+- The community is proactively kept up to date of changes and achievements
+- Officially-managed places are properly and timely moderated
+- Feedback from The Community, however bad or good, is always taken into consideration
+
+### Protocol fostering
+Proactively engage into activities to:
+- Make the protocol known by as many people as possible (website, social medias, conferences, etc.)
+- Convince end-users to use the protocol (demos, webcast, etc.)
+- Convince developers to build on the protocol
+- Grow the community at large
+
+## Funding
+The Governing Body should only be founded on donations from the community. This will be a critical dynamic for this
+project, as it will ensure the community has a clear and straightforward way to show its support and general agreement
+with how well the Governing Body is doing.
+
+All donations will be listed and made public. Donors that have made a donation with significant amount (> X€ over X months)
+must be publicly disclosed as they can use it as leverage to achieve their own goals. Donations MUST NOT be conditional
+to any delivery, service or related item. Donations MUST be without any string attached.
+
+While sponsoring is occasionally acceptable, full disclosure about the transaction, including the contract, MUST be
+publicly disclosed. Contracts that conflict with this full public disclosure clause MUST be refused. Signatures, emails,
+contact numbers will be removed before public disclosure.
+
+Sales of goods and services are acceptable, as long as:
+- They are legally acceptable for the non-profit
+- The majority of income is not tied to a minority of customers
+- Do not interfere or take priority in any way with the missions and responsibility of the Governing Body outlined in this document
+
+The Governing Body will give full disclosure about incomes on a regular basis (TBD, quarterly?), so it can be audited by the community at large.
+
+## Financing
+The Governing Body will be allowed to use its funds to:
+- Pay a regular salary to management board members
+- Give financial compensation to technical board members, after approval from management board and technical lead, to
+  ensure they can afford dedicated time and give an incentive to remain a member
+- Pay for the various fundamental technical services (Domains, web hosting, etc.)
+- Finance trips and related expense to social events which are relevant for the boards’ missions (e.g. FOSDEM stand)
+- Finance individual missions with independent contractors/orgs that may have dedicated knowledge into one area, to further
+  progress the protocol (e.g. a security/crypto consultant for end-to-end encryption, or security audit)
+
+The Governing Body WILL NOT be allowed to provide funds to any entity listed as an employer or of significant involvement
+with any of the boards’ members. This will ensure no board member will have an incentive to redirect the Governing Body
+money for its own profit.
+
+The Governing Body will give full disclosure about spending on a regular basis (TBD, quarterly?), so it can be audited
+by the community at large.
+
+## Leadership
+The leadership of the non-profit will be divided into two boards:
+- Management board
+- Technical board
+
+Membership of those boards are not mutually exclusive, and one person can be a member of both. Each board will have
+specific, non-overlapping responsibilities.
+
+We recognize and even value that no one can be 100% neutral and therefore might try to push their own agenda, even if
+unconsciously. We see this as a driving force as members would have a reason and a motivation to be there and is not a
+negative thing on its own.
+
+As a user, developer, sysadmin, member or donator, it is very important to be able to make an informed decision about
+whether one should continue contributing in its own way to the project. This starts by knowing who the people in charge
+are, what allegiance they might have and the laws they are bound to.
+
+Therefore, every member of each board must disclose the following on public record:
+* Name (not necessarily full legal name, but not an obscure nickname either, like “l33t1337”)
+* Employment status with position and employer if applicable
+* Significant (paid and/or with decision making level) involvements in other organisations of any kind
+* Country of legal residence
+
+Members will be listed on the main website of the protocol project page, along with the latest up to date information.
+
+### Management board
+This board will be made from members of the legal entity and will take on the following responsibilities:
+- Management of the non-profit legal entity
+- Accounting
+- Finances
+- Promotion of The Grid
+- Ensure the governing body’s missions are fulfilled
+- Functional (high-level, non-technical) steering of the protocol
+- Community management
+
+Eligibility:
+- Legal member of the non-profit
+
+Membership starts:
+- By vote of all current board members
+
+Membership ends if either of the following occurs:
+- Of their own will, at any time
+- By vote of all other board members
+
+### Technical Board
+This board will be made of people who have written implementations of the protocol and thus can have an informed,
+knowledgeable and authoritative view about the technical choices to be made and decisions to be taken.
+
+This board’s members will be made of:
+- One lead member, called “The Lead”
+- An number of other members, called “The Members”
+
+The board will decide on a tie-breaking mechanism for decisions.
+
+The lead will take on a “back-seat” role, only giving his final opinion/choice/vote after everyone else has. The Lead
+will have a special role as a spokesperson of the technical board, both towards the management board and the community.
+
+The lead can only be voted in by the management board which MUST seek a written list candidates from the technical board.  
+The lead can only be voted out by the technical board and MUST, prior to voting, seek a written opinion about it from the management board.  
+This will ensure that both boards agree on The Lead being a good fit for the role and that potential abuse is kept under control.  
+The board CANNOT contain more than one member that have financial ties with a specific entity. This will ensure the board
+cannot be taken over in the long term by a single employer/corporation/organisation.
+
+Responsibilities:
+- Production of the protocol Specification
+- Production and maintenance of an implementation validation tool to certify those implementations as protocol compliant
+- Technical steering of the protocol, to fulfil the functional goals
+- Review of community proposals
+- Proactively ensure enough implementations exist to keep the protocol validated
+
+
+Eligibility:
+- Be the main author of at least one maintained (compliant with the current or previous version of the protocol) component implementation
+- Submitted at least one protocol change that has been accepted in the official documentation in the last X months
+- Commitment to be available X business days per week, except when on justified leave
+
+Membership starts:
+- By vote of all current technical board members
+
+Membership ends if either of the following occurs:
+- Of their own will, at any time
+- By vote of all current technical board members
+- By failure to disclose any potential conflict of interest, enforced by the management board if necessary
+- By failure to be available as required, enforced by the management board if necessary
+- By failure to keep their implementation maintained, enforced by the management board if necessary

docs/overview.md

@@ -0,0 +1,177 @@
+# Overview
+
+## Scope
+This document aims to provide background on:
+- Why/how The Grid project came to be
+- Its intended goals and values
+- Differences with the Matrix protocol
+- The high-level methodology/processes we want to put in place to ensure this protocol and project are successful
+- The set of first priorities that will be worked on
+
+## Origin
+As independent developers on the Matrix protocol, we decided to pursue an alternative approach and set of goals and
+provide a fresh set of eyes and solutions to the remaining challenges the protocol is trying to solve.
+
+We have spent to this day over 18 months learning, analyzing and reverse-engineering the Matrix protocol, implemented
+nearly all components with various use cases, granting us extensive knowledge about its:
+- Strengths and weaknesses
+- Current limitations
+- Security vulnerabilities, both used and hypothetical
+
+While we will like to take an alternate road from the Matrix protocol and become a stand-alone protocol, we believe in
+the fundamental concepts and the building blocks and will keep The Grid protocol in line with those for the time being.
+
+## Goals
+The protocol will aim for the following goals:
+- Solve the problem originally identified by the Matrix protocol, fragmented communications, engaging it from a social
+  point of view.
+- Simple client implementations, relying on the server for heavy lifting
+- Federated communication between servers
+- Decentralized data storage, spread across participating servers
+- Designed for a full self-hostable stack to avoid centralization and/or monopoly
+
+## Values
+### Protocol
+- Libre (Free) and Open protocol where its contributors and users are empowered
+- Privacy of data and metadata
+- Security of data and of the network
+- Data exchange relying on a federated network, allowing everyone to spin-up a server and provide the service to a set of users
+- Decentralized data storage, ensuring no single point of failure
+
+### Management
+- Transparency and openness around any talk, design session, workshop, meetings and any other related activity for the
+  protocol, without secretive or confidential sessions
+- Clear, understandable specification documents are the top priority and the main deliverable. A protocol is nothing
+  without a specification.
+- Taken actions and their consequences are used in evaluation, instead of intent.
+- Decisions are backed with documented facts/feedback/issues
+
+### Documentation
+Documentation will be considered a generic term. Complexity, size, format and shape will be scoped to what is deemed
+appropriate by the Governing Body for the various use cases.
+
+As a protocol only exists in its specification and the only seeked resource, documentation will hold a special place for
+this project and acts as the currency in spirit of the project, with various value depending on its complexity, size,
+format, shape, use case and scope at hand.
+
+It will also be used to enforce various good practices and force facts checking.
+More details will be given in a separate, dedicated document to Documentation.
+
+## The Grid vs Matrix
+### Differences
+#### Core values
+Matrix’s ideals are Openness, Decentralization and Encryption [1](#links-and-sources) while The Grid’s ideals are
+Freedom, Privacy and Security.
+
+We see Matrix ideals as a subset of The Grid: While Matrix attempts to only solve the technical problem of fragmented
+communications, The Grid wants to solve the problem at a social level, a higher level which includes the technical one.
+
+While Matrix values and licenses align with the ideals of Open Source, The Grid would follow those of Libre (Free) software.
+This would ensure that users and their rights are the focus and put at the center of each decision, instead of limiting
+the discussion to technical matters only.
+
+We believe in a social gain with The Grid protocol rather than technical or monetary gain, which should be reflected in
+its own ecosystem.
+
+#### Actors
+Given the social purpose of the protocol, we believe involvement, participations and decision making should reflect the
+social nature of the protocol.
+
+Therefore, we want to put in place an ecosystem where anyone has a mean to express their opinion, provide feedback, or
+contribute to the project itself. Making sure that no single entity is in a position of power alone. Instead, several
+entities are in place to keep each other in check.
+
+The creators of this protocol will initially stand alone in a position of power to bootstrap the ecosystem. Afterwards,
+the newly-created non-profit will provide within its articles the requirements to join the various boards and decision
+groups. See the Governing body section for more details.
+
+#### Documentation
+Matrix relies on reverse-engineering reference implementations since its creation 4 years ago, and has yet to produce a
+version of its documentation that can be used to implement a full set of usable and interportable implementations.
+A new spec proposal process was put in place but we believe it does not address the existing issues that led to the
+current situation.
+
+The Grid will therefore take a different approach and attempt to turn documentation into something positive and rewarding
+for contributors and implementers, while putting processes and limits to avoid stagnation and status-quo.  
+It will also take the approach that the spec (the end-result) is to be implemented by at least two projects, independent
+of each other, to ensure that the documentation and the specification are not academic exercises, but real-world and
+problem-solving.
+
+This practical approach where contributors/implementers can see their work be used and recognized, is an example of a
+rewarding experience for those who wish to contribute to the project.
+
+### Which is better?
+We don’t believe one is better than the other - The Grid and Matrix will each follow different values and a different
+type of management.
+
+While they will most likely solve technical problems in different ways, The Grid will initially build from what Matrix
+is today and re-use existing and validated documentation. APIs like Client, Application services and Identity service
+will remain compatible in the short term as the focus will be on producing a usable document that describes the server
+protocol, which Matrix currently doesn’t have.
+
+As The Grid and Matrix will both have concepts of Application Services and therefore Bridges, linking both protocols and
+network will be a property that will be heavily leveraged on The Grid side to smooth out any transition or API change
+that would make the two protocols otherwise incompatible and unable to exchange data.
+
+If you believe in the same values and ideas as we do, we’ll be happy to have you help us with The Grid.
+
+## Next steps
+The high level steps are:
+- Creation of a non-profit to kick-start, grow, foster and maintain The Grid protocol.
+- Document all the concepts and network exchanges.
+- Ensuring that at least two independent implementations validate the documentation.
+
+### Governing body
+To ensure the protocol is free of control from a single entity and that the users are empowered to control it, a non-profit
+organisation will be created to represent the protocol lead and will be funded on donations.
+
+This body will be created as soon as possible as we believe it is key to ensure neutrality in a communication protocol.
+
+This governing body will be created using public and community-reviewed articles and will put in place technical board(s)
+composed of key entities from the community to fulfill its mission.
+
+This governing body will have for mission to ensure the protocol fostering and that its management values are respected
+and followed.
+
+Details about this controlling body, its missions and its proposed articles for creation are available in [a separate
+document](governing-body.md).
+
+### Initial Documentation
+We recognize the hard work, effort and engineering level of the current Matrix protocol and wish to build on that,
+instead of starting from scratch. We also believe that having a documentation of the as-is is key for people to contribute
+constructively and avoid an unfair amount of work spent on reverse-engineering implementations to reach a level of
+understanding sufficient to even start meaningful discussions/contributions to improve the protocol.
+
+The biggest lack of documentation is currently the as-is for the server protocol, which deals with internal structures
+of a Homeserver, the federation exchanges, the DAG model and its underlying algorithms. It is therefore not possible
+to build on an existing documentation for those core concepts.
+
+As the current federation protocol has several critical security vulnerabilities like state resets which have been used
+in attacks [2](#links-and-sources) [3](#links-and-sources) on the live network, and very few underlying algorithms and
+endpoints have been documented, we will take this opportunity to attempt creating internal structures and federation
+exchanges that are immune to those known vulnerabilities, while holding back on any kind of optimization that would
+require re-engineering on working, secure and tested concepts.
+
+As all this will be done in the open, as per our core values, current issues to be addressed will be documented and
+labeled appropriately so anyone in the community can offer a documented technical solution for them. We believe that
+fresh sets of eyes and brains are required to solve those vulnerabilities.
+
+Work has already been started on this and is currently being committed to this Github repository, and a generated online
+version is also available. This work will be relocated under the newly The Grid organisation repositories very soon.
+
+### Independent implementations
+Meanwhile, we will encourage, foster and proactively seek that independent entities implement the protocol using its
+latest documentation.
+
+We believe that a communication protocol that does not have at least two independent implementations is fundamentally
+dysfunctional, as its contributors and governing body have failed to communicate to or be understood by other parties
+about its worth, merit and the related technical knowledge.
+
+In the near and middle term, emphasis will be put on the various protocol efforts to not diverge too much too fast from
+the Matrix protocol. Independent implementers will be able to easily and painlessly implement The Grid as well, ideally
+in an invisible manner for the end user.
+
+## Links and Sources
+[1]: https://matrix.org/blog/home/ - “Support Matrix Today” section  
+[2]: https://matrix.org/blog/2018/05/01/security-update-synapse-0-28-1/  
+[3]: https://matrix.org/blog/2018/06/14/security-update-synapse-0-31-2/