Context:
With that in mind, we tried to address the delay you mentioned specifically in
this version of the spec. The <link> load event should fire as soon as a valid
payment pointer has loaded (which is determined when JSON parsing the response,
rather than waiting for an Interledger connection), and we expect people to
unlock any extra features or content at this stage in good faith, without
waiting for the first "monetized" event (which is where the delay comes
from).
link#load is/was intended to be used to unlock content
Where this model may break down
Automatic payment is rejected due to disabling
You don't emit the load event
State is not 'interactive' (see reference 2 re 'states')
'monetization' event may still come from user initiated tip, even
though this breaks the state model, where it says no payments will
come when the link is in the idle state
(I have seen examples of using only load event to unlock exclusive content)
You do emit the load event, to keep state coherent
In this case automatic payments are disabled
This means that the load event is not as useful for guessing whether
payments will come, and "optimistically" show content.
Originally from:
1 / 2
Context:
link#load is/was intended to be used to unlock content
Where this model may break down
Automatic payment is rejected due to disabling
You don't emit the load event
State is not 'interactive' (see reference 2 re 'states')
'monetization' event may still come from user initiated tip, even
though this breaks the state model, where it says no payments will
come when the link is in the idle state
(I have seen examples of using only load event to unlock exclusive content)
You do emit the load event, to keep state coherent
In this case automatic payments are disabled
This means that the load event is not as useful for guessing whether
payments will come, and "optimistically" show content.
Originally from:
1 / 2