Topic: [ANN] Oyster Shell (SHL) - Dawn of a New Era - page 3. (Read 4002 times)
We should not take it easy as competition has just started and Pearl Oyster already is at third position at this moment. Community should stay active to make this happen again bu showing strength to take PRL to Bibox with current contest. It will not be easy of course but can be done with little extra efforts.
Oyster Development Update
Today’s development update focuses on the work completed for the week of June 24th to the 29th.
This week the development team has continued to work on the jobs that use Oyster’s eth_gateway and interact with the Ethereum blockchain. The team finished QAing the claim_unused_prls task from the previous week and are now working on a new task called claim_treasure_for_webnodes. With this task, instead of immediately invoking ClaimPRL() when a Webnode has done the PoW and claimed a treasure, the team will add the claim to a table in the database and have a task run which will call methods needed to claim the PRL for the website owner. This way, if the first attempt to claim the PRL does not succeed, the broker node can keep trying until the PRL are successfully claimed. Also, for various bury/claim operations, the team has to send a small amount of gas to the affected addresses. Over time this could add up to a lot of wasted ETH if the bury/claim calls don’t use all the ETH that was sent. Thus, the team has added a method to retrieve leftover gas if there is enough left to justify making a new ETH transaction to get the leftovers, making the system more economical.
In addition, the team has continued to work on integrating a streamable module for the front-end to handle larger uploads. Additionally, the team has been working to establish engineering practices with the goal of increasing the development velocity and code stability. Furthermore, the team has continued work on the Badger DB integration and fixed several related unit tests that were failing, as well as worked on Code Climate refactoring and unit testing the changes for the next broker node release. Also, the team worked on automating the deployment of the broker nodes in a staging environment
Further work has been completed on the python reference implementation of the ‘rev2’ update to the Oyster Protocol. The team focused on bringing every feature to a functional state (right now metadata works fine for any arbitrary number of files, along with data map generation, password protection, etc.) and documented every function and method using the same standard currently in place for the Oyster development team to improve readability.
The development team has been focusing on optimizing developer activities to increase efficiency and code quality. The team added automated code quality checks on Oyster’s central repositories, so developers have visibility/impact of their pull request on the code base. They also documented how to work with Travis CI locally to simplify debugging of build scripts and created and documented a TypeScript migration plan so the team can start adding types to our code. The team will continue working through the weekend to start boosting the team’s E2E tests. Finally, the team has been working on upgrading to Webpack 4.
Bibox Community Vote
For those community members not yet aware, PRL has been included in the Bibox exchange’s community vote. The top three projects will be listed, and there is currently a 400K PRL voting reward in place if PRL finishes in the top three. Votes are submitted using the Bibox Token (BIX). The reward will be distributed based on the total number of votes, as well as the individual votes per user (i.e., 400k/total votes * a user’s votes).
We ask our community to note that any BIX token used for voting will only be refunded if the project for which a user has voted for does not place in the top three, and subsequently does not win the community vote.
https://medium.com/oysterprotocol/june-29th-development-update-e3f27058f839
Today’s development update focuses on the work completed for the week of June 24th to the 29th.
This week the development team has continued to work on the jobs that use Oyster’s eth_gateway and interact with the Ethereum blockchain. The team finished QAing the claim_unused_prls task from the previous week and are now working on a new task called claim_treasure_for_webnodes. With this task, instead of immediately invoking ClaimPRL() when a Webnode has done the PoW and claimed a treasure, the team will add the claim to a table in the database and have a task run which will call methods needed to claim the PRL for the website owner. This way, if the first attempt to claim the PRL does not succeed, the broker node can keep trying until the PRL are successfully claimed. Also, for various bury/claim operations, the team has to send a small amount of gas to the affected addresses. Over time this could add up to a lot of wasted ETH if the bury/claim calls don’t use all the ETH that was sent. Thus, the team has added a method to retrieve leftover gas if there is enough left to justify making a new ETH transaction to get the leftovers, making the system more economical.
In addition, the team has continued to work on integrating a streamable module for the front-end to handle larger uploads. Additionally, the team has been working to establish engineering practices with the goal of increasing the development velocity and code stability. Furthermore, the team has continued work on the Badger DB integration and fixed several related unit tests that were failing, as well as worked on Code Climate refactoring and unit testing the changes for the next broker node release. Also, the team worked on automating the deployment of the broker nodes in a staging environment
Further work has been completed on the python reference implementation of the ‘rev2’ update to the Oyster Protocol. The team focused on bringing every feature to a functional state (right now metadata works fine for any arbitrary number of files, along with data map generation, password protection, etc.) and documented every function and method using the same standard currently in place for the Oyster development team to improve readability.
The development team has been focusing on optimizing developer activities to increase efficiency and code quality. The team added automated code quality checks on Oyster’s central repositories, so developers have visibility/impact of their pull request on the code base. They also documented how to work with Travis CI locally to simplify debugging of build scripts and created and documented a TypeScript migration plan so the team can start adding types to our code. The team will continue working through the weekend to start boosting the team’s E2E tests. Finally, the team has been working on upgrading to Webpack 4.
Bibox Community Vote
For those community members not yet aware, PRL has been included in the Bibox exchange’s community vote. The top three projects will be listed, and there is currently a 400K PRL voting reward in place if PRL finishes in the top three. Votes are submitted using the Bibox Token (BIX). The reward will be distributed based on the total number of votes, as well as the individual votes per user (i.e., 400k/total votes * a user’s votes).
We ask our community to note that any BIX token used for voting will only be refunded if the project for which a user has voted for does not place in the top three, and subsequently does not win the community vote.
https://medium.com/oysterprotocol/june-29th-development-update-e3f27058f839
A voting reward of 400K PRL has been added to the @Bibox365 community vote! Help get $PRL into the top 3 to receive the reward.
Good night, guys. Waiting for something above amusing here.
Excellence idea, in right mind logo!
Excellence idea, in right mind logo!
PRL is included in the Bibox community vote! Vote for $PRL here:
https://www.bibox365.com/cinformation?id=700
https://www.bibox365.com/cinformation?id=700
Check out this write-up on Oyster by @WPeaste:
https://bitsonline.com/oyster-protocol-storage-web-revenue/
https://bitsonline.com/oyster-protocol-storage-web-revenue/
Oyster $PRL is scheduled to be listed on BitForex! Trading will open at 11am HKT, June 26th, 2018 (11PM EST, June 26th, 2018). Initial pairing will be PRL/USDT, with PRL/ETH to be implemented soon after.
Nice
Nice
Mind blowing update on current features which are being developed or polished to increase their performance. You can talk more than many points from the whole update but I will draw attention of everyone on the last line which tells in-browser file view feature is under development alongwith other other stuff.
Oyster Development Update June 22, 2018
https://medium.com/oysterprotocol/oyster-development-update-june-22-2018-b6fcb5a54ad3
The development team has made further progress in optimizing the web node script. The previous web node build had a total size of 1.8 megabytes, which is a significant amount of JavaScript to parse through (this was an issue originally submitted by an Oyster community member). The development team has since taken this concern from the community into consideration and has managed to reduce that build to 575kb (a decrease of 70%). By reducing the size of the web node script, the response time for clients will be much shorter, as the necessary data to be downloaded client-side to run the protocol is now significantly smaller.
In addition, the development team has made significant strides in the Ethereuem-related functionalities of the broker nodes, as well as fixed bugs related to gas limits and nonces. Furthermore, QA has been completed on the bury_treasure_addresses task. This task does three things (and for the interest of our community, this post will include the Etherscan transactions that show this task in action).
First, the treasure is sent to a treasure address
(https://etherscan.io/tx/0x896b8d39ae6b1e89f8b931e5a6a49a12e33922c3d62290fc94b9b2c0582579db).
Then, a tiny amount of ETH is forwarded to the treasure address to be used as the gas for the bury() call
(https://etherscan.io/tx/0x54233b4b520bc7634475b786a2306727a5c7dbe737c939508db9550b56c1a2a9).
Finally, the eth_gateway method is invoked and calls the bury() method on the Oyster PRL smart contract
(https://etherscan.io/tx/0x0a7f9427d61e8a4040d5b428f0042996f1ea16a58c7baa23a0174b4b7be6c174).
The transaction ids provided detailing the bury_treasure_addresses task are examples created during testing; thus, the gas prices used in these transactions are relatively high to ensure the transactions are confirmed within a reasonable time frame. In production, these gas prices will be much lower. With the bury_treasure_addresses task working correctly in testing, the development team has moved on to testing the claim_unused_prls task, which will invoke some of Oyster’s eth_gateway methods so that the broker can retrieve any PRLs that were leftover and not needed for treasures.
The development team has also been working on finishing the design for ‘rev2’ and writing proof-of-concept code in Python to use as a reference implementation in other languages later on. The team has started on documenting how rev1 (the current build in production) works to support legacy clients in the future as well. ‘Rev2’ is an exciting future improvement to the Oyster Protocol, as it will give the protocol the capability to offer multi-file uploads in a single session to a single handle. Moreover, each file has the potential of having its own password that the user needs to remember on their own (completely optional feature) and also enables features like media streaming due to a change in how treasures are buried. The design changes in ‘rev2’ of the Oyster protocol will ultimately help wide-spread adoption of the protocol for commercial-grade data storage, as well as lead to a more favorable user experience.
The development team has also added a universal error page to the web storage interface which users will be rerouted to if an error occurs trying upload or retrieval of a file. Additionally, the team has continued testing the integration of Badger DB into the system and are actively working on solving some issues related to this integration. Further work has been completed on integrating a streaming implementation of file uploads to handle larger files. In conjunction with the broker node performance improvements of saving binary data outside of the SQL database, this streaming implementation will significantly help with scalability.
Finally, the team has been working on in-browser previews for Oyster files, and some small improvements on streamable have been made, most notably download progress can now be tracked and displayed visually.
https://medium.com/oysterprotocol/oyster-development-update-june-22-2018-b6fcb5a54ad3
The development team has made further progress in optimizing the web node script. The previous web node build had a total size of 1.8 megabytes, which is a significant amount of JavaScript to parse through (this was an issue originally submitted by an Oyster community member). The development team has since taken this concern from the community into consideration and has managed to reduce that build to 575kb (a decrease of 70%). By reducing the size of the web node script, the response time for clients will be much shorter, as the necessary data to be downloaded client-side to run the protocol is now significantly smaller.
In addition, the development team has made significant strides in the Ethereuem-related functionalities of the broker nodes, as well as fixed bugs related to gas limits and nonces. Furthermore, QA has been completed on the bury_treasure_addresses task. This task does three things (and for the interest of our community, this post will include the Etherscan transactions that show this task in action).
First, the treasure is sent to a treasure address
(https://etherscan.io/tx/0x896b8d39ae6b1e89f8b931e5a6a49a12e33922c3d62290fc94b9b2c0582579db).
Then, a tiny amount of ETH is forwarded to the treasure address to be used as the gas for the bury() call
(https://etherscan.io/tx/0x54233b4b520bc7634475b786a2306727a5c7dbe737c939508db9550b56c1a2a9).
Finally, the eth_gateway method is invoked and calls the bury() method on the Oyster PRL smart contract
(https://etherscan.io/tx/0x0a7f9427d61e8a4040d5b428f0042996f1ea16a58c7baa23a0174b4b7be6c174).
The transaction ids provided detailing the bury_treasure_addresses task are examples created during testing; thus, the gas prices used in these transactions are relatively high to ensure the transactions are confirmed within a reasonable time frame. In production, these gas prices will be much lower. With the bury_treasure_addresses task working correctly in testing, the development team has moved on to testing the claim_unused_prls task, which will invoke some of Oyster’s eth_gateway methods so that the broker can retrieve any PRLs that were leftover and not needed for treasures.
The development team has also been working on finishing the design for ‘rev2’ and writing proof-of-concept code in Python to use as a reference implementation in other languages later on. The team has started on documenting how rev1 (the current build in production) works to support legacy clients in the future as well. ‘Rev2’ is an exciting future improvement to the Oyster Protocol, as it will give the protocol the capability to offer multi-file uploads in a single session to a single handle. Moreover, each file has the potential of having its own password that the user needs to remember on their own (completely optional feature) and also enables features like media streaming due to a change in how treasures are buried. The design changes in ‘rev2’ of the Oyster protocol will ultimately help wide-spread adoption of the protocol for commercial-grade data storage, as well as lead to a more favorable user experience.
The development team has also added a universal error page to the web storage interface which users will be rerouted to if an error occurs trying upload or retrieval of a file. Additionally, the team has continued testing the integration of Badger DB into the system and are actively working on solving some issues related to this integration. Further work has been completed on integrating a streaming implementation of file uploads to handle larger files. In conjunction with the broker node performance improvements of saving binary data outside of the SQL database, this streaming implementation will significantly help with scalability.
Finally, the team has been working on in-browser previews for Oyster files, and some small improvements on streamable have been made, most notably download progress can now be tracked and displayed visually.
35 —💲 Getting paid to disable ads with Oyster Protocol CMO Chris Garner
https://podcast.hodldaily.com/48352ea5
https://podcast.hodldaily.com/48352ea5
Hello! Project Tokens can be purchased only for btc and ETH or for fiat, too, is possible?
Fiat gateway. Oyster Protocol will provide the option to buy storage directly with e.g. PayPal/Stripe. Oyster puts the PRL in place for the customer. Each upload is still paid in PRLs in the background.
Hello! Project Tokens can be purchased only for btc and ETH or for fiat, too, is possible?
NEW ROADMAP Exclusive:
Oyster_L517a40ea698dcf603a51a061d6a06ce42768fdb36d3559fe0665c4450c5c2926FtmcfEH Z
(https://www.oysterstorage.com to retrieve a file) or @pearlbot (telegram)
Oyster_L517a40ea698dcf603a51a061d6a06ce42768fdb36d3559fe0665c4450c5c2926FtmcfEH Z
(https://www.oysterstorage.com to retrieve a file) or @pearlbot (telegram)
It seems of this business will be preferably in the offing! Blameless idea, reasoned approach, riveting job!
That write up on storage on Oyster is very interesting and enhanced and polished my knowledge by arising other points and advantages of the protocol. Other development article also has spoken lot of things for near future. When you read every single write up or review you watch using other angles than traders. This is everywhere visible and here is too.
Quote
Exchange Listings
Oyster continues to aggressive pursue high quality exchange listings. We have signed a definitive agreement with a Top-20 volume exchange. We will have further information regarding the listing date and exchange after we complete technical testing. We plan to have additional announcements regarding listings later this month.
Oyster continues to aggressive pursue high quality exchange listings. We have signed a definitive agreement with a Top-20 volume exchange. We will have further information regarding the listing date and exchange after we complete technical testing. We plan to have additional announcements regarding listings later this month.
Quote
Exchange Listings
Oyster continues to aggressive pursue high quality exchange listings. We have signed a definitive agreement with a Top-20 volume exchange. We will have further information regarding the listing date and exchange after we complete technical testing. We plan to have additional announcements regarding listings later this month.
Oyster continues to aggressive pursue high quality exchange listings. We have signed a definitive agreement with a Top-20 volume exchange. We will have further information regarding the listing date and exchange after we complete technical testing. We plan to have additional announcements regarding listings later this month.
That is good news they are working continuously and trying to make it most trusted project. Listing on a new exchange will drive more traffic towards this token and it will catch attention of new investors. I would like to appreciate your efforts and wish you more success.
Amazing interview which clears team's dedication for mid to long term goals to get integration in more websites which are up to $1 million dollars revenue generators. When you read with little bit interest then it takes no time to realize things are 100% on track. Team is aware of the fact valuable tokens are key for larger adoption and that is what will come in future.
Jump to: