CONFIDENTIAL - WikiWe Confidants' MNDA Required To Proceed
Please call or message an Administrator of Confidants Group if you have questions or observe breaches of confidentiality under this MNDA or related MNDAs.
This WikiWe Guide to Enforceable Commitments (“EC Guide”) is made for incorporation into the WikiWe Model Agreement 2.0 (“WikiWe Model”), which in turn is incorporated into Charters of WikiWe License Hubs.
Purpose
This EC Guide describes protocols and ontologies for enforceable commitments to guide those Members coding, making, and recording them with the intention that their commitments be enforceable under the Wyoming Issue Dispute Resolution Agreement, if need be. “Enforceable commitments” are those voluntarily assumed obligations upon which each Member stakes their reputation, earning merit by fulfilling their obligations while answering for their failings.
Members may transact with each other and keep their records as they please. However, agreement on the protocols and ontologies for recording and enforcing commitments brings many benefits, for example, unlimited scalability of the voluntarily self-governing community. Administrators will recognize enforceable commitments and evidence documented as described in this EC Guide. Enforceable Commitments may include, for example, Agreements (also called contracts), Roles, Compacts, Charters, Pledges, Professions, and Social Promises.
Definitions
An “Agreement” is a exchange of promises between two or more identified persons.
A “Compact” is an Agreement that remains open for new parties to join.
A “Charter” is a Compact focused on organizing a virtual entity, e.g., a License Hub.
A “Pledge” is a promise made to a specified group of “Beneficiaries”.
A “Profession” is a Pledge or Social Promise that includes obligations that do not need to be reciprocated to be enforceable.
A “Role” is a Pledge or Agreement to perform a role for a specific purpose and group of Members (e.g., a License Hub or Project.) Roles are often titled, e.g., as “Manager,” “Officer,” etc.
A “Signature” is a verifiable token of consent by the person singing, for example a PGP public key. It may also function as a personal identifier.
A “Social Promise” is an enforceable promise made to anyone bound by a reciprocal enforceable promise.
A “WikiWe Confidant” is a person who has signed the WikiWe Confidants MNDA.
Channels
Channels are addressed communication means used for giving notice, making claims, giving and revoking consent, issuing credentials, merits, and demerits, and administering enforceable commitments. Every channel has an address, a location (e.g., a computer memory) for storing messages delivered to the address, and at least one key or credential for controlling read/write access to messages in the channel.
Channels can be configured and classed in many different ways. For example, classes may include centralized, decentralized and multilateral, or decentralized and unilateral channels, which classes may be distinguished as follows:
- Centralized channels are one to many. Only one party, typically an admin, can communicate with all parties directly. Clickable online licenses, in which the company presenting the license is the only party who knows who the signers are and how to contact them, fall into this class.
- Decentralized multilateral channels are any to any. Every member of the channel knows the contact address of every other member. Messaging applications are typically arranged this way. Decentralized multilateral channels are useful for groups working together for shared goals.
- Decentralized unilateral channels are like shared lockboxes holding a stack of messages placed by key holders. Every member of the channel has a private key enabling write access, and each can verify their entries by a corresponding public key. The identities and contact addresses of the other keyholders are not disclosed in the channel. Decentralized lockbox channels are useful for verifying social credentials anonymously (e.g., proving the character of a stranger without requiring them to disclose their identity).
Channels may differ in many other respects. For example, some channels may contain encrypted data only, others may be unencrypted. Some channels may keep posted messages indefinitely, others may delete data after a specified period of time. Some channels may be local only (messages stored only on devices belonging to channel members), some may be local first (like local first, but with a mirror copy stored on a server for more convenient access or as a backup), and some may be client-server (messages stored only on a server) implemented. Client-server channels are centralized in that the server operator has the power to block any other member from access to the channel.
The configuration of channels depends on the type of enforceable commitment at hand and the preferences of the persons involved. However, centralized channels establish unequal power relationships, and so shouldn’t be used in decentralized associations except when absolutely necessary, if ever; and when used, their centralized nature should be clearly disclosed to all parties before any commitments are made enforceable.
Pledges work the same way as multi-party Agreements. It is convenient for everyone making the Pledge and all the Beneficiaries to join the same channel or group. Typically, the Beneficiaries and the Pledgers are already in the same channel for other reasons, for example as parties to the same Agreement or Compact.
Social promises are published with a date stamp and a channel for contacting the promisor, for example by publishing in social media or in a blockchain ledger. Decentralized unilateral channels are especially appropriate for social promises inside or outside of WikiWe, enabling promisors to prove their character without disclosing their identity.
Channel Administration
Responsibilities of channel administrators depends on the type of channel: centralized, decentralized multilateral, or decentralized unilateral. WikiWe channel administrators accept at least the obligations of this EC Guide, and may make confirming or additional pledges regarding their administrative role. An example of a pledge for channel administrators is provided at WikiWe Channel Administrator’s Pledge.
Administrators of centralized channels are bound to clearly disclose the centralized nature of the channel to all signers, to not falsify records, and to provide a true copy of records pertaining to any signer who requests a copy.
Administrators of decentralized multilateral channels are bound to administer the channel faithfully, fairly and competently, without bias or prejudice, taking enforcement action only to the minimum extent necessary to protect the channel and its members from malfeasance, including for example malicious or reckless attack, negligent disclosure, and solicitation or content that does not advance the purpose of the channel.
Decentralized unilateral channels are cryptographic ledgers hosted by a network without active administration, i.e., wherein “code is law.” Persons who create unilateral channels are obligated to disclose all source code in compliance with recognized standards.
Channel Admins
Each Primary Notice Channel has at least one owner or administrator. Typically this is the person who first creates the Primary Notice Channel and invites founding members. Some applications permit the administrative role to be reassigned to others after formation.
Members of a Primary Notice Channel can select Channel Admins from among their membership and/or invite one or more neutral outsiders to administer the Primary Notice Channel with or without consenting to the entirety of the Primary Notice Channel agreement.
Any person having administrative powers over a Primary Notice Channel is called a “Channel Admin.” Powers of Channel Admins depend on the technical means used and pledge taken. With Signal messaging application channels, the powers include the power to block and/or eject channel members, to edit channel metadata, and to appoint other Channel Admins. License Hubs govern these powers, their scope and regulation, subject to the essential requirements that all who participate in governing Primary Notice Channels be personally bound and answerable to the Wyoming Issue Dispute Resolution Agreement and that no unequal privilege of power can come without a commensurate obligation to exercise the privilege faithfully, beneficially, and selflessly. License Hubs may require Channel Admins to adopt an administrator’s pledge, for example the WikiWe Channel Administrator’s Pledge to confirm and elaborate on their obligations as channel administrators.
Channel Admins can charge for their services and/or accept equity in the enterprises of the Primary Notice Channels they administer. In the latter case, Channel Admins become equity Members of the License Hub that hires them. In addition, Channel Admins can organize their own License Hubs to improve the quality of their services and market power, and such administratively-oriented License Hubs can act as Channel Admins for other License Hubs, if requested.
Channel Admins can devise and offer various other administrative services and products to License Hub members, such as a free and open market will bear. Members of the License Hub may invite any who can faithfully adopt the pledges and agreements required of Channel Admins to compete in the License Hub’s market for administrative services and products.
Channel Admins can act as bridges to tie smaller groups into networks. The networks can be of the same kind, or more commonly, of different kinds. For example, Channel Admins can bridge Peacemaker groups in different regions or languages by translating messages from one group to another.
Effect Of Departure
Intentional and voluntary departure of a Member from the Primary Notice Channel signifies renunciation of continuing consent to the Primary Notice Channel’s linked agreement.
Involuntary removal of a Member from the Primary Notice Channel does not signify renunciation of consent, unless and until the renunciation is expressly stated by the Member in writing received by at least one Channel Admin. Until renunciation, the removal should be treated as a mere temporary suspension from access to the Primary Notice Channel. Removed Members may seek reversal of any involuntary removal under the Wyoming Issue Dispute Resolution Agreement .
Intentional and voluntary departure of a Member from the Primary Notice Channel does not prejudice their rights (if any) accrued under the linked agreement prior to their departure, except for their right to receive any notice provided per the agreement via the Primary Notice Channel, which right may be treated as waived until the departed Member rejoins the Primary Notice Channel.
Reputation Slates
Within a License Hub, Members may comment on their personal experiences with other Members and their opinions of other Members’ strengths and weaknesses. Each Member is responsible for acting with integrity in doing so.
Additionally, Members may implement methods for generating, maintaining and using private, verifiable records of credentials and demerits received with each Member’s permission out of their interactions with other Members. Such reputation records may be called “Reputation Slates”.
WikiWe Reputation Slates should comply with the functional specification provided in the WikiWe Reputation Tracking Specification.
Not Everything Needs To Be Written Down, But Evidence Matters
Members are not required to create a document of record for every enforceable commitment or piece of evidence. However, Administrators and Members of WikiWe should encourage and support use of documents of record as described in this EC Guide, and may deprecate or disregard undocumented evidence when fair and reasonable under the circumstances.
Not every document of record represents an enforceable commitment. Many if not most documents of record are mere evidence of some fact, relationship, contribution, authorship, transaction, or the like, without stating any definite obligation.
It is convenient for documentary evidence to be identified and hashed using the same or compatible scheme as used for documents evidencing enforceable commitments. Some examples are provided under Standard Ontologies and Protocols below.
Example of Channel Administration for a Messaging App
The following provides a non-limiting example to guide administration of decentralized multi-lateral channels implemented using a messaging app.
- Each person signing an Agreement (the “Signer”) maintains an instance of the messaging application (e.g., the Signal Application available at https://signal.org/download/) on at least one computing device under their personal ownership and control.
- A person configuring an Agreement to be signed under this Memorandum includes a link to a channel of the messaging application for witnessing consent to the agreement (the “Primary Notice Channel”). The Primary Notice Channel should have the same title as the agreement to which it relates and must include a link to the agreement in its header.
- If the person configuring (”Configurer”) the Primary Notice Channel will not be a signer of the agreement, they should note their non-signer status in the Primary Notice Channel and leave the channel shortly after the first signer joins.
- Each Signer uses their messaging app user account on their own device to join the Primary Notice Channel indicated in the body of the agreement that is being signed, by following an expressly identified link to the agreement or pledge. Continued presence in the Primary Notice Channel counts as consent to the linked agreement. In this example, Agreement metadata is linked to the agreement only by the Primary Notice Channel. This may make it less convenient to prove consent to a person who is not a channel member.
For this and other reasons, at least one non-signing neutral (”Neutral”) who is identified as holding a non-signing Neutral role may be present in the Primary Notice Channel without being considered a Signer to the agreement, to act as a witness, administrator, or conciliator/arbitrator.
A designated Neutral or any Party may archive each new signed agreement or pledge in a separate secure location in case the Primary Notice Channel becomes generally unavailable or unusable, and in such case may provide an alternative means for witnessing consent to the agreement that preserves as much as possible the function of the Primary Notice Channel.
Each Signer agrees that they will not use the Primary Notice Channel except for valid business related to its linked agreement and accepts responsibility for their misuse.
In the event that a Signer changes their messaging app Account, they may use the new account for communication in the Primary Notice Channel instead of their prior account, so long as identifying and certifying their identity in the Primary Notice Channel. In this case, substitution of a messaging app account shall not be treated as a new signature, and the original signature date of the Signer shall be respected.
Voluntary departure of a Signer from the Primary Notice Channel shall not prejudice their rights under the pertinent agreement except for their right to receive any notice provided per the agreement via the Primary Notice Channel, which right may be treated as waived until the departed Signer rejoins the Primary Notice Channel per the Witness Protocol above.
If due to a breach in security any unauthorized person who is not eligible to become a Signer or Neutral joins the Primary Notice Channel, or in the event of abuse of the Primary Notice Channel, the Neutral may remove the account of the offending person from the Primary Notice Channel after applicable due process per the Wyoming Issue Dispute Resolution Agreement, or immediately on an emergency basis if warranted by extraordinary abuse causing or likely to cause irreparable harm. The Neutral shall be responsible for any unwarranted ejections.
Standard Ontologies and Protocols
Standard ontologies and protocols for enforceable commitments can undoubtedly be useful. However, in a decentralized association such as WikiWe, locking in detailed ontologies and protocols might be unduly limiting. Therefore, aspects of enforceable commitments not clearly specified in his EC Guide are left open for experimentation for all on a voluntary basis, with all taking responsibility for their own choices.
Nonetheless, the following naming and hashing conventions are proposed as a starting points for evidencing enforceable commitments and other facts and intentions to be made of record. Members who improve upon or extend the ontologies and protocols described in this EC Guide should, after testing their improvements, propose revisions to this EC Guide so that all WikiWe members can share in the benefits.
Metadata and Hashing: All Documents
A WikiWe document is a set of content, metadata, and related hashes. All documents can be attached to least the following metadata:
| Mutability | Necessary | Optional |
|---|---|---|
| Immutable | Created Date Entire content hash | Author(s) identifier(s) Title Document class |
| Mutable | Content version Content address Content address of most recent precedent | |
| Every document should include at least one hash of the entire content, and at least one hash of the document metadata. Additional hashes may be provided at the discretion of the document designer. |
Preferably, the content storage address should be discernable from the document’s metadata hash, which depends, in turn, on the content hash among things.
Hash security should not be less than SHA-256.
The document classes listed below are non-limiting examples. Members may invent other document classes, but those listed are believed to cover currently foreseeable documentary transactions.
Whether a set of data complies with this EC Guide depends on the substance of its context and content, including at least its visibility, authenticability, semantic content, and metadata, wherein substance and effect take precedence over form.
Metadata may be attached to a document in any authenticatable manner, including but not limited to placing in a wrapper of a document file, adding to a header, footer, or other location of a header file, and/or by placing messages in a communication channel linked to the document file (e.g., as provided in the example above).
Agreements
In addition to metadata for all documents, Agreements are attached to at least the following metadata:
| Mutability | Necessary | Optional |
|---|---|---|
| Immutable | Effective date Identifier of each party Signature of each party | Signature timestamp of each signer License Hub or group identifier Expiration date |
| Mutable | Notice address of each party | |
Pledges
In addition to metadata for all documents, Pledges are attached to at least the following metadata:
| Mutability | Necessary | Optional |
|---|---|---|
| Immutable | Effective date Identifier of pledger Signature of pledger | Signature timestamp of pledger License Hub or group identifier Expiration date |
| Mutable | Notice address of pledger | Feedback Licensee |
| A “Feedback Licensee” is an identifier for a person receiving a WikiWe Feedback License. |
Social Promises
In addition to metadata for all documents, Social Promises are attached to at least the following metadata:
| Mutability | Necessary | Optional |
|---|---|---|
| Immutable | Effective date Identifier of promisor Signature of promisor | Signature timestamp of promisor Expiration date |
| Mutable | Notice address of promisor Feedback Licensee |
Declarations
Declarations are signed statements of fact without any enforceable commitment. Wills, trusts, affidavits, and credentials are use cases for Declarations.
In addition to metadata for all documents, Declarations are attached to at least the following metadata:
| Mutability | Necessary | Optional |
|---|---|---|
| Immutable | Identifier of declarant Signature of declarant | Signature timestamp of declarant |
| Mutable | Notice address of declarant |
Contributions
In addition to metadata for all documents, contributions of content to a License Hub are attached to at least the following metadata:
| Mutability | Necessary | Optional |
|---|---|---|
| Immutable | Identity of author(s) Contribution date License Hub or group identifier | Identity of contributor |
| Mutable | Notice address of each author |
Invoices and Claims
In addition to metadata for all documents, invoices and claims are attached to at least the following metadata:
| Mutability | Necessary | Optional |
|---|---|---|
| Immutable | Identifier of claimant Identifier of obligor Basis for claim (document ID) First presented date | Amount License Hub or group identifier Type (business or personal) |
| Mutable | Payment channel for claimant Notice address for claimant |
Settlements and Receipts
In addition to metadata for all documents, settlements and receipts are attached to at least the following metadata:
| Mutability | Necessary | Optional |
|---|---|---|
| Immutable | Settlement date Identifier of recipient Identifier of payer Identity of author Signature of author | Signature of recipient Signature timestamp of each signer Amount |
| Mutable | Notice address of author |
Revocations and Resignations
Any Member may unilaterally resign from a role, or revoke privileges they have obliged themselves to provide to another, using a revocation/resignation document. Making a revocation/resignation of record does not excuse the revoker/resigner from responsibility for their previously assumed obligations, but if communicated clearly should cut off formation of new obligations based on the revoked document. Settlements with mutual releases should be recorded using a settlement document.
In addition to metadata for all documents, revocations and resignations are attached to at least the following metadata:
| Mutability | Necessary | Optional |
|---|---|---|
| Immutable | Effective Date Identifier of revoker/resigner Signature of revoker/resigner Identity of obligation being revoked (e.g., document ID) | Signature timestamp of revoker/resigner License Hub or group identifier |
| Mutable | Notice address of revoker/resigner |