Reverse mapping that indexes stream ids by user address

[PaulRBerg]

Task

It may be helpful for all kinds of integration purposes to read all stream ids belonging to specific addresses. In principle, this is how this could be done:

1. Add a new mapping in LockupLinear and LockupDynamic called _streamsByUser
2. Implement a new getter getStreamsByUser
3. When a stream is created, update both the default _streams mapping, as well as the _streamsByUser mapping
4. Update all tests that check the _streams mapping to also check the _streamsByUser mapping

This feature wouldn't classify streams by status, but it would still be helpful.

Notes

• It might be worth looking at OpenZeppelin's ERC721Enumerable in case their tokenOfOwnerByIndex function would help
• @andreivladbrg has implemented something similar in our Allo V2 integration.

[allwin199]

I would like to work on this, whenever necessary.

[PaulRBerg]

Thanks @allwin199, this is marked as "backlog".

[PaulRBerg]

I have just realized that the task description in the OP was incomplete. _streamsByUser could have been implemented in several ways, that is, user could have represented any of the following:

1. Just sender
2. Just recipient
3. Both sender and recipient

A more precise implementation would have two mappings:

1. _streamsByRecipient
2. _streamsBySender

And two getters:

1. getStreamsByRecipient
2. getStreamsBySender

[PaulRBerg]

After discussing this feature with @andreivladbrg and @smol-ninja, it has become apparent that this is way more complicated than we had initially expected. To copy-paste Andrei's observations from a private Telegram group:

That's the only thing I can think of for now. The implementation might be complex, though. It would require an algorithm to determine if the streamId exists only in the recipient's array (not for the sender) and to update the mappings accordingly: removing the id from the former recipient and adding it to the new recipient. I wrote a quick implementation to give an idea of how it might look. However, I wouldn't bet on it to be the best/correct way of doing this, since I haven't tested it.

Also, there must be an edge case when the NFT gets burned; both mappings (sender and recipient) should be updated. There are likely other scenarios, but I can't think of them at the moment.

A note about the implementation: I don't believe it's possible to optimize the index search in the array, especially since burns and transfers will disrupt the array's order, preventing it from being strictly ascending.

It looks like we may need to use a library like OpenZeppelin's EnumerableMap. However, implementing it is not trivial. It would take time, and it would increase the gas costs in a significant way.

It is also worth noting that reverse indexes can be implemented off-chain (e.g. via subgraphs).

Given the above, I will tentatively close this issue as not planned.