Should we document how to create streams only via the proxy?

[PaulRBerg]

The current docs show how to create streams by interacting with the core directly:

• Create a Lockup Linear stream
• Create a Lockup Dynamic stream

The problem is that streams not created via the proxy will not appear in the Sablier UI (ref: sablier-labs/v2-periphery#11).

So, the question is: should we only document the proxy approach of creating streams, and not even mention the direct way?

Pros for "yes":

• Avoiding cases where the integrators intended the streams to be manageable via the Sablier UI
• Promoting the use of the proxy approach across the ecosystem

Cons for "yes":

• Overcomplicating the docs
• Having to explain the proxy system would make the docs more difficult to follow through
• Not all developers may want to use the periphery; e.g. DAOs creating streams may not need to see their streams in the Sablier UI (as senders)

Cc @razgraf, @gavriliumircea.

[razgraf]

will not appear in the Sablier UI

They will appear, it's just that the sender will not be able to interact with them. The global dashboard search will show all streams created within a Sablier V2 deployment set, so discoverability is still possible but in a "public" manner, not as a stream party (you won't be identified as a sender).

---

Post sablier-labs/v2-periphery#11 proxies became a very big part of our ecosystem.

Not documenting/referencing them would be an error on our side. I believe people will assume the "core" is enough to get going and find themselves in weird situations. We'd also want them to understand the proxy well enough to enable future functionality (e.g. transitioning from V2 to V3, airstreams, other targets).

I suggest splitting the protocol docs into two parts: core (bare bones) and advanced (periphery, other things).

Core

The core (esp. the parts about creating streams) can include callouts/notes referencing the advanced section. Example:

Note: To support advanced functionality (e.g. cancel-and-create, batching) and make streams fully compatible with the Sablier client apps, please look into integrating the proxy and periphery logic.

Integrators can choose to use the core natively, but will now be clearly warned about the periphery aspect. Even if we don't wanna pollute the core section with too many callouts, at least the introductory section should contain these kind of notes.

Advanced

Therefore an "advanced" (or whatever you want to call it) section will tackle all things proxy and target (which require docs anyway).

As a very important extra step we need a FAQ or linker-section between the two parts, answering the following:

• I have created streams programmatically from an EOA. How do I make it compatible with the app? [ ... you can't, for the sender part]
• I have created streams programmatically from an EOA. How do I make it compatible with the periphery and proxy? [... you can, with the operator model]

I realize this involves some extra work, but at this point the docs do seem a bit distant from our actual flows. They are core-specific docs not full protocol docs.

Uniswap has a pretty good way to explain and document these in their Contracts area.

[PaulRBerg]

They will appear, it's just that the sender will not be able to interact with them

Oh, I see! Thanks for clarifying this.

Not documenting/referencing them would be an error on our side

Yes, but this is not what I asked; I asked whether we should only document the proxy approach. I of course agree that, at a bare minimum, we should document the proxy separately.

I suggest splitting the protocol docs into two parts: core (bare bones) and advanced (periphery, other things)

SGTM

Integrators can choose to use the core natively, but will now be clearly warned about the periphery aspect

Perfect! Then the takeaway from this discussion is to just add a warning at the top of the existing references in my original post.

an "advanced" ... section will tackle all things proxy and target

Great

I realize this involves some extra work

Not a prob