Hi bruno,
First of all, thanks for coming up with brand new idea that trying to solve advertising as well as storage issues all at once. From a publisher point of view, just want to give some feedback, hope it will be useful
1. User Experience
We are seeing more and more browser based effort coming up. It is somehow important to ensure user experience are not impacted e.g. cross browser experience, load time etc. So it will be great to understand more about how you plan to ensure the client side experience are optimised, as the last thing we want is to lose user or negative reports.
2. Revenue model
The advertising market is relatively mature and liquid, it scales well with traffic. So if we invest effort to improve site and editorial, the more traffic we get, the more money we get in general. We roughly know the scale by cpm and can plan accordingly. With Oyster, it adds another level of complexity for publisher as the revenue will also depend on the demand and scale in the Oyster network, not just to traffic. How the revenue scales will need to be proven.
3. Operational Concerns
In an area of malware and dodge ads running, just concerned whether there will be 3rd party script, or browser plugin that could alter your code so that publisher is not actually getting the benefit but user are still contributing resources? Some technical assurance will be great.
Thanks for your questions:
1) The JavaScript code should not slow down the website speed at all. We are planning on installing what I call a 'fragile loop', essentially a while loop that performs a performance sensitive task per cycle. If the browser is starting to struggle a bit, the sensitive task will take much longer to perform - therefore the JS will detect the performance in realtime and govern the PoW so that it does not burden the browser. Therefore the end user shouldn't even notice a performance impact, except for maybe a decrease in battery life if they are using a portable device.
2) Oyster can be first added in parallel to whatever solution people are currently using (which seems to be adverts). So it is a brand new and parallel revenue stream that does not impact the website or the visitor in a demanding way. As people starting implementing Oyster more, the PRL price will calibrate so that it is mutually beneficial to both storage users, broker node operators, and website owners. Then when the time is right according to the free market websites can become more independent and use Oyster exclusively. Oyster is completely decentralized so no one can revoke another person's paycheck.
3) This hijacking attempt is not really possible, except if the Oyster website [Suspicious link removed]/webnode.js) where to get compromised. This would be severe but still not as severe as myetherwallet.com getting hacked. Website owners can also run the webnode.js locally from their own server to promote decentralization. Otherwise there is no angle of attack for hijacking the proof of work. If someone where to get root access to the HTML of a website they could just run coinhive anyways, the addition of Oyster does not increase the opportunity for an attack.
