Proposal: simplify asynchronous submission flow

[achamayou]

I think we can simplify the asynchronous submission flow substantially by:

1. Using appropriate HTTP return codes
2. Using Location

As far as I can tell, 303 is intended for that purpose.

Implementations that can allocate a permanent Location early can avoid dealing with temporary OperationID and the potential race between expiry and the client coming back in time, and implementations that do not can still use a 308 once they have allocated a final Location.

[SteveLasker]

Tagging @robinbryce for 👀

[achamayou]

Capturing so I don't forget:

• add detail about temporary vs permanent location and use of 308
• add reminder that temporary locations may not be kept forever by the implementation

[robinbryce]

To be clear, the location is not required to be the permanent or final uri for the registration result ? In other words, it acts just like operaiton id did before, but we are using more of HTTP to convey the interaction.

When the GET on the location returns successfully, the response location is the final registration result ?

Is 302 Found the intented response code for that GET ? That seems to imply the new location is also temporary ?

[robinbryce]

So this simplification seems to remove the ability to specify a "check status" api ? How does the 303/302 model convey async registration problems to the client ?

[robinbryce]

Not sure. It's not clear to me we retain the ability to convey async registration issues clearly to the client. And async registration is not a "corner case" in my view. IMO: the more people want to do with registratio policies the more likely the async registration will be the norm

That said, I do like the effort to make better use of existing aspects of the HTTP spec

[SteveLasker]

Discussion to remove the temporary Operation ID flows, returning a Permanent ID.

[robinbryce]

Discussion to remove the temporary Operation ID flows, returning a Permanent ID.

I belive this forces the transparency service to pre commit to an identifier before the entry is added to the imutable ledger. I think that is un helpful.

High throughput ledgers that offer "at least once" semantics will have duplicates on content that are unique based on there commitment to the VDS.

Either the ledger works counter factualy (the identity can be computed from the content) or it must store the look up permanently. Both can be done, but I don't understand why OperationID is so problematic.

[achamayou]

@robinbryce I need to/have agreed to rewrite this more clearly, I will try to do that tomorrow. The goal was not to force anything, but to allow implementations that could provide the identifier synchronously to do so.

I think this can be done without the identifier being content-derived, it can be a tentative position in the ledger that is reserved, and to which the VDS is guaranteed to be bound if the registration succeeds. If the commit fails, the error can still be returned all the same.

In terms of location, I think something like:

1. POST ... -> 303 Location: Somewhere Temporary
2. GET Somewhere Temporary -> 302 Location: Somewhere Temporary
3. GET Somewhere Temporary -> 308 Location: Somewhere Permanent
4. GET Somewhere Permanent -> 200 Content

It seemed like we could skip 2. in cases where the eventual location is decided early, but it sounds like maybe not?

[robinbryce]

@robinbryce I need to/have agreed to rewrite this more clearly, I will try to do that tomorrow. The goal was not to force anything, but to allow implementations that could provide the identifier synchronously to do so.

Oh, that sounds very reasonable.

I think this can be done without the identifier being content-derived, it can be a tentative position in the ledger that is reserved, and to which the VDS is guaranteed to be bound if the registration succeeds. If the commit fails, the error can still be returned all the same.

Some ledgers may be able to work that way, ours does not. At the time we accept the request we have no way of knowing exactly which position it will get in the ledger. A reservation would require significant limits on throughput I think.

But if this is a requirement on synchronous registration that is fine. We could implement a synchronous path that returned the actual ledger id in the order of < 1 second - heavily dependeing on registration check requirements. It's just for high throughput, we definitely want the option of "comming back later" to get the result. And we most certainly want async registration to continue to be possible

In terms of location, I think something like:

1. `POST ...` -> `303` `Location: Somewhere Temporary`

2. `GET Somewhere Temporary` -> `302` `Location: Somewhere Temporary`

3. `GET Somewhere Temporary` -> `308` `Location: Somewhere Permanent`

4. `GET Somewhere Permanent` -> `200` `Content`

It seemed like we could skip 2. in cases where the eventual location is decided early, but it sounds like maybe not?

Not sure, but I do like the use of 303, 302 and 308 for sure, even if all of the requests are necessary

[robinbryce]

@robinbryce I need to/have agreed to rewrite this more clearly, I will try to do that tomorrow. The goal was not to force anything, but to allow implementations that could provide the identifier synchronously to do so.

Oh, that sounds very reasonable.

I think this can be done without the identifier being content-derived, it can be a tentative position in the ledger that is reserved, and to which the VDS is guaranteed to be bound if the registration succeeds. If the commit fails, the error can still be returned all the same.

Some ledgers may be able to work that way, ours does not. At the time we accept the request we have no way of knowing exactly which position it will get in the ledger. A reservation would require significant limits on throughput I think.

But if this is a requirement on synchronous registration that is fine. We could implement a synchronous path that returned the actual ledger id in the order of < 1 second - heavily dependeing on registration check requirements. It's just for high throughput, we definitely want the option of "comming back later" to get the result. And we most certainly want async registration to continue to be possible

In terms of location, I think something like:

1. `POST ...` -> `303` `Location: Somewhere Temporary`

2. `GET Somewhere Temporary` -> `302` `Location: Somewhere Temporary`

3. `GET Somewhere Temporary` -> `308` `Location: Somewhere Permanent`

4. `GET Somewhere Permanent` -> `200` `Content`

It seemed like we could skip 2. in cases where the eventual location is decided early, but it sounds like maybe not?

Not sure, but I do like the use of 303, 302 and 308 for sure, even if all of the requests are necessary

Maybe The POST can respond imediately with 308//301 in the case where the permanent location is known ?

To be super super clear, I support the use of a location that is intially temporary and is ultimately permanent as indicated by the above HTTP response codes. And of course for ledgers that can go straight to permanent this "just works"