Open lilyannehall opened 7 years ago
amiller
commented
7 years ago This project looks cool! Since the proposed budget is $80k, this would possibly exclude funding any other proposals this season. Would it make a meaningful impact on your project to receive a smaller budget?
lilyannehall
commented
7 years ago @amiller thanks! In terms of impact of a smaller budget for the milestones laid out, it would be a matter of trading time/focus. This project is very important to us and the motivation for the proposed budget is to ensure that our small team can hack full time for 4-6 months without having to seek other employment options and deliver on our timeline. I realize it might appear self-centered to request the entire sum and to that extent we would certainly be grateful for any amount that might be granted - it would just require an adjustment to the expectations regarding delivery timeline (for both the foundation and ourselves).
tromer
commented
7 years ago Can you say more about the Zcash integration? For example:
It's fine if some of these aren't known yet, but please do share your thoughts about the goals and the design space.
lilyannehall
commented
7 years ago @tromer sure!
Objects stored in ORC decay over time intentionally. To prevent decay, "owners" of the data must periodically issue an audit challenge (see protocol spec) for a given shard every 72 hours (arbitrary scoring interval we will be playing with). This is to encourage symmetry with nodes on the network - everyone provides and everyone uses. This is a type of proof of work as periodically objects must be downloaded and new challenges must be generated. This process earns users reputation (soft consensus within local kademlia neighborhood). Good rep earns you access to more usage allowances, so the idea is to create an incentive to both utilize and provide capacity. However, this model doesn't apply well to long-term archival storage or clients on phones or laptops that do not have reliable availability. In these cases, issuing a Zcash payment can be performed instead of participating in the cooperative auditing. The goal, long term, is to leverage the upcoming sapling upgrade to establish micro payment channels (via semi-trusted hubs) to perform the necessary "heartbeats" on shards.
Each shard has a corresponding contract, which includes a fundingDestination - a unique z_addr that keeps it from decaying if the contract's fundingAmount and fundingInterval match the transaction history. In terms of UX, the plan is to have ORC automate this process by providing a wallet that can be topped up and pays out utilized providers on its own. When funds are drained, clients should revert back to standard shard audits and provide notification to the user.
User experience for thin clients is unknown right now and we haven't given much thought yet to ways to delegate trust for issuing payments or audits, but it's something we have considered and know we'll have to solve if we want to see wider adoption.
Hope this helps answer some of your questions!
tromer
commented
7 years ago @bookchin Thanks, that's very helpful. It would be good to have more details written down in the upcoming weeks, to help our technical assessment of the approach.
What are your plans regarding a detailed protocol specification, fleshing out these ideas and their security aspects? Where does this happen during the proposed schedule?
lilyannehall
commented
7 years ago Currently, the protocol specification and 2 improvement proposals are implemented but, to your point, there is not a formal document detailing the integration of Zcash; the system is designed to be token-agnostic.
I joined the Sapling Working Group some weeks ago to begin getting a better understanding of the status of that work for the very purpose of authoring an improvement document specific to the implementation of Zcash, but admittedly have been more focused on getting the underlying auditing, proofs, and reputation in place.
Now that those parts are nearly complete, the next steps are to publish a pre-release sans-payments of orcd and ORC Desktop this week (fingers crossed) to start testing the reputation system in the wild and iterate on issues identified through December, where we intend to roll out an official beta (also sans-payments).
Following the release of the official beta, my focus will be set primarily on Zcash integration, while Ryan is full force on UX for ORC Desktop, and Jeff works with the HRF and other organizations to start designing additional features specific for journalists (perhaps even integrating with SecureDrop).
Because our timeline is pretty aggressive near-term and the Sapling work (based on my perception) is still a little ways out from being ready for us to leverage, we haven't spent a great deal of time on the nitty gritty details of how zcash payments will be integrated, but we have started the conversation.
That said, I know that these missing details are important for the board to make an informed decision. The goal, initially is to keep things simple and not wait until Bolt payment channels are fully implemented before integrating Zcash, instead just starting out with simply issuing regular zcash transactions to providers during the currently implemented audit routine and iteratively upgrade this to using Bolt as that work progresses.
I would love to be able to satisfy any and all questions and/or unknowns that I reasonably can, so in pursuit of that it would be helpful to me if there were some specific action items for us regarding the documentation topics you all would like to see in the short term and we will do our best to try to flesh them out alongside the work we are doing now.
tromer
commented
7 years ago Here's what's crucial to add, in the proposal.
Technical approach for the Zcash integration: what are the goals? design considerations? tentative approach?
(I won't get into detailed design considerations at this point; but yes, it sounds very reasonable for the first implementation to use vanilla Zcash transfers.)
Schedule: right now it contains just 4 words that are relevant to the Zcash integration per se ("Zcash payments integration completed"). When does the design happen, and how? What are the implementation milestones?
Likewise, the evaluation plan says nothing about Zcash integration. What's within scope for this integration and how will we know if it's successful?
lilyannehall
commented
7 years ago @tromer Thanks so much for your consideration of our project. At the last working group meeting, we discussed the integration of Zcash again in some depth to try to nail down answers to some of the missing things that have been requested.
As it turns out, we unanimously decided that we are not ready to take on the integration yet and as a result, we must rescind this proposal. You can read the details of that discussion here.
amiller
commented
7 years ago Just wanted to thank you for setting a good example of participation, definitely looking forward to a future proposal. (Also, I love the link to your discussion minutes posted to a git repo :)
tromer
commented
7 years ago I second @amiller. And the ORC discussion on this is fascinating!
ORC is a peer-to-peer network of computers that coordinate anonymously over Tor to allocate their unused hard disk capacity into a collective, secure, and uncensorable cloud. Users gain reputation by cooperatively auditing each other, which in turn gives them access to more space than they can share and allows them to be rewarded with ZEC.
Files are encrypted on the user's computer, shredded into smaller chunks, and then stored on many different computers around the world! Efficient redundancy strategies enable data to be recovered in the event of network outages.
ORC is completely decentralized, meaning that no single company or organization has control of your data, only you!
Motivation and Overview
There are a handful of distributed storage projects today (Sia, Storj, IPFS - to name a few). However, none of them are designed to protect the identity of users, which greatly limits their application for sensitive or controversial content. ORC provides a completely decentralized storage network that leverages Tor hidden services to provide sender/destination anonymity and plans to introduce Zcash as a complementary reward mechanism to it's existing "get what you give" reputation model.
The ORC project aims to provide journalists, whistle blowers, political dissidents (and regular folks too!) with a means for safely and anonymously disseminating content publicly or privately. Storage providers have plausible deniability as custodians of data and are unable to inspect the encrypted shards of which they have custody.
The desired impact is to make anonymity and resistance to censorship the baseline for object storage on the internet - especially for those who need it most.
Technical Approach
The ORC network is functioning today and aims to officially launch a public beta by the end of 2017. It builds on years of my work on the Storj protocol in production, but brings anonymity, completely eliminates dependency on centralized services and infrastructure, and re-aligns broken incentive models for participating.
More technical details can be found in the protocol specification, developer documentation, improvement proposals, and the source code!
Team Background and Qualifications
Gordon Hall
(AKA @bookchin) is a distributed systems hacker. He is the author of the ORC protocol and it's underlying Kademlia implementation. Prior to ORC, Gordon lead engineering teams at Storj Labs and BitPay.
Ryan Foran
(AKA @MrFancyMonocle) is a programmer who likes tacos; he's previously worked on BitPay's and Storj's web applications.
Nathan Ginnever
(AKA @nginnever) is an Ethereum developer that has volunteered for the IPFS javascript project as well as Zcash GPU mining software. He is the founder of blockEDU free and open education platform.
Evaluation Plan
Every node in the ORC network simultaneously acts as a directory, keeping track of peers that are online, how much storage capacity has been allocated and is available for use, and keeping a reputation score on other peers based on the results of cryptographic audits on shards those peers are storing.
In the sense of quantifiable metrics, these are good indicators; how many nodes are online, how long have they stayed online, and are they being utilized? We are already beginning to track some of this information!
Security Considerations
ORC Desktop ~ships~ will ship as a cross-platform desktop program that anyone can install and start using. No technical skill is required to stay anonymous and secure.
Zcash is not a requirement for keeping content online, but rather one of three mechanisms:
We would like to see ORC be the first large scale use-case for Zcash.
Schedule
So far, we are on track with our 2017 roadmap:
August 2017
September 2017
November 2017
December 2017
April 2018
Budget and Justification
We operate on a tight budget and our team has not drawn any personal compensation from the fundraiser or from our non-profit (501c3) hackerspace which is providing sponsorship for the project, allowing ORC to except tax-deductible donations.
What we are seeking now is time and flexibility to enable our small team to work on ORC full-time through the implementation, testing, and roll-out of the Zcash integration and production release of the project out of beta by Q2 2018. $80,000 would allow our small team to focus 100% of it's efforts towards realizing these goals through the end of April 2018.
This would also provide us more time to strengthen our existing relationship with the Human Rights Foundation, and help on-board similar organizations to using the platform, which could give us more funding options beyond April of next year.
Thank you very much for your consideration, @orcproject