From my analysis today, it appears that the majority of the tasks associated with GnosisVPN have been successfully completed, with only minor discrepancies remaining.
Thanks again for digging into the code and the proposal this deeply - that’s something I rarely see in DAOs but as you mention, that is extremely valuable to ensure funds are not misappropriated.
As you have mentioned in earlier comment, RPCh is already operational: GitHub - Rpc-h/RPCh: RPCh is the only private RPC provider. Uses HOPR under the hood.
Correct, but that has almost nothing to do with the proposed work here.
Deliverables 1.2 and 1.3 have been met (90% there), given that RPCh encompasses similar functionalities, albeit with different endpoints on the exit-nodes
Generally, the intent of this work is to not just provide short-term gains and PoC, but actually a sustainable product development plan which seeks to bring Gnosis VPN as a viable product to a significant market - in line with the Gnosis 3.0 setup. That is important to understand as, indeed, we could make a quick & dirty first version of pHTTP and Gnosis VPN that would never be rolled out in production. But the goal here is actual product development. RPCh has comparatively tiny payloads compared to what you would typically utilize within the use of a web browsing setup.
Thus, the assumption of deliverables 1.2 and 1.3 being 90% there is incorrect. The current version that is in the repo which you also refer to in your next point is utilizing a relatively simple specific purpose solution built for the Ethereum RPC standard only. For example, the setup cannot handle websockets, additional HTTP header fields or other HTTP verbs. That means the entire architecture of this extremely opinionated and non-optimized form of the protocol needs to be overhauled from the ground up. That is deliverable 1.1 which then gets implemented in deliverable 1.2.
As the entry/exit node behavior changes with these additional requirements, entry and exit nodes also need to be reimplemented. This also needs to be tested wrt performance as I expect some large payloads to not get delivered within a timeout window. Beyond per-resource performance assessments, we also need to consider network-wide load assessments to judge which websites and services are in scope of the allow-listed first version of Gnosis VPN which is in scope of this proposal for the first PoC.
The RPCh code has been relabelled to GitHub - hoprnet/pHTTP-lib: p(rivate)HTTP library, which seems to represent the CORE code in RPCh
To be precise we started extracting and generalizing the core of RPCh which should present the basis for the Gnosis VPN work into a separate library. RPCh will become a user of that library, therefore this isn’t a simple re-branding and presents only the first step before we start re-designing and re-writing this for the much larger capabilities of Gnosis VPN compared to the specific purpose use case of RPCh.
The remaining objectives include developing the front-end and enhancing the performance of HOPR, which I would argue the former is out of scope, but given Gnosis Ventures initiative, I find it acceptable.
I don’t understand why a front-end - without which the proof of concept is entirely unusable for normal users - would be considered out of scope. We normally focus on making tech as approachable for end-users as possible and Gnosis does too.
Edit: Additionally, can you specify the milestones you are referring to?
The deliverables 1.1 - 1.5 culminating with a release of a proof-of-concept version of Gnosis VPN is the first milestone. Further milestones would be subject to an additional Gnosis DAO proposal.
What is the value given to each deliverable? Or is the grant given up-front?
We would prefer upfront payment.
Finally it is important to point out that this proposal is not a grant. Gnosis DAO is not just sponsoring product development work but is receiving a significant value worth of HORP tokens on top of the product development work.