Should we allow multiple streams between two users?

[PaulRBerg]

Context

As evidenced by this feature request, there are use cases for allowing multiple streams between the same two addresses, such as:

• Business selling multiple services to the same user (e.g., Google selling Gmail Workspace, Drive, and YouTube)
• User buying multiple instances of the same service (e.g., Gmail for multiple domains)

The catch is that this feature runs counter to the design proposed in our V3 Slides, which contemplated a maximum of 1 stream (i.e., one edge) between 2 user addresses.

Implementation

Two ideas:

1. Actually allow multiple edges at the VM level
2. Application layer that deconstructs a single stream into individual streams based on historical user interactions

Analysis

The 1st approach is unrealizable because we already have concerns about unbounded computational growth. Expanding the scope of the graph to allow multiple edges would add fuel to the fire.

The only realistic solution is to implement it off-chain using an application (call it SabSub) that would work something like this:

1. On Jan 2, using the SabSub UI, Alice starts $5/ month stream to Google for Gmail (domain foo.com)
2. On Jan 6, Alice starts $10/month stream to Google for Drive
   • The UI would store the individual streams into an off-chain web2 database (e.g., Postgres)
   • In the UI, Alice would see 2 outgoing streams and Google 2 incoming streams
   • On the blockchain, there would be only 1 stream moving $15/ month from Alice to Google
3. On Feb 12, Alice starts another $5/ month stream to Google for Gmail (domain bar.com)
   • In the UI, Alice sees 3 outgoing streams, and Google 3 incoming streams
   • On the blockchain, there would be only 1 stream moving $20/ month from Alice to Google

There are downsides, such as the risk that third-party apps unaware of SabSub would continue displaying just 1 stream between Alice and Google. This would create confusion if either Alice or Google interacted with these third-party apps.

But we might have to accept those downsides if we want to go to mainnet before we burn through our treasury :D

RFC

I don't consider this a high-priority feature. We can launch the chain without it and monitor demand along the way.

Cc @IaroslavMazur, @razgraf.

[IaroslavMazur]

I'm in favor of allowing multiple Streams between 2 addresses.

Primarily because this would be a better reflection of the value dynamics in the real world (and would, therefore, make the adoption of SabVM easier/more probable).

Here are some more real-world examples:

• an employee holding several positions with different compensations at a company;
• a new real estate owner (wink-wink @razgraf) buying multiple items of homeware in installments - and streaming the differently-priced items (potentially) over different time periods.

In practice, the multiple Streams between the same 2 users could be "simulated" via the MNTs (1 Stream per each token), with the total number of supported MNTs practically becoming the maximum total number of Streams a user can create towards some other user. However, this is a mere workaround, and is far from being user-friendly.

---

Application layer that deconstructs a single stream into individual streams based on historical user interactions

Personally, I don't think this would be a good idea. Both for the potential issues you've outlined in the OP, and because this would go against the general principle of abstraction/composition, as instead of having the simpler/basic objects (Streams) on the lower level (the VM) and the more complex/composite/abstract objects (Groups of Streams) - on the higher level (the application), we'd have the opposite.

What if we introduce an abstraction layer in the VM (let's call it a "Stream Group"), tracking all of the same-token Streams between 2 users - and summarizing the current stats of the underlying Streams into a single place? A Stream "index" (database-style) of sorts.

So, for example, if there are 2 Streams from A to B, streaming 2 and 3 token units per second respectively, the Stream Group would only have the information of 5 units per second - and would be updated whenever any of the underlying Streams are changed.

---

Related idea: let users include "notes" into their Streams, so that it's easier for them to distinguish between them? 🤔

[PaulRBerg]

Thanks for your feedback.

he multiple Streams between the same 2 users could be "simulated" via the MNTs (1 Stream per each token), with the total number of supported MNTs practically becoming the maximum total number of Streams a user can create towards some other user

This is an interesting idea, but, as you said, it wouldn't be scalable. There are only so many stablecoins, and requiring users to start multiple stablecoin streams just for differentiation purposes would be an awful UX.

---

go against the general principle of abstraction/composition

That is true, but we might have to violate that principle if we want a functioning mainnet.

As I've said in the OP, we run the risk of running into unbound computational growth.

What if we introduce an abstraction layer in the VM (let's call it a "Stream Group"), tracking all of the same-token Streams between 2 users - and summarizing the current stats of the underlying Streams into a single place?

We could, but I would assign this feature a very low priority until we get the base VM and chain up and running. Other assumptions have to be validated before we can venture into these higher-level features.

---

let users include "notes" into their Streams, so that it's easier for them to distinguish between them? 🤔

The chain should not accommodate such use cases. They should be done at the application level.

At any rate, the data field can be used for this.

[IaroslavMazur]

we might have to violate that principle if we want a functioning mainnet.

Tradeoffs are a possible necessity, of course.

A general approach we would like to follow, though, could be the following: implement the desired functionality in the most logical way possible first - and accept tradeoffs only if/when the risk of the unbounded computational growth has a significant chance of materializing.

In other words, functionality first, optimizations second.

---

We could, but I would assign this feature a very low priority until we get the base VM and chain up and running. Other assumptions have to be validated before we can venture into these higher-level features.

Absolutely.

---

The chain should not accommodate such use cases. They should be done at the application level.
At any rate, the data field can be used for this.

Makes sense, yeah.

[PaulRBerg]

implement the desired functionality in the most logical way possible first - and accept tradeoffs only if/when the risk of the unbounded computational growth has a significant chance of materializing

It's the other way around - we need to assume that UCG (unbounded computational growth) will materialize, and we need to do our absolute best to prevent it from happening.

In other words, functionality first, optimizations second.

The concern about UCG is a matter of functionality, not of optimizations.

We first and foremost need to ensure that the chain will be functional and won't go down. Only later we can think about nuanced features like multiple streams between users.

[IaroslavMazur]

Thank you for expressing your point of view!

Although I see a number of potential problems with the application-layer approach, I must admit that I've softened up to it.

In any case, it does feel like we shouldn't preoccupy ourselves with this problem right now. Users wanting multiple Streams between themselves is only really possible if they like SabVM, in general, first. So, we should take care of the latter first - and get back to this discussion afterwards.

---

Side note: wouldn't we cause issues for SabVM users' accounting by separating the multiple Streams at the application layer, while keeping them merged into a single one at a lower level? 🤔

[razgraf]

I'd categorize having a single edge between sender and recipient as an inconvenient not a problem. Using a single edge drastically simplifies our architecture, which I'd say is high priority at the moment.

For use-cases such as the Google example or the real-estate, I'd just abstract this away in our first version to a safe or something that holds sub-accounts. Inconvenient (sender would stream to a single entity with multiple addresses) but easier to digest.

---

P.S. I think Superfluid has the same issue at the moment right? No multiple edges.

[PaulRBerg]

Agree and yes, Superfluid is single-edged, too.

to a safe or something that holds sub-accounts

Account Abstraction

[razgraf]

Exactly, some sort of AA.

[IaroslavMazur]

Just to make sure I've got the idea correctly: you're talking about a single user/address having a maximum of 1 outgoing Stream (where they are the Sender) to anyone in the network - and not just having max 1 Stream towards some other user, right?

e.g. if $A$ is streaming towards $B$, they can stream to nobody else simultaneously (including a 2nd Stream towards $B$, a separate Stream towards $C$, etc.)

[PaulRBerg]

We are and we have been talking about the latter case.

A single "edge" means a single stream between any two users. User A can stream to B, and B to C, and A to C.

It's just that A cannot have two streams to B.

[IaroslavMazur]

@PaulRBerg, thanks for the clarification!

Indeed, it makes sense to disallow multiple active Streams between the same 2 users.

[PaulRBerg]

Note to future self:

To enable multiple streams between users, we will need to set IDs for streams. This isn't currently a requirement because we can identify a stream just by the sender, the recipient, and the token ID.