Previous Posts:
A note on terminology
Within the context of these posts, I’m calling a user application any application that uses SPA to provide a service. Here, such applications always face users (hence the name), but it is only a relative difference. The same application can be a user application and a non-user application (currently nameless), depending on if the user interacts with it directly or intdirectly (triggered by another app).
Pick A Number
To explain how user applications can interact with SPA applications to request storage, let’s define a simple (transparent only for now) pick-a-number application that records a picked number and allows anyone to update it. To update the number, the user consumes the old resource and creates a new one with the updated value.
| TF | Description |
|---|---|
| Init | Create a resource with value v_0, balance with an ephemeral resource |
| Update | Consume the old resource with a number v_n, create a new resource with number v_{n+1} |
Constraints[1]
| Ephemerality | TF | Constraints | |
|---|---|---|---|
| Create | Ephemeral | Not allowed | |
| Persistent | Init | Must be signed by the pick-a-number owner, value v_0, the balancing pick-a-number resource is ephemeral | |
| Update | The consumed resource is non-ephemeral | ||
| Consume | Ephemeral | There must be another non-ephemeral resource created with value v_0 | |
| Persistent | There must be another persistent resource created |
Additional constraints and notes:
- The label must contain a unique id (authorised by the app owner signing the init), so different pick-a-number instances have different labels and we only check resources with the same labels[2]
- If the owner allows non-unique id, the application changes. In reality we probably can have a list of existing ids as a resource/non-linear data that allows checking against to ensure uniqueness, but we don’t care about it now
Modify Pick-A-Number to store the number
In the table below I added the bold constraints that bind user application logic to the SPA logic, therefore triggering storage writes and deletes.
Constraints
| Ephemerality | TF | Constraints | |
|---|---|---|---|
| Create | Ephemeral | Not allowed | |
| Persistent | Init | Must be signed by the pick-a-number owner, value v_0, the balancing pick-a-number resource is ephemeral. | |
| Update | The consumed resource is non-ephemeral | ||
| Both | There must be an SPA resource in the same action that contains the valid (from the application perspective[3]) blob | ||
| Consume | Ephemeral | There must be another persistent resource created with value v_0 | |
| Persistent | There must be another persistent resource created. SPA delete request (non-ephemeral consumed resource with the same blob) must be present[4] |
The diagram below illustrates the proposed design.
Pick A Number feat. RSM Storage (SPA v2)
In the second version of SPA the constraints are slightly different. I strike through the constraints that are removed for SPA v2 and highlight the replacement constraints. If we don’t fix the init value v_0, then the logics for consumed ephemeral and persistent resources become exactly the same.
| Ephemerality | TF | Constraints | |
|---|---|---|---|
| Create | Ephemeral | Not allowed | |
| Persistent | Init | Must be signed by the pick-a-number owner, value v_0, the balancing pick-a-number resource is ephemeral. | |
| Update | The consumed resource is non-ephemeral | ||
| Both | There must be |
||
| Consume | Ephemeral | There must be another non-ephemeral resource created with value v_0 | |
| Persistent | There must be another persistent resource created. |
User application constraints mimic the mechanics of the SPA resource constraints basically defining constraints for both creation and deletion of the blobupon creation of the user app resource. That seemingly helps to unify the application constraints a little bit and have less branches
Next parts:
The table constraints redundant constraints and might be missing some required for security, but this is not the focus of the post, so I’m ignoring it ↩︎
Probably should write some kind of best practice application spec that includes these things so we can just stop mentioning these details every time, but for now I still feel responsible to write it explicitly ↩︎
There are two types of blob validity verified now: SPA verify that the blob is valid from the SPA perspective, the applications that use SPA verify that the blob is valid from their perspective. For example, SPA only allows to store even numbers, and a user application only allow outputting numbers divisible by 256. ↩︎ ↩︎
In this user application, we explicitly trigger deletion on the number update. We don’t have to if the deletion criterion is specified another way, but for SPA v1, the deletion of the blob must be explicitly triggered, just not necessarily as a part of the user application logic. ↩︎ ↩︎