Front-facing statuses for Flow

[razgraf]

During the first demo of the Flow designs we've uncovered a mismatch between contract-level statuses and front-facing statuses for Flow streams. This comes as a necessity to show clearer or easier-to-understand statuses to user. As a possibly incomplete example, the following may very well be defined as "ended":

• paused-insolvent-but-paused-with-reason
• paused-solvent

Default view	Priority view

@PaulRBerg suggested we work on aligning these statuses before we go to production.

The reasoning behind our current contract-level statuses can be found in the flow diagrams here.

Opening this as a request for ideas and feedback.

@sablier-labs/everybody

[andreivladbrg]

I don’t have a good recommendation yet on how to change the contract statuses (or the app statuses), but I want to mention two things:

• The "Ended" status cannot exist at the contract level unless we implement "end time" bespoke logic.
  • Even if we use another word instead of "Ended", I think this status will be used in the app after pauseWithReason("forget stream") is called, i.e. these 2 scenarios: 1. no debt after pause, and 2. dust debt after pause. These two scenarios are different at the contract level.
• I like the "In Debt" status, but I believe it would be very confusing to have it at the contract level, especially given the latest renamings that @PaulRBerg has suggested.

It seems hard to find something to synchronize them.

[PaulRBerg]

Yeah it's definitely more problematic to rename stuff at the contract level. We should try to keep things simple in the contracts and make slight renamings in the UI.

[smol-ninja]

Having seen the current design, I anticipate that users might misunderstand an "Ended" status, even if we provide a description like "fulfilled, can be re-started" and a tooltip explaining its meaning. Many users might just see the word "Ended" and assume they cannot restart the stream, potentially leading to streams not being resumed when they could be. And a lot of support messages.

Have we seen similar behaviour from Lockup users where they missed small details and simply assume something from the big texts?

---

Now in order to keep the "Ended" status in the UI, I'd like to share an idea as below.

Lets only have the option to pause with reason in the UI. And implement a dropdown list with predefined reasons, alongside an additional custom field. We can start with guessing a set of reasons that users might have and refine them based on data. One option in the dropdown would be "End the Stream," which would categorize it under the "Ended" status in the UI. It can either be solvent or insolvent but the reason to categorize it as Ended would just be "End the Stream" option.

This would lead us to have three categories in UI:

Category	Debt / No Debt	Reason
Paused	Both	Anything except End the Stream
Streaming	Both	-
Ended	Both	End the Stream

And if we want to maintain an "In Debt" and "Streaming" categories, we can do it as follows:

Category	Paused / Streaming	Reason
In Debt	Both	Anything except End the Stream
On-going	Streaming without Debt	-
Ended	Paused	End the Stream

I think the second option is more complex than the first option. Alternatively, we can have both views and then track analytics to discover the popular one.

These are just ideas so feel free to criticise and provide feedback.

[PaulRBerg]

Great criticism on "Ended".

I will think about your suggestions some more and follow up with feedback.

Have we seen similar behaviour from Lockup users where they missed small details and simply assume something from the big texts?

Not sure off the top of my head, but we should expect this to happen due to natural human biases.

[razgraf]

Agree "Ended" is a bit misleading, especially in relation to the restart feature.

Have we seen similar behavior from Lockup users where they missed small details and simply assume something from the big texts?

We've seen people fail to read even the big texts and choose to go through the effort of searching for the chat box instead 😅

Now in order to keep the "Ended" status in the UI, I'd like to share an idea as below.

If we find something more fitting, we don't have to. I used "Ended" on whim as a final status (not focused on restart) to simply tell the user "hey, you're okay not actively keeping tabs on these streams, focus on the ones above".

implement a dropdown list with predefined reasons

I like this! Let's just figure out what those reasons would be, as for now we've only discussed one, right? Releasing debt, but from the sender's perspective.

Regarding your first breakdown in categories, as I said, I wanted to somehow highlight streams with debt as being high priority. So I'd love to keep this in mind, if there are not arguments against this "debt-first" ordering.

[PaulRBerg]

One of the unanswered underlying questions here is this: in the Priority view, should the UI follow the structure hierarchy of the Status enum, i.e. Streaming/Paused first and Solvent/Insolvent second, or the other way around?

So far, it looks like @razgraf went with the other way around, i.e. structuring the streams by Solvency first. This runs against the Solidity version, but I see why users might be more interested in this categorization.

Furthermore, my proposal to remove pauseWithReason has implications for this discussion.

Here's my synthesized proposal:

• Reverse the structure in the Status struct, i.e. rename PAUSED_INSOLVENT to INSOLVENT_PAUSED, etc., to synchronize the UI and the contracts
• Introduce a new status VOIDED in the Solidity contract
  • A voided stream can be restarted
• Rename "Ended" to "Voided" in the UI (as per @smol-ninja's excellent criticism above)
• Keep "In Debt" terminology but rename "Ongoing" to "Funded" in the UI
  • "In Debt" is mapped to "INSOLVENT"
  • "Funded" is mapped to "SOLVENT"

WDYT @sablier-labs/engineers?

Alternatively, we could stick with Solvent/ Insolvent in the UI, too. WDYT about that, @razgraf?

[smol-ninja]

They are interchangeable. A voided stream doesn't have a streaming/ paused dichotomy

Lol. You are right. It doesn't make a difference. The point about former being organized is not relevant anymore.

I am in favour of making the proposed changes then.

[andreivladbrg]

A voided stream = a paused stream with zero debt.

which is exactly the same thing with PAUSED_SOLVENT :))

It's not quite the same thing as a duplicate.

i am sorry, but it is exactly a duplication, how would you change the statusOf function implementation?
consider the scenario when a stream is paused and then: 1. sender refunds all tokens 2. recipient withdraws everything - how would we differentiate between them? see again my point about binary

i am on the same line with @smol-ninja, if we want to introduce the VOID status, we should modify the logic to disallow restart on voided streams

this is something we should discuss separately, not in this thread

well, it is relevant to discuss this here as long you propose to add a new status called VOID

[andreivladbrg]

re PI to IP i am ok with the change, may be i am just used to the current version so this is why i say is easier

[PaulRBerg]

which is exactly the same thing with PAUSED_SOLVENT :))

This is set-theoretically incorrect.

it is exactly a duplication

No.

A duplicate is something that is identical. If A has all the properties as B has and vice-versa, B is a duplicate of A. Whereas if D has only some properties of C, D is said to be contained with C, but not duplicates.

VOIDED is a special case of SOLVENT_PAUSED. It's not a duplicate.

how would you change the statusOf function implementation?

We would introduce a new boolean isVoided in the Stream entity.

how would we differentiate between them?

Good point.

We would return SOLVENT_PAUSED in this case.

we should modify the logic to disallow restart on voided streams

Makes sense — let's do this.

This is how VOIDED would be different from SOLVENT_PAUSED.

well, it is relevant to discuss this here as long you propose to add a new status called

True.

[smol-ninja]

Great. Seems like we all have an agreement now. I am happy we decided to disallow restarting a voided stream.

[andreivladbrg]

Closing in favor of #218

[razgraf]

Related: https://github.com/sablier-labs/v2-interfaces/discussions/1054