Topic: [ANN]🔵🔵 OYSTER 🔵🔵 Anonymous Storage Generates Revenue for Websites - page 41. (Read 73428 times)
June 25, 2018, 01:26:21 PM
We are getting nice chances to pick this token at cheap price even development progress is very impressive. This is good news soon another exchange will open this market this is nice job done by dev. I hope this project will get more success.
June 25, 2018, 12:54:34 PM
Bill Cordes:
Quote
As a heads-up, this is not the exchange I alluded to last week
So there's another Top 20 still in the works
So there's another Top 20 still in the works
June 25, 2018, 12:32:53 PM
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.
June 25, 2018, 09:18:10 AM
Oyster team is coming out with very good updates in development which need to more explanation as reader automatically can judge the project based on the work. This is true we are caught in a phase where markets are tumbled but this isn't the end. Oyster team is doing work without caring of the price or response which comes immediate and is temporary.
The Oyster team is different from any other team I am observing, they have an incredible dedication and passion for what they are doing. And most importantly, they are not about talking but delivering. Almost any roadmap has been met with laser precision. There were some slight delays with the main net but that was rather due to IOTA not being ready and so the team had to improvise and find a workaround. And they did in a remarkable period of time. I life my hat for what they have achieved so far and the price is just a reflection how absurd this market can seem, not at all is it just to the project and stage they are in.
June 25, 2018, 06:39:37 AM
Oyster team is coming out with very good updates in development which need to more explanation as reader automatically can judge the project based on the work. This is true we are caught in a phase where markets are tumbled but this isn't the end. Oyster team is doing work without caring of the price or response which comes immediate and is temporary.
June 25, 2018, 12:16:16 AM
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.
Very nice update, i was in withdrawing my support to the oyster pearl but as this news comes out. I was lose for a long time because of uncomfortable market and i sold some of my tokens lately. Now i am finding some projects which i can trust its long mid term to long term roi. This announcement is so great and in timing for me. 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.
Agree. I am very happy that team shows us their progress regulary. Hope the PRL price will recover soon
June 24, 2018, 09:48:47 PM
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.
Very nice update, i was in withdrawing my support to the oyster pearl but as this news comes out. I was lose for a long time because of uncomfortable market and i sold some of my tokens lately. Now i am finding some projects which i can trust its long mid term to long term roi. This announcement is so great and in timing for me. 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.
June 24, 2018, 05:23:53 PM
It's a crypto trade is very nice. Very nice design, blameless business! Good luck guys.
June 24, 2018, 02:55:46 PM
At this point there is no reason to go further, from what I understand Oyster has plenty of benefits and those benefits are the reason why it can survive. I’m just saying that giving more money than ads isn’t one of them. For 1000 visits you make in the dollar amounts of ad revenue. Those visits cost almost nothing in electricity, and therefore I make almost nothing in PRL.
Already answered
Quote
For 1k visits you are making a dollar? You are speaking of uniques, right? Where do you have that number from? That's also depending on the ads your are getting on your website. You can't simply "chose" to make such money.
June 24, 2018, 02:50:08 PM
At this point there is no reason to go further, from what I understand Oyster has plenty of benefits and those benefits are the reason why it can survive. I’m just saying that giving more money than ads isn’t one of them. For 1000 visits you make in the dollar amounts of ad revenue. Those visits cost almost nothing in electricity, and therefore I make almost nothing in PRL.
June 24, 2018, 12:58:10 PM
When you verify these transactions and look at the details and then return to remaining content of the update it gives you real understanding of the progress that what has been done. At start I just read and couldn't understand but with the help of these proof of transactions it became clear.
June 23, 2018, 03:30:27 AM
This is very good achievement by successfully reducing the web node size to increase the response time and make the whole process faster and more efficient. After launch of main net we are in a phase where enhancement in capacities and capabilities and efficiencies is next. We need to stand by the team to let them improve and upgraded where they think is necessary.
June 22, 2018, 03:13:26 PM
Yes, at least a stock exchange of the first two-bit, but then I think not to average once again on prl, we can not find the bottom in any way. Need more exchanges, volumes, liquidity, and most importantly new holders and traders.
June 22, 2018, 02:31:04 PM
The team is working awesome I feel nice to read to latest update as like they are making progress and implementing nice features to make it user friendly and make it more useful. They are bringing comfort for people to use this like normal tool. I think this is good achievement for this project.
June 22, 2018, 02:21:42 PM
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.
June 22, 2018, 01:47:03 PM
Who understands the potential just buys to reduce the cost of token after picking up at various price levels. Price in cryptocurrencies changes in matter of minutes upon good announcements. For me development and team is important because price will automatically follow the demand once it reaches at some good utility level.
June 22, 2018, 11:29:18 AM
One thing which everyone should keep remember about Oyster is they have connected blockchain technology with traditional for this platform. Project is still at early stage that's why people aren't catching the idea but when fiat gateway will be fully integrated and functional with goals in pipeline it will be available in clearly visible shape.
Maybe they need partners or a bigger community than ever before. Oyster's service is under construction and it will be up against Google, Microsoft, Apple, Dropbox. When Oyster is more popular and valuable, users will find Oyster. User experience is important, they are people like them willing to spend money to own a good service and easy to use. June 22, 2018, 07:19:44 AM
Good morning, all! I have reviewed all the details of your idea and everything is actually very good!
June 22, 2018, 06:39:16 AM
I am always confident and optimistic that the future of PRL will continues to improve, I do not regret even buying with expensive price of more than 8000 satoshi and now the price now drop and not more than 3000 satoshi.
June 22, 2018, 03:38:49 AM
One thing which everyone should keep remember about Oyster is they have connected blockchain technology with traditional for this platform. Project is still at early stage that's why people aren't catching the idea but when fiat gateway will be fully integrated and functional with goals in pipeline it will be available in clearly visible shape.
Maybe they need partners or a bigger community than ever before. Oyster's service is under construction and it will be up against Google, Microsoft, Apple, Dropbox. When Oyster is more popular and valuable, users will find Oyster. User experience is important, they are people like them willing to spend money to own a good service and easy to use. Jump to: