Should we include the caller in the "Withdraw" event arguments?

[PaulRBerg]

A follow-up to #142.

@andreivladbrg, should we also include the caller among the Withdraw event's arguments? This is so that we can differentiate withdrawals made by the recipient vs withdrawals made by approved operators.

[andreivladbrg]

Yes, I think it would be a good idea.

Also I would say to change the recipient argument with the caller in the Cancel event.
https://github.com/sablierhq/v2-core/blob/79485a216c9b058cd25174c33ab6e983deffa63a/src/interfaces/ISablierV2.sol#L65

[PaulRBerg]

Thanks, but you didn't explain why it would be a good idea?

Re Cancel event - shouldn't that include both the recipient and the caller? Who, by the way, must be the sender, so why not call him the sender?

[andreivladbrg]

Thanks, but you didn't explain why it would be a good idea?

I think it's a good idea because of the reason you just mentioned, i.e:

This is so that we can differentiate withdrawals made by the recipient vs withdrawals made by approved operators.

The cancel function can be called by any approved operator like the withdraw one.

We don't need to display the recipient because we already know that withdrawAmount goes to the recipient and the returnAmount goes to the sender.

[PaulRBerg]

Oooh, I see, now with the implementation of ERC-721 there can be an operator calling cancel on behalf of the recipient. Cool. Thanks for explaining.

I would advise to keep the recipient in the event. You say that we know that that is a recipient, but we have to think from the perspective of the external viewer of the event. How can they know who is the recipient after they see this event? A cancelation deletes the stream, so the only way they could find out is by running an archive node, which is expensive AF.

[PaulRBerg]

On second thoughts, I don't think that adding the caller in the event arguments (either Withdraw or Cancel, or both) would be useful. Doing that wouldn't add any valuable information that can't already be extracted from the msg object.