Bradymck
commented
7 years ago I really like this, I think there may be synergy with my proposal as well: https://github.com/district0x/district-proposals/issues/64
I'm in the process of rewriting mine to be more of a micro service market. I received some feedback and comments and it's looking to work better as an off chain listening server or in the case of what your proposal, it takes the cross district functionality and extends it into the real world data as well. I would love to throw ideas around and see if we can boil these down into a similar use case that could either benefit both districts or even become one.
I see it like this:
Mine is a cross district event chaining market, the market will be traditional servers offering the automation of posting to other districts when another post is listed, completed or sponsored. In your case, the plugins could be on these servers as well and be pulling data in to chain posts based on real world data as well.
Just spit balling here.
Thoughts?
puttersworth
quantumdwayne
8lcarte
always2late
parag
chickenpie347
Name:
MassZone Plugins
Purpose:
MassZone Plugins will be a marketplace district (a Zone) focused specifically on the creation, development, refinement, discovery, incentive mechanisms, and sales of Plugins catered to the Mass population (inclusive of businesses and private individuals) for Mass adoption. It will be a repository of plugins where members can create, find, fund, support, critique, rank, sale, and buy plugins. Of notable importance, members of the district will be incentivized to provide intrinsic value (via contributions of dev work, funding(s), etc.) to the plugins because they will be correlatively rewarded for said contributions. This will largely increase the overall success rate of the plugins created and delivered by this district.
Plugins (or add-ins, addins, add-ons, addons, or extensions) are a critical component to the mass adoption of new technologies. They enable a plethora of different functions and behaviors to execute which expands and extends the functionality of the underlying program. They have become ubiquitous with the internet and other prominent applications that exist on the market today. More than likely, 99.9% of users [including you] are using one or more plugins – knowingly or unknowingly – whilst reading this proposal. With customization capabilities, plugins are able to provide a large, differentiated user base with a common set functions or behaviors- all while requiring minimal, or no, change to the plugins’ code.
A few key reasons plugins are widely used include:
There are numerous types of plugins, with the most recognizable being those associated with WordPress. The ease and simplicity of using plugins is, in my opinion, one of the reasons why WordPress has become as mainstream as it has. It gave the masses the tools (i.e. the plugins) necessary to create the site(s)/operation(s) that they desired without having to know code, learn code, or hire a developer. Plugins are not only valuable to the District0X foundation and its ability to function within itself and amongst other platforms, but plugins as a “general facilitator” are going to be extraordinarily valuable for blockchain technology as an industry.
At present, plugins catering to the Ethereum blockchain are very limited and because of this there is a significant opportunity to develop a district around the development, rating system, and purchase and sale of plugins. Right now Metamask (https://metamask.io/) is developing a chrome plugin with plans “to support Firefox and beyond”, WordPress has five (5) plugins associated with cryptocurrencies + purchasing via Ether, and there is a general lack of plugins dedicated to this space because of the “newness” of crypto in general. There will undoubtedly be countless plugins developed in the coming decade and beyond, therefor now is the time to develop a solid community and district catering to this marketplace. It should go without saying that the people that create, find, fund, support, critique, rank, offer for sale, buy, and/or provide any intrinsic value to plugins directed toward the blockchain will be the ones who benefit in immeasurable ways not yet known. I liken it to the sellers of shovels during the gold rush where plugins are the shovels to the ethereum/blockchain gold. This is why I’m proposing to create MassZone Plugins.
Description:
The district will be composed of the following “pages”:
Profile page, publicly showing members’:
--> Contributions will be synonymous with DNT and the specific amount of DNT attributable to the various types of contributions will be pre-determined by each member and their preference. Delivery of DNT contribution will happen via execution of automated smart contracts. This will provide a valuable incentive system because members who offer no, or not enough “contribution incentive”, will not get much, if any, help/contribution in making their plugin projects successful. Members who allocate larger DNT and/or offer profit-sharing arrangements for contributions will get significantly more help/contribution from other members of the district. This should produce better, higher quality plugins and the upside profit (DNT/contribution) will be shared by any and all who contributed to the plugin’s success. The smart contract feature will also prevent any “misunderstanding” or “delays” in receiving DNT/contribution because the terms will have already been set and mutually agreed to and accepted. This incentive system also may reduce “copycat conflict” where you can get two people trying to create the same plugin... If they are both going to benefit (potentially right down the middle, 50:50 if they agree) then it would seem logical they would team up and cooperate as opposed to try to independently develop. NOTE: I could be completely wrong on this last part regarding copycat conflict; that’s just MHO.
Plugin search page:
Filterable by category, tags, rating, DNT price, # of installs, desired operation, compatibility, contribution level(s), level of completion, value*
Value of the plugin could be determined through a weighted combination of the # of people (the mass) who have effectively utilized the plugin and its respective ranking. For example, value = ((#of installs with positive feedback .75) + (#of upvotes .25)) / #of total installs of the plugin. This is just a crude example and the expectation would be to hold semiannual voting proxies to establish this and other formulas, algorithms, and governance policies.
Plugin overview page:
- Plugin details – What it does, what problem it solves, use cases, screen shots, etc. - Purchase – Plugin price in DNT where plugin owner sets the buy price. All contributions pre-linked to profit sharing will have already been established and will enable every contributor to receive his/her respective pre-established percentage of DNT (i.e. the profit share of the sale) regardless of the price the owner sets. This could be voted to be different if a compelling case against it existed. - Ratings & reviews – plugin users can provide the creator(s) + contributor(s) with ratings and reviews that will establish and differentiate the good creators + contributors from the bad; users will be naturally incentivized to provide ratings and reviews for the betterment of the community at large. This is similar to most other ratings and review systems: your work product sucks, you get a bad review and the users wants to warn/prevent others from the same shitty experience; your work product is excellent, you get a good review! - Plugin creator’s reputation status – on the 1:10 scale (unworthy:worthy) potential plugin users/purchasers can get an assessment of how well-respected and trusted the plugin creator is. Because potential plugin purchasers will use this metric in determining whether to purchase a plugin, plugin creators are incentivized to be respectful, honest, and trustworthy at all times within the district; if they are not, their plugin sales will suffer via bad Rep status. - Comments – self-explanatory - Support – plugin users can reach out directly to the plugin creators and contributors to solicit support. A specific amount DNT (mutually set and agreed to by the two parties) would be transferred to provide additional support/customization that did not originally come with the plugin. - Working demo/preview – self-explanatory. Potentially offer a free trial period to validate plugin efficacy. - Fund it! – depending on the stage of development, anyone who possesses DNT can contribute to the plugin by sending DNT and receiving the correlative pre-established funding contribution reward.
Plugin idea generation page (a.k.a. PluginIG):
--- reference "Plugin Idea Generation" below ---
Open forum & chat page: self-explanatory
FAQ, help, support page: self-explanatory
Use case:
Joe wants to make a plugin that allows him (or a company’s internal servers) to pull the geo location and speed of all smart cars currently in motion. Why? Because he thinks it would be neat and businesses which are dependent upon traffic flow(s) would likely pay Joe a decent sum of money for this functionality/data.
Therefore:
How MassZone Makes Money:
MassZone will have to take a cut of certain revenue/DNT streams; it’s a necessary evil to maintain the quality and consistency we are looking to achieve and that the plugin users, creators, and contributors deserve. The cut will however be limited to only those plugins that generate > 200k DNT over any rolling 90-day period- and of those plugins, a sliding fee scale will be applied.
For example, the logic would go as follows:
For every rolling 90-day period, if the plugin generates:
Utilizing this fee structure incentivizes successful plugins (i.e. the creators/contributors thereof) to reach even greater levels of successful because the more sales/DNT they generate, the lower the fee bracket they’re in, and the more DNT they ultimately pocket. It also doesn’t unduly charge the “less successful” plugins that may likely already been in the red (unprofitable) because of development, hardware, labor, and other costs that have been expended on the plugin. A key thing MassZone wants to encourage and NOT stifle is the creativity of the creators; if the creators feel they are going to get “shafted” with a fee for ANY revenues (on top of the sunk costs for development) they are going to be less inclined to take risks and come up with the real game-changer plugins, which is exactly what we want, game-changers!
Plugin Idea Generation:
MassZone will have a standardized template (actually https://github.com/district0x/district-proposals/issues/40 would fit well here) which solicits all pertinent information necessary to develop a new plugin. This would include the general functionality of what the plugin should accomplish and not necessarily the backend of "how" it accomplishes it. People seeking a plugin which does't currently exist can fill out this standardized template and that information would be automatically submitted to, and populate, a page at MassZone called PluginIG. Developer members (i.e. the plugin creators) can go to PluginIG, search for plugins they think would be fun, interesting, rewarding to code, and go about developing the plugin should they so desire. If the desired plugin is highly custom/user specific, and the plugin creator doesn't believe they would be able to sell it broadly into a larger market/application, the plugin creator and the person seeking the plugin can create a separate, independent smart contract arrangement to do said work that is agreeable to both parties. Or they don't come to an agreement and both go their separate ways...
Additional Thoughts/Notes (thinking aloud):
Plugins on MassZone will be of top notch quality with the bottom 10% being “cut” annually and the top 10% receiving bonuses for additional, continued motivation. NOTE: the 10% bottom cut doesn't apply to plugin creators and/or contributors- it applies only to the actual plugin itself.
Catering to the masses will be the moto for the district with special attention to making plugins that are easy enough for a grandma or child to use, i.e. the masses.
Members can remain anonymous
Awards/flair will be assigned to those identified as being a best seller, best developer, most inquired, highest rated, etc.
To provide checks and balances, there will be:
Again, as mentioned above, where there are objective values being sought (for example >50.1% from the 7 board of directors to signal a change in policy) the community that makes up the district will need to voice their opinion.
Expanded staking: ??? I’m not entirely sure of the feasibility with what I’m going to propose here, but… could it be possible that plugin creators are able to “generate” DNT (or some similar, off-shoot form of DNT) based on the number of plugin installs and/or plugin use? As an example, let’s say Tom creates a plugin and 500,000 people have downloaded and are using it. They may have already paid a small upfront fee to purchase it, but could Tom continue to earn “dividends” on his creation through the generation of some other form of token/coin? This question is very much related to the NEO token I’ve been holding and its ability to generate “GAS”. I have X tokens and everyday I’m earning GAS “tokens” as well. This is quite an amazing feeling and one in which the plugin creators should also get with respect to their creations. Can something similar to this be enacted under the district0x platform? If not, I suppose Tom could potentially specify his plugin as a “service” and therefore for every month a user has Tom’s plugin installed, the user would be required to pay Tom 0.1 DNT as rent or a license fee? Or, the rent/license fee may be based not upon a fixed interval, but rather a number of computations it completes. Once a certain threshold (or multiple thresholds are met) different trigger payment tiers could be executed.
Feel free to ask any and all questions which I begin to answer and include here:
Thanks, and long live d0x!
Q: Are these plugins that can only be used within the MassZone district or are they plugins that can be installed on other districts? A: These plugins could installed and utilized on other districts as well. At the risk of being overly ambitious/visionary, the intention is that these plugins could be compatible not only within the District0x framework (d0INFRA), but among the Ethereum network and across the entire blockchain ecosystem as well (cross-chain functionality). At least that's the ultimate goal.
Q: Do they have to go to MassZone to use it? A: No. The plugins can function on any district and run independently of MassZone. For the sake of argument, let's say MassZone "went down" (not that that's a possibility), but hypothetically, if it did, the plugin(s) would remain fully functional operating in a "stand-alone" state if you will.
Q: Or will it be like Wordpress where I can install it into the backend of my district? A: Yes, it will be like a WP plugin that installs on the backend; that is an excellent analogy.
Q: How will contributors want to monetize? A: The monetization model would find it's natural equilibrium without much, if any, outside input. Through trial and error, plugin creators and contributors would naturally come to some commonly "accepted and agreed-to" price range for the various contribution components. For example, Tom will not get much contribution if all his contribution rewards are cheapskate/minimal (i.e. not worth anyone's time), yet Bill who is overly generous with his contribution rewards may get too much contribution and dilute himself out of any exciting ROI, which also isn't an ideal. The community will quickly discover and learn what the "acceptable/respectable" contribution ranges are, and will not likely deviate far from that range.