GIP-98: Should GnosisDAO invest in HOPR to kickstart development of GnosisVPN?

Hi - Harry from Nym here. Some of our users that are also on Gnosis told me about this. Of course, we’d be happy for Gnosis users to use NymVPN. We could build a dapp in gnosis that would allow to pay for the NymVPN using Gnosis - we already are working on supporting quite a few cryptocurrency payment options, so we’d be happy to add DAI and so on. It’s pretty easy to add so we wouldn’t need to request funds to do so.

It is odd that as soon as we launch a VPN for testing using our quite well-working mixnet infrastructure that HOPR decides to copy us - as usual - and then go ask for money for their own VPN. We have expressed concerns about the HOPR architecture for a long time:

Why we don’t support Gnosis for payments out the box is because of user privacy. We don’t use Gnosis Chain as our primary chain because we are Rust and WebAssembly based chain that needs the Web Assembly and validator support to use privacy-enhancing anonymous credentials to de-link the payment from usage of the NymVPN (see here https://nymvpn.com). . I would worry if any decentralized VPN was using Gnosis without sufficient privacy for payments, and so far, we seem to be the only ones doing that.

We would hope any decision could be made on the basis of technical merit. We aren’t against competition, but we do want people to realize why Nym made the decision to use Rust/WebAssembly and Cosmos for our primary chain and why we chose our particular technical architecture. The mixnet has worked well for years via Nym Connect via SOCKS5 (like Tor), and we’d encourage people from the Gnosis community our new NymVPN out - it opens for beta testing quite soon, but the code is already working and live in Github.

2 Likes

I find it really amusing how much effort you put into badmouthing the competition, if only that energy would go into something good :wink:

Anyway, I hope someone from the HOPR team answers all your concerns. But I think we should stay on topic here and discuss the original proposal.

2 Likes

Unlike other code that would require lots of development, the Nym mixnet works today without a million+ grant from anyone. Thus, the effort of Nym has made a working mixnet and we already have the code working for a VPN-like usage over a mixnet.

We take privacy seriously and wanted to make sure that people knew why we made our technical choices that are quite different from HOPR (or Elixxir or others) - I do not think payment over DAI is by default privacy preserving, unless you have shielded transactions on Gnosis already working similar to how Aztec works. Also, it would be relatively easy for us to add DAI and Gnosis chain support with our existing privacy tech. We thought the larger Gnosis community would be interested in this information even if you are not for whatever reason.

1 Like

It seems we have started off on the wrong foot.
My primary issue lies with the logistical inconsistencies presented. A funding sum of 1.5 million dollars appears excessively high for the proposed purpose.
While I understand your argument regarding competition, I propose a reformation of the proposal to highlight its altruistic intentions more clearly.
Despite this, due to the current logitsical discrepancies, my stance remains a vote against the proposal.
Edit: I see no proof of “bad mouthing”. Am only expressing my opinion on the matter.

klemenza, I believe that comment was solely pointed at Harry, as he has a history of such behavior. By all means, let’s continue with a healthy conversation. The Gnosis / HOPR partnership will continue to flourish well beyond this proposal because of integrity and aligned values. I am looking forward to the journey ahead.

3 Likes

Engagements of this nature should be strategically justified.

I completely agree with you on this central point and gladly take the opportunity to make the strategic alignment between Gnosis and HOPR clearer here.

From my perspective, it appears we are allocating 1.5 million to a product that is not necessary for our operations

Gnosis DAO is not primarily focussing on operations but on growth of the Gnosis ecosystem. I recommend this excellent blog and forum post by the Gnosis founders on that topic.

Despite HOPR’s long-term presence in the industry, the product has yet to demonstrate significant functionality.

That is not correct, you can try out RPCh.net - which relays Ethereum RPC calls via HOPR nodes - today. Please let me know if you run into any issues. Here are many examples of RPCh working well for people.

Upon reviewing LinkedIn, it’s evident that a majority of the team, including the primary founder and designer of the protocol, have departed from the company.

This is also incorrect. As is not atypical for startups and market cycles, HOPR has indeed downscaled and some people left, but I as primary founder as well as all senior developers are still on board (see GitHub links that I shared above). Apart from me there are currently 9 full time engineers developing HOPR, all of whom will be available to work on Gnosis VPN & HOPR should this proposal pass.

Binance was an initial financier of this venture. My concern lies with the possibility that Binance possesses a substantial quantity of HOPR tokens, which they may dispose of to avoid regulatory issues.

There are many holders of the HOPR token. All of them could sell, yes, that is a risk with any publicly traded token. We are happy to have received support from Binance (just as Nym did) but indeed we are looking forward to a tech world that is not just VC dominated but instead built on ecosystem collaboration and support. We have already begun this transition and want to pursue it going forward - hence leaning towards Gnosis chain as a self-proclaimed DAO chain.

Why not consider utilizing Privacy made simple - NymVPN 2?

Nym has decided to combine all solutions into one solution which is neither the approach of HOPR nor Gnosis. Nym is driving development of an L1 blockchain, a mixnet and a VPN product as one central player. The Gnosis ecosystem is made of independent projects (such as Gnosis Chain, Safe, CowSwap, Karpatkey, Gnosis Pay and many more) focused on discrete parts of the tech stack. That’s not Nym’s approach and that is fine but that is a major difference. Gnosis has not made a decision to move out of the EVM into the Cosmos world.

The founder has made references to RPCh. An examination of the relevant updates reveals code associated with this enhancement. In my view, 1.5 million is an excessive amount for such an update.

This proposal is not about RPCh but to generalize the initial work that we have and are still actively pursuing in the direction of RPCh for the much more general use case of VPNs. Yes, that work has already started but the completion of it is a very long process that is supported through the proposal that I posted here.

5 Likes

It is odd that as soon as we launch a VPN for testing using our quite well-working mixnet infrastructure that HOPR decides to copy us - as usual - and then go ask for money for their own VPN.

NymVPN does not seem to have launched, it cannot be downloaded and used as of this moment, the initial ongoing prototyping work does not seem to be completed. In addition, I refer to my answer above on strategic alignment with Gnosis and diversity of the technology stack.

We have expressed concerns about the HOPR architecture for a long time:

As we explained at the time, those concerns were based on a misunderstanding of how HOPR works, a misunderstanding which has only deepened as HOPR’s design has been further developed and improved. We tried to reach out via various avenues to explain and correct this, but were repeatedly ignored (and indeed blocked). It seemed reasonable to assume you aren’t actually interested in discussing this.

At HOPR we believe the web3 is a place for collaboration and mutually beneficial partnerships, that’s the spirit of this proposal. We want to deepen our support for Gnosis Chain - and the wider Ethereum ecosystem - to bring privacy to existing users.

I would worry if any decentralized VPN was using Gnosis without sufficient privacy for payments, and so far, we seem to be the only ones doing that.

Nym chose to combine a payment layer and anonymous messaging into one system. As outlined above, while we understand that approach it’s not the approach that HOPR has taken and not the approach that Gnosis has taken.

we do want people to realize why Nym made the decision to use Rust/WebAssembly and Cosmos for our primary chain and why we chose our particular technical architecture.

Again we understand your choice of building on Cosmos here but that’s not our design choice or Gnosis’. However, the EVM certainly does have shortcomings that I do not get tired pointing out.
Thus we wholeheartedly support Nym in bringing not just on-chain privacy but also WebAssembly to Gnosis Chain, and endorse any such efforts.

5 Likes

Hello everyone, yesterday we organized AMA with Sebastian and he answered a lot of question about GnosisVPN. Watch Twittter or YouTube

7 Likes

I was surprised by the pushback this proposal has received. Have you watched the Gnosis HOPR AMA?

I’ve been following HOPR for a while and have been impressed by their development along with their transparency and communication with the public. @SCBuergel in particular.

I fully support this proposal. I also think $1.5m is overly reasonable. They could have justifiable asked for more.

4 Likes

I think your skepticism is healthy.

How much additional capital is estimated to be needed to advance from a proof-of-concept to a finished product/shipped browser extension? What about agreements for ongoing maintenance & support? I think we need to consider the full financial outlay it would take to make this dream a reality.

1 Like

It’s true that these questions of funding and amount are important, so it could be a further discussion to say what the amount requested might be (a rough range?).

But I understand the desire and interest in making a VPN, especially with the GNOSIS brand.

With its transition, Gnosis wants to offer services and products with real utility and interest for the crypto community.

And I’m totally in line with this philosophy, so I can’t wait to find out more and see if this product can be developed to expand the Gnosis range of services/products

1 Like

We deliberately did not ask for a large upfront sum with an upfront full-scale project plan because we do not want to fool GnosisDAO into thinking that such huge projects would ever work according to a non-agile multi-year development plan. Instead, we carefully considered what we are certain we can deliver within 9 months - and maybe we can go beyond that. So a next step depends on exactly how far we get, how the landscape looks like at that point in time and what reasonably makes sense to develop next and which target platforms, user groups and use cases should be tackled. Especially on the commercial questions we are very much looking forward to more discussions and feedback from the community at the time of the second proposal.

Since some questions in this direction came up I find it important to highlight that all work that we undertake at HOPR is free and open source with permissive licenses. As such, even the initial work that is already now ongoing to generalize RPCh to more general purpose usage, is already all in the open. So if HOPR does not deliver, is going over budget or ceases to align with the Gnosis ecosystem, there is absolutely nothing stopping another team from taking over the work that we did.

3 Likes

I wanted to also take the opportunity to highlight the decentralized nature of the HOPR network which shows another angle of alignment between HORP and Gnosis and which is a value proposition of onboarding HOPR node runners as Gnosis validators. We created this Dune Dashboard that highlights that there’s only 2 HOPR Safes with more than 10 connected HOPR nodes and only 10 run more than 1 HOPR node.

I think that is a significant difference from many other projects in the ecosystem in that HOPR nodes are operated by individuals and not professional node operating corporations. Many of HOPR nodes are running on DappNodes out of their operators’ homes, thanks to our partnership with and custom branded HOPR DappNode devices.

2 Likes

Thank you for your responses. I must express, however, my remaining scepticism.
Upon reviewing the codebase, the associated costs seem unjustifiable. Though I prefer to remain unnamed, I can evaluate this matter accurately.

I propose the following adjustments:

  1. The total cost should be reduced to $500,000
  2. Implement a milestone-based funding model, wherein funds are disbursed upon achieving specified benchmarks

Nevertheless, I anticipate that these suggestions may be overlooked, as this has been my experience with DAOs in the past, sadly.

1 Like

Thanks for looking at our code - that’s what FOSS is about and I’d appreciate specific feedback. It would help me to respond to you if you made your criticism explicit. Are you saying “your code looks so poor that it’s not even worth the $1.5m of this first proposal” or “you basically did 90% of the work that’s needed for this first milestone of Gnosis VPN and only have like 3 man months of work left and hence $1.5m is too much”?

As outlined in detail in the OP, I absolutely agree with your notion of milestone-based payouts and that’s exactly what we suggest here in this proposal.

1 Like

From my analysis today, it appears that the majority of the tasks associated with GnosisVPN have been successfully completed, with only minor discrepancies remaining.

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 must apologize if my scrutiny seems excessive. However, I believe the funding requested exceeds the necessary amount. In line with the principles of DAOs and the ethos of cryptocurrency, we should adhere to the maxim: Don’t trust, verify.

Edit: Additionally, can you specify the milestones you are referring to? The proposal seems vague in that aspect. What is the value given to each deliverable? Or is the grant given up-front?

1 Like

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.

As a noob, I would like to know what would be the implications of exit/entry nodes with people using the product with their already KYCed addresses on Gnosis Pay with this product?

I know the PoC is supposed to provide limited access to certain endpoints to help out with privacy. However, as all the people who have signed up for a Gnosis Card provided their KYC info to Fractal, and Gnosis Pay, and most probably Monavate also having access to this info as well, I am curious to get an insight on the implications of what a decentralized VPN network powered by HOPR node runners in terms of prejudicing the user’s privacy (especially if the node runner is using the same credentials/IP/or whatever you wish to call it is known by regulatory bodies or poor opsec by the node runner).

Would it pose a risk to the node runner as being KYCed, would it pose a risk to the user with a KYCed address, would it pose a risk to the entire network due to the failure of either?

EDIT: I do think we need a decentralized VPN solution and this is one of the proposals that got me excited on Gnosis 3.0/consumer product oriented roadmap!

3 Likes

That’s a very good - and non-noob - question! Let’s dissect it:

First of all, what are the implications for entry and exit nodes? Entry nodes see the end-to-end encrypted metadata of the traffic. So the entry node which is directly in contact with a user of course sees that user’s IP address and metadata such as the size of requests and reponses they send. The latter can be partially mitigated by sending data via multiple entry nodes. In fact, HOPR is designed to make the switching of routes very efficient, to provide decrease the necessary trust in individual entry nodes.

The exit node, on the other hand, has no way of knowing the user’s metadata, so specifically they don’t see the user’s IP address. But the exit node makes the actual requests and sends back the responses so that webserver sees the websites that are being accessed, but they don’t see from who, so the exit node does not see the IP address or other metadata and is specifically also not able to link individual requests to the same user.

Thus, if you are concerned about your KYC-ed identity being linked to your web-browsing activities, Gnosis VPN should be able to better protect you against de-anonymizing of your traffic than other means. The only exception is of course if the entire chain of nodes all collude (including entry and exit nodes and Gnosis Pay KYC providers) - but there’s really no system that could protect you against that.

I’m very happy to hear that Gnosis VPN makes you excited about the Gnosis 3.0 roadmap - we see the same!

2 Likes

This proposal is now live for voting on Snapshot.

3 Likes