Open-ended question: should we rename "sender" to something else?

[PaulRBerg]

The problem with the sender argument is that it can be easily confused with the Ethereum property msg.sender.

In #73, I have changed the NatSpec description of the sender argument to the following:

/// @param sender The address from which to stream the tokens, which will have the ability to cancel the stream.
/// It doesn't have to be the same as msg.sender.

Which clarifies what is the goal of this argument, but I still find it confusing. While writing the tests for the create function, I had to use very specific names in the tests variables so I can differentiate between sender and msg.sender.

Does anyone have an idea for a better name?

[andreivladbrg]

Considering that the create function will mint a NFT when a stream is created, I suggest minter.

[PaulRBerg]

Interesting idea, but this is not about msg.sender. It's about sender, i.e. the account which has the ability to cancel the stream later on. The sender should definitely not be the minter.

Furthermore, I think I would prefer to steer away from the NFT minting terminology.

[razgraf]

Ideas:

1. payer (would work with payee but sounds good together with recipient too)
2. agent
3. investor

[PaulRBerg]

I like #1 and #2, but investor doesn't work, because it's msg.sender who funds the stream.

[PaulRBerg]

Due to a lack of any better alternatives, I suggest we stick with sender. There's also a bit of path dependency with this terminology due to V1 - it might confuse a lot of users if we started referring to the V1 sender in a different way in V2.

[PaulRBerg]

Going to lock this since we have reached a soft agreement to stick with sender (mainly due to a lack of any better alternative).

[andreivladbrg]

Randomly came to mind the manager name, what do you think?

[PaulRBerg]

Love it! Tagging @razgraf.

[PaulRBerg]

@razgraf I think the question for you here is whether you would be happy to display this property as "Manager" in the UI, as well?

[razgraf]

I really like manager as a name for the variable. But outside of the technical aspect, I'm not sure the user really gets as much intel from "manager" versus what he'd get from "sender".

The word "sender" holds much more meaning in the context of transferring value. It is he who keeps the money flowing.
Meanwhile, "manager" is a great choice but as a job or assignment for the sender. They get to send the money as well as manage the stream over time.

I'd be happy to refactor our code (subgraph and interfaces) to mirror this, but I still think the UI should display the label as "sender".

[PaulRBerg]

I think that there is a bit of inexplicit knowledge that would be worth clarifying.

In the Sablier UI, the funder is the same as the sender, which is why it makes sense to keep the "sender" copy. However, whenever the funder is not the same as the sender, the terminology breaks apart.

It is this unbundling of the funder from the sender which was the reason why I opened this discussion in the first place - in that case, it makes more sense to refer to the sender as something else, and @andreivladbrg's suggestion of manager is the best suggestion so far.

Let's ruminate more on this topic before making a decision. I am, in principle, open to the idea of keeping the manager variable in the Solidity code, while continuing to refer to both the funder and the manager as the "sender" in the Sablier UI. Ultimately, our goal with Sablier V2 is for it to become a core protocol that powers multiple user interfaces - we won't be able to control how user accounts are labeled in third-party UIs.

[PaulRBerg]

Locking since after multiple discussions on this topic (including face-to-face conversations) we have never found a better alternative to sender. There is no ideal word that would work in all use cases.

[IaroslavMazur]

Should we call the Stream senders "streamers"?
Personally, I like the sound of that, and how it underlines the fundamental role that the senders play in the Stream economy.

Related: the Stream recipients could, therefore, be referred to as "consumers". However, this sounds less cool than "streamers". 🙃

[PaulRBerg]

With the benefit of hindsight, it's good that we didn't go with 'streamers' (as we've soft-pivoted toward token distribution).

[PaulRBerg]

Closing due to inactivity.

"sender" is good enough and renaming it at this point would introduce too many breaking changes.