Replies: 5 comments 1 reply
-
On second thoughts, "stream" might not be that bad terminology. Dictionary.com has this carve-out in the definition for stream: I don't see why, in a future where the streaming meme grows in popularity, dictionary definitions could not be updated to include our kind of streams, i.e., something like "digital agreements for distributing financial assets over time". |
Beta Was this translation helpful? Give feedback.
-
I'm not actually keen on changing this terminology. Reason 1: What is streaming?In tech, streams involve continuous distributions (what one might call live flows), but they're also based on clear intervals for said distribution. In video streaming, an asset is broken down into packages that are sent once every There's a cognitive load in assessing a stream split in longer segments as "streaming", I agree with that, but this doesn't mean it doesn't abide by the description above. Therefore, depending on the definition you attach to the concept of streaming, the continuous aspect can simply define "a non-interrupted distribution of items" while the segments which make up that distribution (the milestones) can be on a spectrum from milliseconds to days, months, years.
It can be. It isn't granular streaming, but in a definition that doesn't anchor to a set segment/period, it is still considered streaming. Reason 2: Brand identity
If you mix and match, go to one extreme or the other, a stream/distribution can take many shapes. This has been proven by our LockupDynamic use-cases. Instead of changing the core concept, we could simply define sub-sets of streams. Instead of payroll, there is monthly streaming. Instead of step-unlocks there's quarterly streaming. Instead of complex shapes, there may be milestone streaming. Why change the term when we can adapt the meaning. Secondly, why ditch a great word for a bland one when it become such an important part of our brand. It's a differentiator, a symbol. I've always been against brands losing their uniqueness, with a prime example being the tweet-to-post change. Reason 3: People seem to get itOne important observation coming from these recent UNI-team-coin streams is that people seem to get it. They "created" this time-lock idea (which side note we'll probably add to the app in a bespoke manner soon) without external help. They molded a stream into a new shape. Sure, it's a small sample of users that confirms this reason (the same can be said for the OP) but it's enough to prompt us not to rush this decision of dropping/reducing the usage of "streaming" in our code/materials. A separate suggestionWhile I'd still use "streaming" as a base concept (thus keeping the |
Beta Was this translation helpful? Give feedback.
-
We talked about this on the call today (@razgraf, @andreivladbrg). Arguments in favor of keeping the "streaming" terminology:
We should monitor user feedback and come back to this if and when users give us signals that they are confused by this choice of words. |
Beta Was this translation helpful? Give feedback.
-
Related: https://github.com/sablier-labs/company-discussions/discussions/32 |
Beta Was this translation helpful? Give feedback.
-
One more idea - replacing cc @sablier-labs/solidity. |
Beta Was this translation helpful? Give feedback.
-
Problem
It has become increasingly clear that the term
streams
is a misnomer forLockupDynamic
. You can find a complete exposition of my rationale here, but, in short, the issue is two-fold:LockupDynamic
for timelocks12, i.e., "streams" in which the payout looks like this:Solution
Rename the
_streams
mapping to something else, as well as all semantically related references.My suggestions:
payments
plans
agreements
accords
covenants
schedules
flows
Although I will admit that I don't particularly like any one of these options, for instance, "payments" would be confusing because a settled stream may be composed of multiple withdrawals (the recipient may have withdrawn multiple times). And so you end up with a "payment of payments".
WDYT @andreivladbrg, @razgraf?
Off-shoots
There are several consequences downstream, e.g., the
streamingBalanceOf
function would have to be replaced byavailableBalanceOf
(or something like that). But all these changes flow from the "streams" terminology, so let's deal with it first.Footnotes
https://github.com/sablier-labs/v2-core/issues/706 ↩
https://twitter.com/ashleighschap/status/1712946120584781961 ↩
Beta Was this translation helpful? Give feedback.
All reactions