|
denam
|
 |
June 16, 2018, 05:50:55 PM |
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
If you see garbage posts (off-topic, trolling, spam, no point, etc.), use the "report to moderator" links. All reports are investigated, though you will rarely be contacted about your reports.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
|
TonyBons
Newbie
 Offline
Activity: 16
Merit: 0
|
|
June 18, 2018, 07:01:58 AM |
|
It seems of this business will be preferably in the offing! Blameless idea, reasoned approach, riveting job!
|
|
|
|
|
|
ToTheMoon_XOM9IK (OP)
|
|
June 18, 2018, 06:40:09 PM |
|
NEW ROADMAP Exclusive: Oyster_L517a40ea698dcf603a51a061d6a06ce42768fdb36d3559fe0665c4450c5c2926FtmcfEH Z ( https://www.oysterstorage.com to retrieve a file) or @pearlbot (telegram) 
|
|
|
|
|
|
Naes
|
|
June 19, 2018, 11:38:33 AM |
|
Hello! Project Tokens can be purchased only for btc and ETH or for fiat, too, is possible?
|
|
|
|
|
|
ToTheMoon_XOM9IK (OP)
|
|
June 19, 2018, 08:18:46 PM |
|
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. |
|
|
|
|
|
|
|
ToTheMoon_XOM9IK (OP)
|
|
June 22, 2018, 07:22:17 PM |
|
Oyster Development Update June 22, 2018 https://medium.com/oysterprotocol/oyster-development-update-june-22-2018-b6fcb5a54ad3The 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.  |
|
|
|
|
|
denam
|
|
June 23, 2018, 07:16:26 PM |
|
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.
|
|
|
|
|
|
|
|
ToTheMoon_XOM9IK (OP)
|
|
June 25, 2018, 05:36:23 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.Nice
|
|
|
|
|
|
|
|
|
PhillipH
Newbie
Offline
Activity: 24
Merit: 0
|
|
June 29, 2018, 04:10:01 PM |
|
Good night, guys. Waiting for something above amusing here.
Excellence idea, in right mind logo!
|
|
|
|
|
|
ToTheMoon_XOM9IK (OP)
|
|
June 29, 2018, 05:32:14 PM |
|
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. |
|
|
|
|
|
ToTheMoon_XOM9IK (OP)
|
|
June 30, 2018, 08:10:09 AM |
|
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 VoteFor 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 |
|
|
|
|
|
pumz
|
|
June 30, 2018, 08:53:48 AM |
|
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.
|
|
|
|
|
|
|
|
|
|
ToTheMoon_XOM9IK (OP)
|
|
July 06, 2018, 09:05:53 PM |
|
Development UpdateToday’s update will focus on the work completed between July 1st — July 6th, 2018. This week, the development team finished up treasure index hashing. The treasure index of a sector is now chosen by hashing the average of the indexes selected by the alpha and beta node. The hash ensures that the treasure index is genuinely random within the sector. In addition to the hashing function, the index selection method now supports variable sector size and has guards to ensure the treasure index is valid. The team has also started working on production database migrations. Additionally, the team continued to QA ETH/PRL transactions triggered by the broker node, made small fixes, and updated unit tests. The development team is now at a stage where they can test the web node ability to claim real PRL on the Ethereum mainnet successfully. For example, this transaction was the result of a web node submitting a claim to a broker node: https://etherscan.io/tx/0x73dd4c3a2b7d1daa14c0c2a8bc92f9daffc98256e89bc0ee46d784d4aa30e8a0. The team completed QA on the BadgerDB integration, as well as cleaning up some issues with the unit tests for the broker nodes. Furthermore, the team has been working diligently on fixing Code Climate issues, ultimately leading to a more standardized code base. By using Code Climate, the team can set coding standards for engineers to help keep the code base healthy while the team grows. The team has also been looking into tooling to help engineers configure and setup testing/staging environments efficiently and reliably so that the QA process is more automated and easier to perform. In addition to the above improvements, the team is finishing up integrating streams for file uploads and will begin working on streams for file downloads. This is intended to allow users to upload or download large files in the browser while being memory efficient. Finally, the team worked on upgrading the web node from Webpack 3 to Webpack 4 and all dependent development libraries to the latest versions and worked on porting to and installing Typescript on the web node. Typescript will allow for strongly-typed JavaScript (i.e., explicitly declaring a variable type as a string, integer, etc.), which will improve Oyster’s coding standards and enhance security within the code base. Development Goals for the Following WeekBelow are a few of the improvements the Oyster development team will be working on in the following week 1. Continued focus on size/speed improvements 2. First design steps of a public api/client lib — the Oyster development team believes an API that other people can consume is needed for adoption. This will be a building block for how everyone, including Oyster’s internal services, upload data and also a building block for higher level wrappers. The team believes in the future the bulk of our storage will come from API users, not necessarily Oyster’s official storage interface. 3. Continue improving development tooling/process — cleaner code, more code coverage with testing, more end-to-end tests. https://medium.com/oysterprotocol/july-6th-development-update-1eb1f85d7787
|
|
|
|
|
|
