Copy edits #30
Copy edits #30
Conversation
This commit includes copy edits of "white-paper.md".
There was a problem hiding this comment.
I've read over the whole document a couple times, and I have questions. 😁
I recognize GitHub might not be the preferred place for discussion, but I look forward to seeing your thoughts on these matters whether on Telegram, Discord, or wherever.
Super excited about tea!
- The paper mentions "leftpad" among other projects and says we need to ensure software integrity, but what stops someone from rage quitting on a project? Couldn't they theoretically unstake and/or unsteep, and walk away? I see that the "leftpad" situation would still be slightly improved because they wouldn't be able to simply pull their packages off of the Internet, but is that the extent of protection?
- The document speaks a lot about punishing bad actors, but what about people who make earnest mistakes? Further, what if someone is on vacation for the entirety of the "governance-defined grace period" for responding to a tea taster? Will that also result in slashing?
- What happens if someone submits a package for which they aren't the maintainer? Let's say I grab Homebrew and publish it on tea. Now I have the NFT. How do we navigate this situation if you want to rightfully claim ownership of that NFT? Additionally, the Sybil attack scenario where someone creates many identities is addressed, but what about if they make a bunch of packages on behalf of real maintainers without their knowledge?
- On line 169, we say, "Packages may only depend on major versions or greater than specific versions, but for the whole range." What does this mean? I comprehend right up until the "but for the whole range" bit.
- What is the explicit behavior we're trying to avoid that wastes developers time on line 199? "To disincentivize wasting developers’ time, communication between the tea tasters and package maintainers will require the tea tasters to steep tea tokens." I think it would be helpful to be more clear here.
- Similar to item 1, is there an exit strategy? If someone decides to hang up their software development hat, how do they gracefully leave the system? I think this is something that should be made clear up front.
- Is there anything we can do to protect NFT holders from scammers? It seems inevitable that someone will accidentally hand over their seed phrase and lose their maintainer NFT or what-have-you.
- On line 225, what does ESG stand for?
- Is it possible for a package maintainer to act as a tea tester and make a negative or positive report about their own project? Is there a world where the total reward for doing so would be higher than simply being a reputable maintainer?
- Y'all go into detail about the possibility of leveraging a DAO to remunerate all maintainers involved in the development of a package. Curious, did you consider fractionalized NFTs? It seems like it could be a way of keeping the remuneration native to the system.
- In the "Dependencies Analysis" section, there is a bit of a conflict in what is communicated. On line 155, we say, "To provide a simple methodology that rewards all developers who have contributed to open-source software while keeping the creation of the dependencies tree quick and computationally efficient, we propose to verify only first-level dependencies upon submission of a package." and on line 167, we say, "To address this, we propose each package be subject to a full dependency scan upon submission so we can ensure that the package complies with the following rules for semantic version ranges." What is the intended behavior and does it change depending on the lifecycle of package maintenance?
- On line 199, there is mention of a "messaging protocol". Will this be native to the blockchain? Or is there any additional detail that can be shared about this? There are a few—but not many—blockchain solutions out there right now that could actually facilitate messaging. DeSo comes to mind.
- Is there any risk of tea tasters becoming predatory? Let's say a bunch of people find this awesome new tea tool, and they try it out but don't get the traction with their package that they're looking for and stop paying attention to it. If that happens in a high enough volume, I could see a scenario happening where tea tasters race to ruin the reputations of tiny projects created by newer developers. This could have a negative effect on the ecosystem.
- Will the "governance-defined" period of time take CVE severity into account? Or will it be fixed?
- Is the list provided in the "Governance" section exhaustive? Those were "inflation, transaction fees, staking rewards, steeping rewards, or optimum steeping ratio."
| @@ -212,7 +212,7 @@ As packages gain in popularity and usage, with more applications and potentially | |||
|
|
|||
| ## Maintainer NFT | |||
|
|
|||
| Upon successful submission of a package, the package maintainer will receive a non-fungible token (NFT) to evidence their work and contribution. The holder of this NFT will automatically receive all rewards associated with the package. Package maintainers may transfer maintenance ownership over a package to another package maintainer by simply transferring the package’s NFT. Successful transfer of the NFT will lead to the new owner automatically receiving future package rewards. | |||
| Upon successful submission of a package, the package maintainer will receive an NFT as evidence of their work and contribution. The holder of this NFT will automatically receive all rewards associated with the package. Package maintainers may transfer maintenance ownership over a package to another package maintainer by simply transferring the package’s NFT. Successful transfer of the NFT will lead to the new owner automatically receiving future package rewards. | |||
There was a problem hiding this comment.
Felt odd to break up "NFT" into its component words here when it had already been used many times beforehand without qualification.
There was a problem hiding this comment.
Fair - We should include the "non-fungible token" expended version in section 5.1 then, the first time NFT is used so there is no ambiguity.
There was a problem hiding this comment.
That works. I'll add it.
There was a problem hiding this comment.
But also, wen nfteas?
|
Wow! Thank you! We’re looking through these and love your contribution. |
|
Thanks @artburkart - Comments are below
They could definitely unsteep, but that would be very visible. The incentive for package maintainers is to remove the tea they have steeped, so they don't get slashed and lose tea, but doing so triggers an event that is visible to all. That event signals the rest of the community who can then decide whether to unsteep themselves and stop using the package, or fork it and maintain it themselves. |
One of the goals of the governance-defined grace period is to account for earnest mistakes and give people the opportunity to correct them. |
That package could be looked at as a fork. Handling package forks is something we've listed under future work. tea tasters could also flags these forks as such and steep against them, thus affecting the reputation of the package and their "maintainer" |
I could create a bot to overload a developer with unsubstantiated claims that the developer would feel they need to address to maintain their reputation. Having to steep tokens should disincentivize this behavior. |
|
6.Similar to item 1, is there an exit strategy? If someone decides to hang up their software development hat, how do they gracefully leave the system? I think this is something that should be made clear up front. See 5.1 "The holder of a package’s NFT can transfer its ownership to another developer (or group of developers), thus making them maintainers of the package and recipients of any future rewards. Similarly, a developer may decide to take on the role of package maintainer by forking the existing package and submitting a new one which they will maintain moving forward, thus becoming themselves both package creator and maintainer." |
We should look at this from 2 different angles:
Governance could be an approach there as well, but I believe we should be very careful not to give Governance the ability to control where NFTs are/who owns them, as it would materially increase the attack surface. |
ESG = Environmental, Social, and Governance |
A package maintainer could try to do that. This is one of the reasons why we need to make sure the system (including the reputation system) integrates Sybil protection mechanisms. |
The use of a DAO to remunerate all maintainers is part of future work. Fractionalized NFTs could be another approach - Great idea! Let us know if you're interested in building it. |
The goal here is to check the first level of dependencies to limit compute requirements. The underlying assumption is that a package used as a dependency is a package that was itself submitted to the registry (See Figure 2). |
The goal would be for it to be native to the chain. We'll share more in the yellow paper in a few months. |
|
13.Is there any risk of tea tasters becoming predatory? Let's say a bunch of people find this awesome new tea tool, and they try it out but don't get the traction with their package that they're looking for and stop paying attention to it. If that happens in a high enough volume, I could see a scenario happening where tea tasters race to ruin the reputations of tiny projects created by newer developers. This could have a negative effect on the ecosystem. We always need to consider the risk of any participant becoming predatory. We'll share a mode detailed view of the tokenomics with the yellow paper that will include information on multiple scenarios including this one. |
At launch, it is likely to be kept simple, but the intent should be to allow for the community to make that decision and give Governance the tools to enact it. |
No - the list is not exhaustive, hence the "these parameters could include" |
This is a relatively unclear way of saying eg. >=5.2 <6, clearing up the language here would be good. |
There was a problem hiding this comment.
@thomas-borrel and @mxcl, thanks for the thorough review last week. I was traveling, so I didn't get back to it right away. For the most part, I don't have follow up questions, and I'm going to push up a PR that acquiesces to any rebuttals you've made.
The use of a DAO to remunerate all maintainers is part of future work. Fractionalized NFTs could be another approach - Great idea! Let us know if you're interested in building it.
I don't think I'm the person you want implementing fractional NFTs, but I will look into and follow up with suggestions.
Also, I tried to get a hold of Nick via Telegram, but I haven't received a reply yet, and I can't DM them on Discord. 😅 Any chance you could pass on the message that I'm trying to get in touch? I'd very much appreciate it. 😊
|
|
||
| * Packages may only depend on major versions or greater than specific versions, but for the whole range. | ||
| * Packages may only depend on a major version or any version preceding the next major version increment (e.g., >= 5.2 < 6). |
There was a problem hiding this comment.
@mxcl
Perhaps this is clearer? This is really challenging language. 😅
There was a problem hiding this comment.
It’s an “and”. I suggest:
Packages may only constrain their dependence to a major version though the starting range can be any semantic version (e.g., >=5.2.1 <6).
There was a problem hiding this comment.
Before I make the edit, are you saying "dependence" or "dependencies"?
This?
Packages may only constrain their dependencies to a major version, though the start of the range can be any semantic version (e.g., >=5.2.1 <6).
There was a problem hiding this comment.
I did mean dependence but I guess dependencies is better.
|
|
||
| [^13]: Source: @medium | ||
|
|
||
| ## Package Users | ||
|
|
||
| Package users are software developers focused on solving a specific problem. They often look in the open-source community for the tools they need to experiment quickly and iterate at very little to no cost, directly benefitting from the work of package creators and maintainers. Traditionally, a subset may have chosen to support package maintainers through donations or other forms of remuneration; however, this has rarely been the case. | ||
| Package users are software developers focused on solving a specific problem. They often look in the open-source community for the tools they need to experiment quickly and iterate at very little to no cost, directly benefiting from the work of package creators and maintainers. Traditionally, a subset may have chosen to support package maintainers through donations or other forms of remuneration; however, this has rarely been the case. |
There was a problem hiding this comment.
Kept it as "benefiting".
white-paper.md
Outdated
|
|
||
| ## Package Supporters and Sponsors | ||
|
|
||
| In Web 2.0 and web3, package supporters have often been called “sponsors.” They are organizations or package users who use open-source software to build their commercial products, philanthropists looking to support the ecosystem, or entrepreneurs looking to fund teams to develop components of a larger system. | ||
|
|
||
| tea proposes to extend the communities of package supporters to the entire tea community, whether organizations, developers, users, or tech enthusiasts. tea’s goal is to implement decentralized incentive mechanisms through unique use cases of the tea token for any member of the tea community to contribute to the perpetual sustainability and continuous growth of open-source. Package supporters and sponsors are free to decide which packages or package maintainers they want to support based on their work, beliefs, or any criteria and metric that would influence their decision. Additionally, the support provided by package supporters and sponsors will flow to each package’s dependencies, thus implicitly trusting the package maintainer to make good choices about their stack and using this information to contribute to their reputation. | ||
|
|
||
| Provided that the package maintainer offers such service, a package supporter and sponsor may receive a premium support level NFT in return, thus benefiting from accelerated SLAs or more flexible licensing. Additionally, package supporters and sponsors may decide to support packages or package maintainers and automatically redirect all or a percentage of their rewards to incentivize teams to build new open-source software. In other words, packages don’t need to exist for tea to start pouring in. Nascent projects can be supported just as well as more mature ones, further incentivizing a constantly evolving open-source landscape. | ||
| Provided that the package maintainer offers such a service, a package supporter and sponsor may receive a premium support-level NFT in return, thus benefiting from accelerated SLAs or more flexible licensing. Additionally, package supporters and sponsors may decide to support packages or package maintainers and automatically redirect all or a percentage of their rewards to incentivize teams to build new open-source software. In other words, packages don’t need to exist for tea to start pouring in. Nascent projects can be supported just as well as more mature ones, further incentivizing a constantly evolving open-source landscape. |
There was a problem hiding this comment.
Oh, I see. Thanks for the clarification.
white-paper.md
Outdated
|
|
||
| Our goal is to reward both Web 2.0 and web3 developers. The intricacies and specifics of each stack make it so that tracking installations and uninstallations of packages could easily fall victim to one or more bad actors. That includes “buying” installations to artificially inflate numbers. An even worse scenario would be introducing fundamental changes to the nature of open-source software by creating unnecessary friction with license keys or other deployment tracking mechanisms. To provide the broadest coverage, we believe that rewards mustn’t rely on a simplistic notion of tracking installations or uninstallations, but rather on incentive mechanisms that encourage the submission of quality packages and the reporting of nefarious or high-risk packages. Lastly, many packages rely on common dependencies. For example, lodash has 151,209 dependents[^15] while chalk has 78,854 dependents[^16] or log4js has 3,343 dependents[^17]. As more packages are created using the same dependencies, how do we ensure that incentives are distributed fairly and equitably? How do we ensure that the most utilized dependencies are rewarded without starving new or emerging packages and developers? How do we ensure that the incentive system does not end-up steering developers away from niche languages to centralize them where incentives are better? But also, as developers, how do we identify packages with the most dependents to build alternatives - leaner, more efficient, better-coded versions of these packages? At tea, we believe that the lack of incentive has impeded the evolution of open-source software. Supported by the right economic incentives and rewards, more developers will be in a position to build, improve and augment open–source software for the betterment of the world. Only then will the tea token be able to represent the total value of open-source software. | ||
| Our goal is to reward both Web 2.0 and web3 developers. The intricacies and specifics of each stack make it so that tracking installations and uninstallations of packages could easily fall victim to one or more bad actors. That includes “buying” installations to artificially inflate numbers. An even worse scenario would be introducing fundamental changes to the nature of open-source software by creating unnecessary friction with license keys or other deployment tracking mechanisms. To provide the broadest coverage, we believe that rewards must not rely on a simplistic notion of tracking installations or uninstallations, but rather on incentive mechanisms that encourage the submission of quality packages and the reporting of nefarious or high-risk packages. Lastly, many packages (i.e., dependents) rely on common dependencies. For example, at the time of writing, Lodash has 151,209 dependents[^15], while Chalk has 78,854 dependents[^16] and log4js has 3,343 dependents[^17]. As more packages are created using the same dependencies, how do we ensure that incentives are distributed fairly and equitably? How do we ensure that the most utilized dependencies are rewarded without starving new or emerging packages and developers? How do we ensure that the incentive system does not steer developers away from niche programming languages to centralize them where incentives are better? And as developers, how do we identify packages with the most dependents to build alternatives—leaner, more efficient, better-coded versions of these packages? At tea, we believe that the lack of incentive has impeded the evolution of open-source software. Supported by the right economic incentives and rewards, more developers will be in a position to build, improve, and augment open–source software for the betterment of the world. Only then will the tea token be able to represent the total value of open-source software. |
There was a problem hiding this comment.
Removed "i.e., dependents"
|
|
||
| {#fig:steeping-rewards} | ||
|
|
||
|
|
||
| Versioning and conflicting dependencies are significant challenges, and troubleshooting them can turn into massive time drains. To address this, we propose each package be subject to a full dependency scan upon submission so we can ensure that the package complies with the following rules for semantic version ranges. | ||
| Versioning and conflicting dependencies are significant challenges, and troubleshooting them can turn into massive time drains. To address this, we propose each package be subject to a comprehensive dependency scan upon submission, so we can ensure that the package complies with the following rules for semantic version ranges: |
There was a problem hiding this comment.
I switched this to "comprehensive" because it's more evocative of quality, whereas "full" seemed to communicate quantity.
|
Oh, also, would it be helpful if I looked at all the other PRs that have come through? |
|
Sorry for the delay on this, but frankly, it's a lot to review. |
@mxcl - yeah, this isn't a great forum for this type of discussion. I'll break it up into smaller PRs, so we can get some of the noncontroversial stuff merged. Smaller chunks should make it easier to process. 👍 |
|
I've captured all the changes in separate pull requests, so this can be closed and removed. Thanks for all the reviews! Nick reached out to me, but we still haven't had a chance to connect; very much looking forward to meeting him! |
|
You're a superstar @artburkart 🔥 |
This commit includes copy edits of "white-paper.md".
It's getting late by me, but I wanted to get these initial copy edits proposed. Tomorrow I'll follow up with inline commentary.