Why are we not emitting the "sender" in the "Cancel" event?

[PaulRBerg]

Why are not emitting the "sender" in the "Cancel" event?

[PaulRBerg]

Cc @andreivladbrg would love your thoughts here.

[razgraf]

Isn't it redundant? We would already have access to msg.sender to figure out who called cancel on the stream (recipient or sender).

[PaulRBerg]

As you say, the caller can be either the sender or the recipient.

You can't know who the sender is without emitting in the event.

[razgraf]

If you're looking to optimize gas on emitted variables, we do have ways of identifying this. The sender is generally immutable and we would get it from the Create Stream event. By comparing these details (cancel event + data from the create event) we should be able to arrive at a conclusion.

If gas isn't a consideration here, including it would speed up this process of course.

[andreivladbrg]

If gas isn't a consideration here, including it would speed up this process of course.

Should be a gas increase, probably few hundreds, which wouldn't be a problem.

If there is utility in emitting the sender we should do it.

[PaulRBerg]

We have to take into consideration the DX for integration partners - it's one thing if we have to jump through hoops to obtain the sender for a cancellation, it's quite another thing if a third-party developer has to do it.

Based on this rationale I have opened a PR to emit the sender in the Cancel event:

#190

[PaulRBerg]

Locking, as this has been implemented in #190.