Merge branch 'master' into marketplace-B

LICENSE

@@ -0,0 +1,121 @@
+Creative Commons Legal Code
+
+CC0 1.0 Universal
+
+    CREATIVE COMMONS CORPORATION IS NOT A LAW FIRM AND DOES NOT PROVIDE
+    LEGAL SERVICES. DISTRIBUTION OF THIS DOCUMENT DOES NOT CREATE AN
+    ATTORNEY-CLIENT RELATIONSHIP. CREATIVE COMMONS PROVIDES THIS
+    INFORMATION ON AN "AS-IS" BASIS. CREATIVE COMMONS MAKES NO WARRANTIES
+    REGARDING THE USE OF THIS DOCUMENT OR THE INFORMATION OR WORKS
+    PROVIDED HEREUNDER, AND DISCLAIMS LIABILITY FOR DAMAGES RESULTING FROM
+    THE USE OF THIS DOCUMENT OR THE INFORMATION OR WORKS PROVIDED
+    HEREUNDER.
+
+Statement of Purpose
+
+The laws of most jurisdictions throughout the world automatically confer
+exclusive Copyright and Related Rights (defined below) upon the creator
+and subsequent owner(s) (each and all, an "owner") of an original work of
+authorship and/or a database (each, a "Work").
+
+Certain owners wish to permanently relinquish those rights to a Work for
+the purpose of contributing to a commons of creative, cultural and
+scientific works ("Commons") that the public can reliably and without fear
+of later claims of infringement build upon, modify, incorporate in other
+works, reuse and redistribute as freely as possible in any form whatsoever
+and for any purposes, including without limitation commercial purposes.
+These owners may contribute to the Commons to promote the ideal of a free
+culture and the further production of creative, cultural and scientific
+works, or to gain reputation or greater distribution for their Work in
+part through the use and efforts of others.
+
+For these and/or other purposes and motivations, and without any
+expectation of additional consideration or compensation, the person
+associating CC0 with a Work (the "Affirmer"), to the extent that he or she
+is an owner of Copyright and Related Rights in the Work, voluntarily
+elects to apply CC0 to the Work and publicly distribute the Work under its
+terms, with knowledge of his or her Copyright and Related Rights in the
+Work and the meaning and intended legal effect of CC0 on those rights.
+
+1. Copyright and Related Rights. A Work made available under CC0 may be
+protected by copyright and related or neighboring rights ("Copyright and
+Related Rights"). Copyright and Related Rights include, but are not
+limited to, the following:
+
+  i. the right to reproduce, adapt, distribute, perform, display,
+     communicate, and translate a Work;
+ ii. moral rights retained by the original author(s) and/or performer(s);
+iii. publicity and privacy rights pertaining to a person's image or
+     likeness depicted in a Work;
+ iv. rights protecting against unfair competition in regards to a Work,
+     subject to the limitations in paragraph 4(a), below;
+  v. rights protecting the extraction, dissemination, use and reuse of data
+     in a Work;
+ vi. database rights (such as those arising under Directive 96/9/EC of the
+     European Parliament and of the Council of 11 March 1996 on the legal
+     protection of databases, and under any national implementation
+     thereof, including any amended or successor version of such
+     directive); and
+vii. other similar, equivalent or corresponding rights throughout the
+     world based on applicable law or treaty, and any national
+     implementations thereof.
+
+2. Waiver. To the greatest extent permitted by, but not in contravention
+of, applicable law, Affirmer hereby overtly, fully, permanently,
+irrevocably and unconditionally waives, abandons, and surrenders all of
+Affirmer's Copyright and Related Rights and associated claims and causes
+of action, whether now known or unknown (including existing as well as
+future claims and causes of action), in the Work (i) in all territories
+worldwide, (ii) for the maximum duration provided by applicable law or
+treaty (including future time extensions), (iii) in any current or future
+medium and for any number of copies, and (iv) for any purpose whatsoever,
+including without limitation commercial, advertising or promotional
+purposes (the "Waiver"). Affirmer makes the Waiver for the benefit of each
+member of the public at large and to the detriment of Affirmer's heirs and
+successors, fully intending that such Waiver shall not be subject to
+revocation, rescission, cancellation, termination, or any other legal or
+equitable action to disrupt the quiet enjoyment of the Work by the public
+as contemplated by Affirmer's express Statement of Purpose.
+
+3. Public License Fallback. Should any part of the Waiver for any reason
+be judged legally invalid or ineffective under applicable law, then the
+Waiver shall be preserved to the maximum extent permitted taking into
+account Affirmer's express Statement of Purpose. In addition, to the
+extent the Waiver is so judged Affirmer hereby grants to each affected
+person a royalty-free, non transferable, non sublicensable, non exclusive,
+irrevocable and unconditional license to exercise Affirmer's Copyright and
+Related Rights in the Work (i) in all territories worldwide, (ii) for the
+maximum duration provided by applicable law or treaty (including future
+time extensions), (iii) in any current or future medium and for any number
+of copies, and (iv) for any purpose whatsoever, including without
+limitation commercial, advertising or promotional purposes (the
+"License"). The License shall be deemed effective as of the date CC0 was
+applied by Affirmer to the Work. Should any part of the License for any
+reason be judged legally invalid or ineffective under applicable law, such
+partial invalidity or ineffectiveness shall not invalidate the remainder
+of the License, and in such case Affirmer hereby affirms that he or she
+will not (i) exercise any of his or her remaining Copyright and Related
+Rights in the Work or (ii) assert any associated claims and causes of
+action with respect to the Work, in either case contrary to Affirmer's
+express Statement of Purpose.
+
+4. Limitations and Disclaimers.
+
+ a. No trademark or patent rights held by Affirmer are waived, abandoned,
+    surrendered, licensed or otherwise affected by this document.
+ b. Affirmer offers the Work as-is and makes no representations or
+    warranties of any kind concerning the Work, express, implied,
+    statutory or otherwise, including without limitation warranties of
+    title, merchantability, fitness for a particular purpose, non
+    infringement, or the absence of latent or other defects, accuracy, or
+    the present or absence of errors, whether or not discoverable, all to
+    the greatest extent permissible under applicable law.
+ c. Affirmer disclaims responsibility for clearing rights of other persons
+    that may apply to the Work or any use thereof, including without
+    limitation any person's Copyright and Related Rights in the Work.
+    Further, Affirmer disclaims responsibility for obtaining any necessary
+    consents, permissions or other rights required for any use of the
+    Work.
+ d. Affirmer understands and acknowledges that Creative Commons is not a
+    party to this document and has no duty or obligation with respect to
+    this CC0 or use of the Work.

README.md

@@ -1,2 +1,26 @@
-# codex-spec
-Specs for Codex network
+## Codex Specifications
+
+Codex is building a decentralized durability engine aiming to allow users to have data persistence.
+This repository contains Codex specifications currently under discussion.
+
+Visit the official [Codex website](https://codex.storage/) for more information about the project.
+
+Note: Codex is still under active development. 
+Specifications located in this repository should be considered not production-ready.
+Discussion is held with the intention of maturing each specification.
+
+## Contributing
+
+Contributors are welcome to create a new pull request to discuss a topic related to the Codex protocol.
+When writing specifications,
+it is recommended to adhere to the [1/COSS](https://github.com/vacp2p/rfc-index/blob/main/vac/1/coss.md) guidelines.
+
+Please adhere to the following guidelines:
+
+- Name and title of all specifications must have the `CODEX-` prefix
+- Try to use [semantic breaks](https://sembr.org/)
+- Use the [template](./template.md) to help construct specifications
+
+## License
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

specs/marketplace.md

@@ -235,7 +235,8 @@ Note that one SP node can fill more than one slot.
 If the SP node decides to ignore the request, no further action is required.
 However, if the SP node decides to fill a slot, it MUST follow the remaining steps described below.
 
-An SP node MUST decide which slot, specified by the slot index, it wants to fill. The SP node MAY attempt to fill more than one slot. To fill a slot, the SP node MUST first download the slot data using the CID of the manifest (**TODO: Manifest RFC**) and the slot index. The CID is specified in `request.content.cid`, which can be retrieved from the smart contract using `getRequest(requestId)`. Then, the node MUST generate a proof over the downloaded data (**TODO: Proving RFC**).
+
+An SP node MUST decide which slot, specified by the slot index, it wants to fill. The SP node MAY attempt to fill more than one slot. To fill a slot, the SP node MUST first reserve the slot in the smart contract using `reserveSlot(requestId, slotIndex)`. If reservations for this slot are full, or if the SP has already reserved the slot, the transaction will revert. If the reservation was unsuccessful, then the SP is not allowed to fill the slot. If the reservation was successful, the node MUST then download the slot data using the CID of the manifest (**TODO: Manifest RFC**) and the slot index. The CID is specified in `request.content.cid`, which can be retrieved from the smart contract using `getRequest(requestId)`. Then, the node MUST generate a proof over the downloaded data (**TODO: Proving RFC**).
 
 When the proof is ready, the SP node MUST make a transaction calling `fillSlot()` on the smart contract with the following REQUIRED parameters:
 
@@ -256,6 +257,7 @@ In response, the SP node SHOULD stop its current operation and attempt to fill a
 
 ### Proving
 
+
 Once an SP node fills a slot, it MUST submit proofs to the smart contract when a challenge is issued by the contract. SP nodes SHOULD detect that a proof is required for the current period using the `isProofRequired(slotId)` function, 
 or that it will be required using the `willProofBeRequired(slotId)` function in the case that the [pointer is in downtime](https://github.com/codex-storage/codex-research/blob/41c4b4409d2092d0a5475aca0f28995034e58d14/design/storage-proof-timing.md).
 

template.md

@@ -0,0 +1,65 @@
+---
+title: TEMPLATE
+name: Codex Specification Template
+category: (Standards Track|Informational|Best Current Practice)
+tags: an optional list of tags, not standard
+editor: Jimmy Debe <jimmy@status.im>
+contributors:
+---
+
+### (Info, remove this section)
+
+This section contains meta info about writing specifications.
+This section (including its subsections) MUST be removed.
+
+[COSS](https://rfc.vac.dev/spec/1/) explains the Vac RFC process.
+
+### Tags
+
+The `tags` metadata SHOULD contain a list of tags if applicable.
+
+## Abstract
+
+
+## Background / Rationale / Motivation
+
+This section serves as an introduction providing background information and a motivation/rationale for the specification.
+
+## Theory / Semantics / Specification
+
+This section SHOULD explain in detail how the proposed protocol works.
+It may touch on the wire format where necessary for the explanation.
+This section MAY also specify endpoint behaviour when receiving specific messages, e.g. the behaviour of certain caches etc.
+
+## Wire Format Specification / Syntax
+The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, 
+“NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
+
+This section SHOULD not contain explanations of semantics and focus on concisely defining the wire format.
+Implementations SHOULD adhere to these exact formats to interoperate with other implementations.
+It is fine, if parts of the previous section that touch on the wire format are repeated.
+The purpose of this section is having a concise definition of what an implementation sends and accepts.
+Parts that are not specified here are considered implementation details. 
+Implementors are free to decide on how to implement these details.
+
+
+## Implementation Suggestions (optional)
+An optional *implementation suggestions* section may provide suggestions on how to approach implementation details, and, 
+if available, point to existing implementations for reference.
+
+
+## (Further Optional Sections)
+
+
+## Security/Privacy Considerations
+
+If there are none, this section MAY state that fact.
+This section MAY contain additional relevant information, e.g. an explanation as to why there are no security consideration for the respective document.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
+
+## References
+
+A list of references.