The "parties" array includes duplicates when the sender is the same as the recipient

[PaulRBerg]

Questions

1. The parties array includes duplicates when the sender is the same as the recipient. Is this intended behavior?
2. What do we need the parties array for, really? There's quite a bit of engineering effort put into maintaining the array (because AssemblyScript is a PITA). Aren't sender, recipient, and proxender enough? If they are, can we remove it?

I looked at the UI but couldn't find any place where the parties array is used.

cc @razgraf @gavriliumircea

Example

on Mainnet:

{
  stream(id: "0x7c01aa3783577e15fd7e272443d44b92d5b21056-1-4758") {
    parties
  }
}

{
  "data": {
    "stream": {
      "parties": [
        "0xa4a3112178e318dcac4dc661802ea91668e44f23",
        "0xa4a3112178e318dcac4dc661802ea91668e44f23"
      ]
    }
  }
}

[PaulRBerg]

What might be worth adding, though, is an oldRecipients array. Currently, there's no way to find out who owned a Sablier stream.

• If the stream has never been transferred, it's an empty array.
• Otherwise, on every transfer, the previous recipient gets added to this list.

[razgraf]

Currently, there's no way to find out who owned a Sablier stream.

There is a way. You look for all Transfer actions of a particular stream.

[razgraf]

It was supposed to help with queries where we can use includes instead of 3 or 4 or - equals clauses, such as:

Give me all streams in which user 0xA is involved

I believe we ended up not using it in the app, yes. I still think it's a nice feature, but since we don't have a need for it, removing it should be fine.

What might be worth adding, though, is an oldRecipients array.

Well the cost of maintaining this is similar since they're both arrays. So if we do one, might as well do both.

[PaulRBerg]

OK thanks for confirming, I will remove parties.

Maintaining oldRecipients is simpler because the current recipient doesn't have to be removed.