Class: Rules

Rules

Represents Storj protocol handlers

new Rules(node)

Constructs a Storj rules instance in the context of a Storj node
Parameters:
Name Type Description
node StorjNode
Source:

Methods


audit(request, response)

Upon receipt of a AUDIT message, the node must look up the contract that is associated with each hash-challenge pair in the payload, prepend the challenge to the shard data, and caclulate the resulting hash, formatted as a compact proof. See compact-proofs.
Parameters:
Name Type Description
request object
response object
Source:

claim(request, response)

Upon receipt of an `CLAIM` message, nodes must validate the descriptor, then ensure that there is enough available space for the shard. If both checks succeed, then the descriptor is signed and returned along with a consignment token so the initiating renter can immediately upload the data. This call is the functional inverse of `OFFER`, as it is used for a renter to signal to a farmer that it wishes to rent capacity. These messages are generally sent based on information collected when subscribed to farmer capacity publications.
Parameters:
Name Type Description
request object
response object
Source:

consign(request, response)

Upon receipt of a CONSIGN message, the node must verify that it has a valid storage allocation and contract for the supplied hash and identity of the originator. If so, it must generate an authorization token which will be checked by the shard server before accepting the transfer of the associated shard.
Parameters:
Name Type Description
request object
response object
Source:

mirror(request, response)

Upon receipt of a MIRROR message, the node must verify that it is in possesion of the shard on behalf of the identity or the message originator. If so, given the token-hash pair, it must attempt to upload it's copy of the shard to the target to establish a mirror.
Parameters:
Name Type Description
request object
response object
Source:

offer(request, response)

Upon receipt of an OFFER message, nodes must validate the descriptor, then ensure that the referenced shard is awaiting allocation(s). If both checks succeed, then the descriptor is added to the appropriate offer processing stream. Once the descriptor is processed, we respond back to the originator with the final copy of the contract.
Parameters:
Name Type Description
request object
response object
Source:

probe(request, response)

Upon receipt of a PROBE message, the node must attempt to send a PING message to the originator using the declared contact information. If successful, it must respond positively, otherwise error.
Parameters:
Name Type Description
request object
response object
Source:

renew(request, response)

Upon receipt of a RENEW message, the recipient farmer must extend or terminate it's contract based on the new terms supplied by the renter. If the renewal descriptor is valid and complete, the farmer must store the updated version after signing and respond back to the originator with the version containing the updated signature.
Parameters:
Name Type Description
request object
response object
Source:

retrieve(request, response)

Upon receipt of a RETRIEVE message, the node must verify that it is in possession of the shard on behalf of the identity of the originator. If so, it must generate an authorization token which will be checked by the shard server before accepting the transfer of the associated shard.
Parameters:
Name Type Description
request object
response object
Source: