Brainstorming ideas for Flow

[smol-ninja]

I have been brainstorming some ideas by myself to implement into Flow. An open-ended streaming protocol opens up new use cases such as payroll which requires a different design than what we have in v2 and Airstreams.

I'd love to have comments from @sablier-labs/everybody on these.

Allowing anyone to initiate withdrawal on behalf of recipients

Motivation

• Recipients will have more flexibility to choose withdrawal addresses. The address could belong to an exchange, a Safe or any crypto wallet that is not integrated into the interface.
• Remove the need for all recipients to interact with the Sablier.
• A recipient can initiate withdrawals through a hot wallet while using a hardware wallet as a withdrawal address.

Create multiple streams

Motivation

• A new user/corporation migrating to Sablier might wish to create multiple streams at once.

Question: Should it be implemented into core contracts or periphery contracts? If yes, should I move depositMultiple to the periphery as well?

Broke fees

This feature is similar to v2-core where third-party entities that interact on behalf of users can charge service fees.

Withdraw from multiple streams

Motivation

• Allowing recipients to withdraw from multiple streams will save gas.
• Stream sender or anybody can initiate withdrawals to stream recipients for multiple streams in one transaction.
• Users can show interest in Sablier UI to allow Sablier to initiate withdrawals on behalf of users. This can lead to improved user experience.

Allowing anyone to deposit into any stream

deposit allows anyone to deposit to a stream. It could be a useful feature for corporations where the stream is managed by one address while deposits come from different addresses (finance team, etc).

One disadvantage of this feature is if someone accidentally deposits into a stream (for ex. fat finger or entered an incorrect stream ID), those funds can only be withdrawn by the stream creator.

Since this offers flexibilities for users, we can consider alternating approaches:

1. The sender can whitelist addresses allowed to deposit into the stream.
2. We can track depositor addresses along with the deposit. In the current model, a stream ID is specified during the deposit. If $\text{depositAmount} \leq \text{refundableAmount} $, the depositor can claim back his deposit. So if someone accidentally deposits to the wrong stream, they can initiate withdrawal as soon as they realize it.

The sender deposits into a pool and then allocates to streams

Motivation

• Currently, all streams created by a sender are mutually exclusive. This could lead to poor user experience when managing multiple streams as each stream requires managing its deposit. This is also gas expensive.
• I propose a design where the sender can make a single deposit into a pool shared by all the streams created by him. (Inspired by Blur Pools). In Web2, this is similar to using the same credit card for multiple recurring payments.
• Only the sender can get a refund from the pool.

Anybody can deposit into a pool and then allocate to streams

Similarly, anybody can deposit into a pool shared by all the whitelisted streams.

[andreivladbrg]

Thanks for opening this discussion

Allowing anyone to initiate withdrawal on behalf of recipients

this is also what we are discussing in the v2-core sablier-labs/v2-core#731

if we manage to implement this idea there, it would totally make sense to also implement this here.

Should it be implemented into core contracts or periphery contracts

periphery would be more appropriate, as this logic is not crucial to make things work here — it is only a feature on top.

should I move depositMultiple to the periphery as well?

i think it would work totally fine, as long as we keep the deposit function callable by anyone.

This feature is similar to v2-core where third-party entities that interact on behalf of users can charge service fees.

yes, this feature would be important to implement here as well

Withdraw from multiple streams

useful feature to have it here too

Allowing anyone to deposit into any stream ... (for ex. fat finger or entered an incorrect stream ID)

this could be a concern, but I guess it is a very common risk in the crypto space, similar to metamask transfers, due to the nature of blockchain technology

i still believe that leaving deposit public is the right decision. what we could do in the UI (to prevent unwanted scenarios) is to add multiple warnings when trying to deposit into a stream that is not controlled by you

The sender can whitelist addresses allowed to deposit into the stream.
We can track depositor addresses along with the deposit.

tbh, i don't think this added complexity would be worth it, especially the second point; adding one more address in the stream entity would add one more slot (i hope i didn't misunderstand your proposal).

Currently, all streams created by a sender are mutually exclusive.

yes, this is correct.

The sender deposits into a pool and then allocates to streams ... This is also gas expensive

would it be different from depositMultiple, except for the gas cost being cheaper due to only one ERC20 transfer? would there be a change in the flow?

one more idea for the periphery: createMultipleAndDepositMultiple

I propose a design where the sender can make a single deposit into a pool shared by all the streams created by him

this design is similar to how llamapay works, can i kindly ask you to read my comment from here?

https://github.com/sablier-labs/private-discussions/discussions/6#discussioncomment-7304440

i think we should have a separate discussion for this idea, as it changes architecture design, planning to open one

one very important aspect: i remember Razvan telling me that having a super different API compared to v2-core would be very complicated for the application/UI to handle

[razgraf]

would be very complicated

It wouldn't be veeeeeery-very 😅 but it would:

1. definitely make our lives easier in supporting both within the same app (and maybe subgraph - but this remains to be seen)
2. promote consistency between Sablier's products, which in turn makes the DX more intuitive

[andreivladbrg]

supporting both within the same app

having it in the same app is the goal, too many apps to chose from would cause confusion for the end user, we must find a way to abstract it

promote consistency between Sablier's products, which in turn makes the DX more intuitive

yep, this point is super important imo

[smol-ninja]

@andreivladbrg

I still believe that leaving deposit public is the right decision.

Now, I agree with this as well. I think this offers more flexibility to users and should remain public in the core contracts.

would it be different from depositMultiple, except for the gas cost being cheaper due to only one ERC20 transfer? would there be a change in the flow?

Yes, quite a different design.

Let's say a user manages 2 open-ended streams with different rps. If one stream runs out of funds, he will have to make a deposit to that stream. In the idea that I proposed, both these streams will share a common pool so as long as there is money in the pool, none of these streams will accumulate debt. Reading your comment from https://github.com/sablier-labs/private-discussions/discussions/6#discussioncomment-7304440, I agree that it could be a bad UX for recipients but I don't agree that this would mean one recipient could potentially "steal" the other recipients' funds.

Even though this design does not offer additional benefits for users who have fewer streams, it could be very useful for someone managing a large number of streams (like companies).

The question that we should ask is "who are our users". Are they recipients or are they creators? Whose experience should we prioritise depends on that answer. I am opening a separate discussion for this as you mentioned this would require architecture design: #13

Also started these issues and assigned them to me: #12 #11 https://github.com/sablier-labs/v2-open-ended/issues/10 and will work on them over the next few days.

[andreivladbrg]

As we talked on the call @smol-ninja

Allowing anyone to initiate withdrawal on behalf of recipients

created an issue: #30

Create multiple streams

will be on periphery

Broke fees

ongoing PR, that needs to be reviewed and merged: #14

Withdraw from multiple streams

created an issue: #31

The sender deposits into a pool and then allocates to stream

and

Anybody can deposit into a pool and then allocate to streams

we will use only depositMultiple for now