Key Features
WikiDeal in a nutshell? The Wikipedia of deals.
WikiDeal aims at offering better deals at lower prices (reducing fees) for transportation (like Uber and Blablacar), hosting (like Airbnb & Booking) and more (see below "Wikideal services - usecases").
The core services are contracts and online support to sell, rent, employ, share ...
Like on Wikipedia, you can freely access, edit and adapt the contracts for your specific contexts and needs.
Lawyers and assistants propose you optional hotline & coaching services to design and manage your deals, including bench marking (for pricing, parametering...), externalizing operational tasks ...
For instance, you can ask them "please manage my empty apartment, put it on rent, and take a fair commission fee on each deal".
If you contribute as volunteer, like on wikipedia, you get rewards (bonus) to use as voucher for transportation, hosting etc. Like on wikipedia, you have dozens of volunteering options to make empower Wikideal community.
Who owns WikiDeal? It's a common, owned by its users.
Each user has to buy one share (costs CHF 10.- plus 5% increase/year), in one or many microparts (for instance CHF 1.- on each wikideal transaction).
Users can also contribute in developing the platform’s technology, legal support, marketplaces and governance, like on wikipedia.
User's groups gathers to create poles of activities (geographical such as Polandarbitration chamber) and on
How is it governed?
WikiDeal gathers the highest standards on ethics, privacy, customer support, free licensing, low costs and high efficiency, inspired by the Wikimedia foundation participative governance (who's operating Wikipedia and 13 related projects such as wikispecies, wiktionary...).
WIKIDEAL SERVICES (USECASES)
The Minimum Viable Product (MVP) is planned to provide the following wiki-managed features:
- Models of ready to use and customizable contracts (“deals”), agreements and rules of functioning.
- Each contract includes optional clauses to help make fair deals, such as adapted conditions of payment, simplified arbitration for conflicts and easy authentication of signatures.
- Each clause of each contract is easy to adapt, edit, comment, explain and refer to laws and stats.
- Automated scenarios helping dealers select and respect each clause of their deals, raising awareness with tutorials, reminders, amendments, alerts, stats, use cases and terms of interpretation …
- Conflict prevention and resolution between WikiDealers using coaching, mediation and arbitration.
- Anonymized big data for risk management, including incentives & compensation tools such as benchmarks on pricing and fines, reputation and karma management, social and ecological impact.
- Fair deal enclosure options (executing, canceling & resiliating with compensations, transfer).
Which deals are we talking about?
First, peer-to-peer deals for everyday life, including:
- Services such as transportation, freelance, internship…
- Renting goods (functional economy) including hosting, vehicles, clothes…
- Buying and selling (ticketing for shows, real estate, food, machines…).
- Loans of goods without middle men (from loaning funds to books or bikes).
- Partnership (employment, pre-nuptial/marriage/divorce, co-owning goods…)
- Most types of deals humans can imagine and need to agree upon.
Then, deals with multiple stakeholders, such as:
- Leasing including three parts: buyers, sellers and loaners (banks, insurance, funds…).
- Social contracts and rules for shared real estate, such as condominiums and communities.
- Private-public partnership, such as those to protect forests or assess quality of products.
- Franchising agreement (such as those between TED Foundation and TEDx event licensees).
- Joint ventures (from co-working to buying shares of a company).
- Pedagogical signage to respect deals, such as waste management rules on a public toilet.
Components
Contract models
Contract models are predefined models (or templates) of contracts for various agreements or deals. Contract models are provided, edited and discussed by the community just like Wikipedia articles, to make sure the best possible contract model is always provided for a specific purpose.
A contract model is simply comprised of a document title and collection of appropriate clauses that defines the agreement.
A contract model may also contain notes, warnings or other to be decided optional fields that will help users when using the contract model to generate real contracts.
To be decided:
- Architectural implementation of contract models.
Clauses
A contract model will mostly be just a collection of legal clauses, conditions or provisions. Clauses will be blocks of text that can contain variables. An example of a clause would look like:
“{{ signatory }} agrees to pay {{ offerer }} the amount of {{ fee }} before the {{ day }} of the month for the period {{ start_date }} until {{ end_date }}”
Clauses could have meta information assigned to them based on community feedback. Examples include things like “popularity” or “legal expert verified”. It could also include references or citations to various types of laws that the clause adheres to.
If a clause is verified by a legal expert it should of course not be directly editable, because it will have to reverified after each edit. This means that instead of editing a clause it will create a new clause, keeping the original. The new clause will then become an optional suggestion for creating a contract.
To be decided:
- Should clauses contain the information on which models they belong to (i.e. using Semantic MediaWiki)? Or should the contract models contain this information?
Creating a contract
Using the contract models and clauses users would be able to generate customized contracts for their own purposes.
Envisioned workflow:
- Select an existing contract model.
- Input all the variables that the contract model requires and additional details such as a preamble.
- Fill in all the conditions of the contracts, which decides which clauses will be included in the contract.
- [Optional] Edit the clauses of the contract. This may consist of:
- Removing clauses.
- Reordering clauses.
- Replacing clauses with different clauses in the database of approved alternative clauses.
- Adding custom clauses.
- Save the contract (for example as PDF) and send it to the stakeholders of this contract.
Signing contracts
Once a contract has been created and sent to its stakeholders it will have to be signed to conclude a deal.
The signing phase of a contract should ideally not only be a “sign” or “decline” button. In this phase there should also be the possibility for all parties involved to discuss and negotiate on the contract.
In this phase a contract could have statuses, such as:
- Draft
- Conflict
- Being discussed
- Signed
- Denied
- Closed
When this stage is done successfully a deal has been made.
Post deal
When the deal has been made WikiDeal could provider additional features that make the execution of the deal easier. Examples of features in this stage could include, but are not limited to:
- If a contract contains dates or deadlines WikiDeal could send reminders to the parties involved. This would also apply to monthly repeating clauses.
- If a contract contains a monetary transaction WikiDeal could provide payment links that already includes the monetary amounts as stated within the contract.
- If a contract is related to a service it could be programmatically linked to automatic activation/cancellation of said service when signed.
Decentralization
Because contracts contain private information they should not be stored on the main centralized main WikiDeal server. Creating a contract on the site should only allow the user to save the contract to their local computer, but not on the main WikiDeal server.
Contracts might temporarily be saved on the WikiDeal server during the Minimum Viable Product stage of development for convenience.
Instead ideally we would develop an external tool to generate contracts using the centralized community driven data of WikiDeal, but without storing any personal data. This will make users fully in charge of their own personal data while still using the crowd-sourced data that WikiDeal provides.
For organizations using WikiDeal we envision a decentralized system where the organization hosts their own WikiDeal instance. The organization instance will use the data provided by WikiDeal for contract models and clauses, but it will store all personal data of its organization only on their own WikiDeal instance.
For contracts between individuals we envision a decentralized system using instances (similar to the fediverse or email). This allows users to be in control of their data by either signing up to an instance that they trust or choosing to host their own.
Alternatively we could also consider some sort of fully peer to peer approach to making deals but details of this have not been thought out.
Proof of concept
Before making a Minimum Viable Product (MVP) it might be a good idea to make a proof concept first.
The proof of concept will likely just include:
- Contract models.
- Clauses.
- Creating contracts (very basic implementation).
This is to focus on establishing WikiDeal as a really useful public repository for clauses and contract models and so we can see if the envisioned architecture we end up choosing works as expected.
A proof of concept will give us a good place to interature further upon and this also gives us more time to work out the details of what a MVP should contain.
Minimum Viable Product
Outdated feature matrix information that might be used for future reference:
| Contract Models | Prio | Hours |
| Base model type which can contain a collection of clauses | 1 | |
| Conditional clauses and options to customize the clauses | 2 | |
| Notes and help texts | 3 | |
| Clauses | ||
| Base clause type | 1 | |
| Clause variables | 1 | |
| Citations in clauses | 2 | |
| Statistics (maturity, references, etc.) | 2 | |
| Notes and help texts | 3 | |
| Creating a contract | ||
| Entering basic variables (names, date, preamble, etc.) | 1 | |
| Enabling conditional clauses | 2 | |
| Visual contract editor | 1 | |
| Save as PDF or other formats | 2 | |
| Send to stakeholders | 3 | |
| Annex and attachments to contracts | 3 | |
| Signing contracts | ||
| Basic signing of contracts | 1 | |
| Discussion and negotiation | 2 | |
| Various states (draft, conflict, denied, signed, etc.) | 1 | |
| Post deal | ||
| Sending reminders | 2 | |
| Automation API | 3 |
Additional features (likely not in MVP)
| Creating a contract | Hours |
| Personalized contract styling (typography, etc.) | |
| Decentralization | |
| External contract creation tool (desktop or phone app) | |
| Self hosted instances (with federation) | |
| True peer to peer contract creation | |
| Funding | |
| Bounding curve software |