[GAP-17] Offline requestor model #40

stranger80 · 2021-12-26T19:06:19Z

Design specification of the generic Offline Requestor model.
The Offline Requestor mechanics may include payment via a smart contract, which receives funding from requestor, and performs payments while requestor is offline. The GAP should specify the logic of such a basic payment smart contract.

johny-b · 2022-07-04T10:37:54Z

gaps/gap-17_offline_requestor_model/gap-17_offline_requestor_model.md

+This GAP introduces following features which are aimed at enabling the "offline Reuqestor" scenarios listed above:
+- Activity Attach/Detach
+- Self-sustained Payments
+- Agreement Permissions Management


Just a thought:

Agreement Permissions Management is a separate feature that has many use cases that have nothing to do with the "offline requestor". E.g. developer who creates an app that is supposed to run on Golem might prefer to rent (buy?) agreements from some third party, let's call them "broker". This way, from the developer POV:

There is no strategy-related complexity

There is no payment-related complexity (e.g. broker service could just support Mastercard)

Broker can handle some part of the risk (e.g. agreements that were ended by the provider are "free" for the end user, and broker pays-or-not-pays the provider, but from the developer POV this doesn't matter)

Actually, I wouldn't be surprised if this became the main way developers interact with Golem in the future.

-->

I think this topic might deserve a separate GAP ...

... that should be a little more general - e.g. we might want to rent activities, not agreements?

There is now a separate GAP for this: #56

shadeofblue · 2022-07-06T08:03:43Z

gaps/gap-17_offline_requestor_model/gap-17_offline_requestor_model.md

+- Requestor daemon may reconnect at any time, and exercise control over the Activity via ExeScript
+
+**Notes:**
+- This scenario is only possible with payment schemes which assume upfront payment or allow long intervals between payments or with self-sustained payment


Suggested change

- This scenario is only possible with payment schemes which assume upfront payment or allow long intervals between payments or with self-sustained payment

- This scenario is only possible with payment schemes which:

* either assume upfront payment,

* or allow long intervals between payments,

* or are self-sustained and not depending on the presence of the daemon.

shadeofblue · 2022-07-06T08:11:12Z

gaps/gap-17_offline_requestor_model/gap-17_offline_requestor_model.md

+    - The HL API implementations shall include the ability to obtain a "live" instance of Activity object and corresponding Agreement object based on `activityID`, and then perform actions on them (ExeScript command execution and results processing, Agreement control, including termination), as in the following pseudo-code example:
+       ```
+       ...
+       activity = Golem.attach_activity(activityId)   # returns an "attached" Activity object, which can then be used to manipulate the Activity


actually, it doesn't have to be attach_activity ... maybe, in this scenario it suffices for the activity to be instantiated -> iow:

activity = Activity(activityId)

Attaching would be required if we wanted to resume a current high-level Task/Service worker with the given activity... but then, the engine would need to gather also other data, like agreement ids, etc

Actually I believe this should be an explicit operation on a Golem object, which is representing the "context" in which the Activity resides.

Alternative 'style' would be to create an Activity object and populate its ID, then 'attach' it to the Golem context, for the engine to 'hydrate' it (reconcile against current state and populate resptective Activity properties):

... activity = Activity(activityId) activity = Golem.attach_activity(activity) ...

...but the 'shorthand' syntax I've proposed in the GAP text seems 'lighter', so I prefer that.

Just FYI, my current version is

golem = GolemNode() activity = golem.activity(activity_id)

and this only initializes the Activity object (doesn't even validate the activity_id).

OK, but in case an Activity with a given activity_id exists on the network - will golem "attach" itself to it and allow the subsequent control?

I'm not sure if I understand the question.

GolemNode objects corresponds to a (YAGNA_URL, APP_KEY) pair. If this is enough to control the activity, it will allow the subsequent control. It doesn't matter if the activity was created with this GolemNode instance or not (or in this script run, or this yagna instance).

IOW, I think that if you created an activity and shared with me activity_id and your APP_KEY I could do:

async with GolemNode() as golem: activity = golem.activity(activity_id) activity.execute_command(...)

without additional effort (except for setting yagna identity with the same APP_KEY).
(I might be missing something, but in principle this is how this should work, I think?).

...OK, cool, and for example if we do this:

async with GolemNode() as golem: activity = golem.activity(activity_id)

...will the activity object correctly represent the actual state of the Activity?

Yes, but you'll need an additional call

async with GolemNode() as golem: activity = golem.activity(activity_id) state = await activity.get_state()

After some more consideration, I decided I don't understand what is "attach" and "detach" in your model :/ For me, every entity with activity_id and credentials is "attached" (i.e. it can interact with the Activity).
So - sorry if my answers don't make sense :)

nieznanysprawiciel · 2022-08-12T13:10:47Z

gaps/gap-17_offline_requestor_model/gap-17_offline_requestor_model.md

+- Requestor daemon remains online until Agreement is signed and Activity started
+- Requestor daemon transfers grants control rights to another node/identity, which remains online and exercises control over the Activity 


I would say, that in case of delegating permissions, Requestor doesn't even have to sign Agreements. If other service is responsible for sustaining the execution of tasks, than it needs the ability to sign Agreements on behalf of this Requestor. In such scenario sustain service could initialize everything by himself.

Sorry for delay on commenting this.

The "Scenario C" is purely about the ability to delegate control to an already signed Agreement (which is paid by whatever payment method/platform negotiated by original Requestor). This is not about delegating rights to "token pool" owned by the original Requestor to another Requestor. For two primary reasons:

Delegating rights to create agreement from "offline Requestor" to another Requestormakes the latter, well, an "online Requestor" :)

I don't want to propose a generic way of delegating rights to a "token pool".

The scenario where original "bootstrap" Requestor only initiates an application with initial set of Agreements and then empowers other nodes to create new Agreements - I would like to handle in a slightly different way, via a [GAP-18] "drip-feed payment contract" (so allowing other nodes to manage am onchain payment mechanism), and [GAP-19] "Golem Supervisor concept". Please bear with me.

stranger80 · 2023-01-12T15:00:51Z

Review 12.01.2023:

How to handle situations where Requestor goes offline while there are some inflight actions - eg. we launch exescript with 10 commands, 5 of them completed, 5 are still pending, and Requestor goes offline - what should happen there?
- For ExeScript batches: after re-attaching it should be possible to resume the reception of results returned by remaining 5 commands.?
- what about streaming results?
- maybe it should be impossible to detach while there is unfinished ExeScript command pending?

…ine_requestor_model

nieznanysprawiciel · 2023-02-08T11:25:04Z

gaps/gap-17_offline_requestor_model/gap-17_offline_requestor_model.md

+#### **Feature: Agreement Permissions Management**
+In order to support scenarios where control delegation from Requestor to a different Golem node is performed, the Golem APIs must include a concept of permissions and grants. 
+
+This feature is described in a dedicated [GAP-24](). 


Broken link

nieznanysprawiciel · 2023-02-08T11:25:16Z

gaps/gap-17_offline_requestor_model/gap-17_offline_requestor_model.md

+As self-susteined payment mechanisms are to be provided by specific, distinguished payment platform & scheme implementations, the Golem nodes and Agent applications will ensure compatibility by indicating respective payment conditions via properties & constraints in Demands & Offers. Therefore only nodes which support self-sustained payments will enter an Agreement, so backwards compatibility will be ensured.
+
+### Agreement Permissions Management
+See relevant [GAP-24]() for details.


Broken link

nieznanysprawiciel · 2023-02-08T11:29:10Z

gaps/gap-17_offline_requestor_model/gap-17_offline_requestor_model.md

+This scenario is implemented only on Agent application level (so in HL API library), so backwards compatibility is ensured between a "new" HL API library implementation and "legacy" `yagna` daemon implementation (as no `yagna` REST API changes are required).
+
+#### 2. Requestor `yagna` daemon goes offline
+**IMPORTANT** Will current Golem net implementations (eg. "hybrid net") support a scenario where `yagna` daemon is reconnecting to network after downtime?


nieznanysprawiciel · 2023-02-08T11:40:51Z

Review 12.01.2023:

* How to handle situations where Requestor goes offline while there are some inflight actions - eg. we launch exescript with 10 commands, 5 of them completed, 5 are still pending, and Requestor goes offline - what should happen there?
  
  * For ExeScript batches: after re-attaching it should be possible to resume the reception of results returned by remaining 5 commands.?
  * what about streaming results?
  * maybe it should be impossible to detach while there is unfinished ExeScript command pending?

This touches topic of developer UX discussions that we had lately with SDK team. There are other aspects of querying commands results, for example:

If you have run command in batch, that spawns background process, you would like to still be able to query it's results.
- That means that you should be able to query results of any command in batch, not only the executing one
We would like to execute many batches at the same time
- So we need to be able to access output of arbitrary command

For sure we are no able to enforce, that Requestor won't detach from activity before commands are finished.
And even if we would, I wouldn't like to do this.
I think we need to have good introspection API, that will allow Requestor to re-attach and see what is the state of ExeUnit.

GAP-17 Offline reuqestor model placeholder

a91f24b

stranger80 added the GAP: Feature GAP type: Feature label Dec 26, 2021

GAP 17 specification - initial sketch

e23cf54

johny-b reviewed Jul 4, 2022

View reviewed changes

shadeofblue reviewed Jul 6, 2022

View reviewed changes

stranger80 added 2 commits July 18, 2022 23:07

Applying review changes.

e87e800

GAP-17 almost complete

506a1f0

nieznanysprawiciel reviewed Aug 12, 2022

View reviewed changes

stranger80 added 4 commits January 29, 2023 21:49

Merge remote-tracking branch 'origin/master' into stranger80/GAP/offl…

f3bd3cc

…ine_requestor_model

Attach/detach and inflight API calls

d2a1c05

Finishing touches

99c3ff2

Finishing touches

61f6d2b

stranger80 merged commit 2f3f8f9 into master Jan 29, 2023

nieznanysprawiciel reviewed Feb 8, 2023

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[GAP-17] Offline requestor model #40

[GAP-17] Offline requestor model #40

stranger80 commented Dec 26, 2021

johny-b Jul 4, 2022 •

edited

Loading

stranger80 Aug 30, 2022

shadeofblue Jul 6, 2022

shadeofblue Jul 6, 2022

stranger80 Jul 18, 2022 •

edited

Loading

johny-b Aug 24, 2022 •

edited

Loading

stranger80 Aug 29, 2022

johny-b Aug 30, 2022

stranger80 Sep 1, 2022

johny-b Sep 2, 2022 •

edited

Loading

johny-b Sep 6, 2022 •

edited

Loading

nieznanysprawiciel Aug 12, 2022

stranger80 Aug 29, 2022

stranger80 commented Jan 12, 2023

nieznanysprawiciel Feb 8, 2023

nieznanysprawiciel Feb 8, 2023

nieznanysprawiciel Feb 8, 2023

nieznanysprawiciel commented Feb 8, 2023

-- This scenario is only possible with payment schemes which assume upfront payment or allow long intervals between payments or with self-sustained payment
+- This scenario is only possible with payment schemes which:
+* either assume upfront payment,
+* or allow long intervals between payments,
+* or are self-sustained and not depending on the presence of the daemon.

		- Requestor daemon remains online until Agreement is signed and Activity started
		- Requestor daemon transfers grants control rights to another node/identity, which remains online and exercises control over the Activity

[GAP-17] Offline requestor model #40

[GAP-17] Offline requestor model #40

Conversation

stranger80 commented Dec 26, 2021

johny-b Jul 4, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

stranger80 Jul 18, 2022 • edited Loading

Choose a reason for hiding this comment

johny-b Aug 24, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

johny-b Sep 2, 2022 • edited Loading

Choose a reason for hiding this comment

johny-b Sep 6, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

stranger80 commented Jan 12, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nieznanysprawiciel commented Feb 8, 2023

johny-b Jul 4, 2022 •

edited

Loading

stranger80 Jul 18, 2022 •

edited

Loading

johny-b Aug 24, 2022 •

edited

Loading

johny-b Sep 2, 2022 •

edited

Loading

johny-b Sep 6, 2022 •

edited

Loading