Requesting scenario #105
Requesting scenario #105
Conversation
prekucki
force-pushed
the
prek/requestor-story
branch
from
e569c56
to
e768d1c
Compare
| For the created DEMAND, the Requestor receives a stream of agreement proposals. The proposals can be of two types: | ||
|
|
||
| Initial | ||
| : An offer presented to the network in general without knowledge of the other party. Such an offer should be reviewed, and the Requestor should specify their expectations regarding the contract. An example of such an interaction is reading the list of networks on which the Provider can receive payments and choosing the one preferred by the Requestor. |
There was a problem hiding this comment.
I think I'd simply defer to @nieznanysprawiciel 's explanation of this procedure in #104 .
|
|
||
| #### Step 7: Service Activation and Contract Supervision | ||
|
|
||
| With an active contract, the Requestor activates the service by creating an Activity. Using the Activity object, they send a request to activate access to the node with a specified access password. In response, they receive the service details. |
There was a problem hiding this comment.
I don't get it - where does the password come from and what does it protect?
|
|
||
| With an active contract, the Requestor activates the service by creating an Activity. Using the Activity object, they send a request to activate access to the node with a specified access password. In response, they receive the service details. | ||
|
|
||
| The Requestor's application connects directly to the provided endpoint to verify that it is functioning correctly. |
There was a problem hiding this comment.
I'm sorry but I don't understand. What's an endpoint in this context? Requestor Agent and Provider Agent where able to make contact already to reach an Agreement (we intentionally skipped the details of how this happens) - is this some different communication channel?
| - In the case of a pay-as-you-go contract, at regular intervals, billing records called DebitNotes are sent to the Requestor. These contain the number of requests made, the service uptime, and the resulting fee. The Requestor must verify that this data is accurate and either confirm the upcoming payment or terminate the contract. | ||
| - The Requestor monitors the service on the Provider's side to avoid sending tasks to malfunctioning providers. | ||
|
|
||
| For long-running services, it's necessary to extend the allocation to ensure sufficient funds are available. |
There was a problem hiding this comment.
Both you and @nieznanysprawiciel (in #104) have described this already. I think @nieznanysprawiciel has gone further with refining his version, so let's just refer to his explanation and extend it with whatever is not present there.
|
|
||
| For long-running services, it's necessary to extend the allocation to ensure sufficient funds are available. | ||
|
|
||
| #### Step 8: Contract Closure |
There was a problem hiding this comment.
Just like previous section, let's use the one from #104
No description provided.