Should we allow the sender to withdraw for the recipient?

[razgraf]

In light of #110 , #155 etc. I'm not sure I remember why we landed on giving the sender permission to withdraw for the recipient?

It would allow them to run a "relayer" themselves for created streams sure. But if we implement #155 this relaying becomes a business model for the "Sablier Keepers". Also, in need of extra customization, one could just implement a recipient contract/proxy that has a permission list for everything from transfer to withdraw.

The downside with maintaining this sender power is that we create yet another edge-case for integrators to take into account.

Note: I could not find this exact topic documented in our discussions, so the thread can serve as historical reference for our decision.

[PaulRBerg]

We have never reached an agreement about this; the ability of the sender to withdraw has always been an assumption that we have made in the Sablier smart contracts. This is how V1 works.

Given the dozen or so cases when we have been contacted by users who had accidentally created a stream towards a recipient that cannot claim (e.g. a CEX address), I am staunchly in favor of keeping the withdrawal permissions as are they are by continuing to let the sender be able to withdraw.

But if we implement #155 this relaying becomes a business model for the "Sablier Keepers"

Firstly, we haven't agreed upon #155.

Secondly, even if we agree, we're talking about two very different permission schemes. The sender is the creator of the stream, and so the payment of the stream's money is his business. Not ours. We would only intervene with the Rescuers when necessary and when explicitly requested by users in special circumstances. But the sender should be able to just call the withdraw function without ever getting in touch with us.

one could just implement a recipient contract/proxy

As discussed elsewhere, this is completely unfeasible because you just cannot coordinate with both the sender and the recipient to do this. It's just not something we can do. The creation of a stream is an asynchronous operation - the recipient need not be online when the stream is created.

we create yet another edge-case for integrators to take into account.

I shared my thoughts about this in #150.

[razgraf]

because you just cannot coordinate with both the sender and the recipient

You do not need them to coordinate. The stream can be transferred after-creation, by the recipient to a smart-contract.

[PaulRBerg]

Fine. But that would be an amazingly "roundabout" way to offer a minor feature; the development and maintenance cost would not be worth it.

And that would still not cater for the problem of how to recover the funds when sent to a recipient that cannot claim.

[PaulRBerg]

@razgraf can we consider this discussion closed and lock it?

[razgraf]

Sure, I locked this, but I'm still unsure the security/complexity outweighs the advantages of allowing this sender trigger.

[PaulRBerg]

I'm not sure I follow your point - allowing the sender to withdraw actually increases the security of the user funds because the sender can withdraw on behalf of the user in case something bad happens. I had explained this in my first post.

And then, about complexity - there's hardly any complex logic added for this. See the isAuthorizedForStream function:

if (msg.sender != getSender(streamId) ...