feat: add exit to empty seat

[katelynsills]

See #1582 for more discussion. I'm curious if we could implement the give portion too, using a reallocation.

I still need to add tests of the different userSeat methods to ensure the empty seat operates like a real seat in all ways.

Closes #1582

[Chris-Hibbert]

This looks like it continues to conserve all our safety properties, but I don't understand its value.

Under what circumstances would a contract want to create an internal seat for which it needed an exit clause?

[katelynsills]

This looks like it continues to conserve all our safety properties, but I don't understand its value.

Under what circumstances would a contract want to create an internal seat for which it needed an exit clause?

Many circumstances - for instance, if the seat should exit after a particular deadline. Or, if the userSeat facet will be handed to someone else such that the ability to exit is separated from the contract's ability to exit.

My point, though, is that the burden of proof has been in the wrong direction. We shouldn't be asking why seats should all act the same. We should be asking why some seats should have different functionality. I would like the empty seats to have the same functionality as other seats.

[erights]

I like the switching burden of proof argument. But it seems this PR is only a step along the way. The result is far from like a seat in all ways.

A seat whose want alone must be satisfied to preserve offer safety would take it farther from being just like a normal seat. I also don't see how it is a workable plan. The seat would start with an allocation that VIOLATES its offer safety. If the contract crashes in this state, offer safety would be violated. If the seat is exited in this state, what happens? Preventing the exit violates payout liveness.

So putting aside the burden-of-proof argument, it would help to actually have and try a concrete use case. The issues under even an artificial but concrete use case may be much easier to evaluate than under imagined use.

Was there a particular use case you had in mind that motivated this in the first place?

[katelynsills]

I like the switching burden of proof argument. But it seems this PR is only a step along the way. The result is far from like a seat in all ways.

I think I disagree with this. The only way it is different is the offer cannot give anything. That's only one difference. An important difference, but it is the only one.

I view this PR as a step towards being able to give from the contract side. Potential solutions include either 1) being able to synchronously process payments from the contract to cover give (hard) or 2) being able to synchronously use reallocations to cover give (seems easier). Either way, this PR shows that our previous assumption that you cannot exit an empty seat was unnecessary.

A seat whose want alone must be satisfied to preserve offer safety would take it farther from being just like a normal seat. I also don't see how it is a workable plan. The seat would start with an allocation that VIOLATES its offer safety. If the contract crashes in this state, offer safety would be violated. If the seat is exited in this state, what happens? Preventing the exit violates payout liveness.

Yup, that makes sense.

So putting aside the burden-of-proof argument, it would help to actually have and try a concrete use case. The issues under even an artificial but concrete use case may be much easier to evaluate than under imagined use.
Was there a particular use case you had in mind that motivated this in the first place?

Yes, 1) the ability to exit an empty seat automatically afterDeadline and 2) to hand the userSeat to another entity such that they (who do not have access to the zcf seat) can exit on demand.

I think I will try to change this PR to allow the contract code to pass only the exit rule, so that the want and give are still empty under the hood. I want to push this PR forward because I think it does two important things: 1) allows all Seats to have uniform exitObjs based on the exit rule, and 2) shows how the proposal can be updated from the ZCF side, preparing the way in the future for us handling give correctly.

[erights]

shows how the proposal can be updated from the ZCF side, preparing the way in the future for us handling give correctly.

By "updated" do you mean modified after creation? I don't think so, and your current code only provides proposal ingredients when the seat is constructed. This makes sense to me.

With that clarified, I look forward to the next version. Thanks.

[katelynsills]

By "updated" do you mean modified after creation? I don't think so, and your current code only provides proposal ingredients when the seat is constructed. This makes sense to me.

No, sorry, updated is the wrong word. I mean created.

[erights]

LGTM

[erights]

Stale want:. Please remove.

[katelynsills]

Good point

[erights]

Didn't you already flatten this out in a previous PR? In any case, the flattening is good.

[katelynsills]

Whoops, I've got some rebasing to do, sorry.