Customer <> service-provider commercial engagement

[arjunhassard]

First of multiple Issues relating to NuCypher market design, with the aim of exploring the system constraints and crystallising the engagement between customers (Alices) and service-providers (Ursulas). Starting with how this flow looks today:

1. Alice has created and parameterized an Arrangement.
   def __init__(self, alice, expiration, ursula=None, arrangement_id=None, kfrag=UNKNOWN_KFRAG, value=None, alices_signature=None) -> None:

• Duration is specified (today -> expiration), this is the input for calculating the price (per policy).
• A deposit is included to compensate participating Ursulas (value). Is this reassurance that the data owner has enough funds? Should this cover the entirety of the eventual payment? If not, how does Ursula know they will be paid in full?
• m and n are not included in the arrangement, but have been specified via the grant function

2. This arrangement is now broadcasted out to various Ursulas – selected at random, but weighted by the size of the segments of their respective stakes that satisfy the duration criteria.
   *If many Alices choose specific nodes (handpicked_ursulas), it may change the nature of the market, as it introduces competition between service-providers. More on this in Customer choice (handpicking nodes)  #5.
   *The number of jobs/policies an Ursula is currently responsible for has no impact on the selection process. In the future this could even out demand.

3. The Ursulas who receive the arrangement choose whether or not to accept it.
   def consider_arrangement(): from nucypher.policy.models import Arrangement arrangement = Arrangement.from_bytes(request.data)
   *On what basis are Ursulas accepting/rejecting arrangements, given their contents? Arrangement durations will equal or be shorter than an existing commitment to the network, so that's not a good reason. Certain Ursulas may seek to optimise their margins (i.e. avoid high overheads), but blindly rejecting arrangements is unlikely to help, so the only exception is if the Ursula anticipates a particularly large amount of access requests (e.g. they work out an arrangement was sent by a Telegram-like application). If that became a widespread strategy, this would jeopardise the network scaling and likely require changing the compensation model.
   *Giving Ursulas the right to reject arrangements introduces uncertainty and latency for data owners / developers, who are accustomed to ~100% predictability and immediate responses from existing key management systems.
   *Ursulas rejecting arrangements may also clash with an over-arching objective to commoditise the access control service – i.e. provide a predictable, uniform service for a uniform payment. Indeed, a single network price for a given policy duration would make it even less rational to reject an arrangement, as there is definitely no prospect of a better offer around the corner.

4. Alice waits until n Ursulas accept her arrangement proposal.
   *Is the system sequentially approaching Ursulas (or batches of Ursulas) until enough accept? If so, how long does it wait before the next Ursula/batch is contacted? Is there a situation where an Ursula accepts, only to find that the "position has been filled"?

5. Once n Ursulas accept the arrangement....
   *Before publishing, Alice can still decide to cancel the arrangement and create a new one, without paying out anything.
   *If the deposit is not enough to cover the total cost of the participating Ursulas for the duration, does Alice now add more funds (now she knows how many Ursulas to pay)?

6. The policy is live. Participating Ursulas perform their duties and are compensated.
   *Compensation is split into tranches, and spaced out to fit the duration of the corresponding policy?

7. Alice can revoke the arrangement for all or any of the participating Ursulas. She has to 'pay for the period in which the revocation is requested'.
   *A 'period' is a single cycle, so just one day – is this enough of a disincentive? The ditched Ursula may be gearing up for a long commitment, only to be dropped with zero notice or severance pay.

[cygnusv]

1. The Ursulas who receive the arrangement choose whether or not to accept it.

def consider_arrangement(): from nucypher.policy.models import Arrangement arrangement = Arrangement.from_bytes(request.data)

*On what basis are Ursulas accepting/rejecting arrangements, given their contents? Arrangement durations will equal or be shorter than an existing commitment to the network, so that's not a good reason. Certain Ursulas may seek to optimise their margins (i.e. avoid high overheads), but blindly rejecting arrangements is unlikely to help, so the only exception is if the Ursula anticipates a particularly large amount of access requests (e.g. they work out an arrangement was sent by a Telegram-like application). If that became a widespread strategy, this would jeopardise the network scaling and likely require changing the compensation model.
*Giving Ursulas the right to reject arrangements introduces uncertainty and latency for data owners / developers, who are accustomed to ~100% predictability and immediate responses from existing key management systems.
*Ursulas rejecting arrangements may also clash with an over-arching objective to commoditise the access control service – i.e. provide a predictable, uniform service for a uniform payment. Indeed, a single network price for a given policy duration would make it even less rational to reject an arrangement, as there is definitely no prospect of a better offer around the corner.

I agree with your view here. In fact, although the methods are there, currently there's no logic to actually consider arrangements (see https://github.com/nucypher/nucypher/blob/master/nucypher/network/server.py#L219). As you can see, arrangements are blindly accepted.