Module moderated_join 

Joins through a refersTo: moderatedDocument property: the removal records a chained or composite join proves beside the documents it joins. See the module docs. Joins through a refersTo: moderatedDocument property: the removal records a join proves beside the documents it joins.

A moderatedDocument reference promises its target is in state or was removed by the contract’s moderators, on the record: the document type keeps a removal record for every document a moderator deletes, and its documents leave state no other way. So a by-id join off such a property (chained or composite) proves, beside the by-ids fetch of the joined documents, the removal records of the same ids, one more component of the one merged proof: [removals_path_query]. A joined id with no document is then reported with its proven record ([pair_missing_with_removals]), and an id with neither is refused, as a missing permanentDocument target is: corrupted state on the server, an invalid proof in the verifier.

The component names every joined id, not only the ones missing a document: the verifier builds the merged query before it knows which are missing, and grovedb proves each queried key present or absent, so a prover can pass neither a removed document off as live nor a live one off as removed.

Functions

decode_removals

Decodes the proved (or fetched) entries of a removals_path_query, by document id. A malformed record, or one proved twice, is a corrupted proof.

pair_missing_with_removals

The records of the joined ids missing that have no document, in their order, from removals. Each must have a record that stands, unrestored: a restored record describes a document that is live again. An id without one means the target left state without a moderator’s recorded removal, which a moderatedDocument target can not, so it is refused.

removals_path_query

The removal records of document_ids within one document type of one contract, each proved present or absent: the removals query by ids (Drive::contract_document_removals_query), unlimited, as the by-ids fetch of the documents it sits beside is (the ids bound it), and walking in left_to_right so it merges with the components it is proven beside (its selection does not depend on the direction). The ids are queried in canonical byte order, so the prover and a verifier that collected them in any order build the same query.