Include "recipient" in "WithdrawFromLockupStream" event

[PaulRBerg]

PRB: The event to look for is WithdrawFromLockupStream

User: now i cant just listgen for the withdrawfromlockupstream because i dont know all the streams that are created. So i think i have to listen to something that registers a stream id so im not trying to cancel streams from other distirbutions.

PRB: Paul R. Berg | Sablier, [Dec 18, 2023 at 11:34:40 PM]:
Can't you just check if the to address emitted in the event matches your list of known recipient addresses?

The to parameter is indexed so you can also retroactively filter events by that address

oooh wait, to can be a third-party address ..

User: I dont know, im trying to figure out your system to do what we need.

PRB: We're gathering 10/10 product feedback by talking to you, thanks very much. We will include the recipient in a future version of the protocol so that you can filter by the recipient

[razgraf]

Worth noting that:

• in case someone else withdraw (e.g. sender) the to address is locked to the stream's recipient
• in case the recipient withdraws, the user can just check who triggered the event using the from value usually attached to the payload of any event

So you should be able to get a hold of the stream's recipient even now.

[PaulRBerg]

There are two other cases in which it is not possible to know the recipient:

• If you approve an NFT operator
• Once Make withdraw function callable by any account #731 gets implemented in V2.2

[razgraf]

Fair point with the NFT operator, but for the second one: public withdrawals would still be towards a hardcoded to address. People can't withdraw from your stream to their own pocket (same rule as with v2.0 sender withdraw). Right?

[PaulRBerg]

People can't withdraw from your stream to their own pocket (same rule as with v2.0 sender withdraw). Right?

right

[PaulRBerg]

Closing as the withdraw event now includes to.