OrchidTechnologies / orchid

Orchid: VPN, Personal Firewall
https://www.orchid.com/
GNU Affero General Public License v3.0
652 stars 103 forks source link

Running a Node #49

Closed 8ball030 closed 4 years ago

8ball030 commented 4 years ago

Hi Guys, Really like the project, I would love to get involved and support the ecosystem.

How do I go and run a node? There is no documentation I can find at all. Ive spent about 30-45 minutes just looking for a quick start guide so I can share some of this delicious unlimited bandwidth I have.

8ball030 commented 4 years ago

So is this project like dead or something?

jsclary commented 4 years ago

That's a good question and, unfortunately, I don't know the answer to it.

All I can tell you is that if you look in srv-shared, the README.md there tells you some of the prerequisites and how to properly check everything out including all the submodules. It's probably best to build from pkg-lnx with "make deb" or "make rpm" which uses docker and sets up a proper build environment as the prerequisites in the srv-shared/README.md won't be sufficient on all distros. I actually installed additional dependencies (build-essential, clang, rust, bc, libstdc++, docker) and built successfully according to the srv-shared/README.md before I noticed that

I've installed the .deb file and there's a man page and "orchidd --help" output which are both limited to a very basic description of each command line option and no mention of the /etc/orchidd.conf options. I'm not clear on how to configure and run it correctly so I came here looking to ask much the same question as you.

dereksilva commented 4 years ago

Hey folks, thanks for having an interest in being a bandwidth provider. The node software is still in active development and testing with the first set of partners (PIA, Boleh, LiquidVPN, etc.).

They're actively providing feedback on the software, and working with us to make it ready for general availability. Right now the focus is on the iOS and macOS apps, but the team's attention can turn back to the node software after those launch (unless another priority pops up).

In the meantime, you can continue to poke around the node software on GitHub, but we can't offer any documentation or support at this time since things are still changing so quickly. You are welcome to try installing it on your own machine but we can’t provide support at this time.

You could also take a look at the partnership with Bloq and explore participating in their node.

ghost commented 4 years ago

Hey folks, thanks for having an interest in being a bandwidth provider. The node software is still in active development and testing with the first set of partners (PIA, Boleh, LiquidVPN, etc.).

They're actively providing feedback on the software, and working with us to make it ready for general availability. Right now the focus is on the iOS and macOS apps, but the team's attention can turn back to the node software after those launch (unless another priority pops up).

In the meantime, you can continue to poke around the node software on GitHub, but we can't offer any documentation or support at this time since things are still changing so quickly. You are welcome to try installing it on your own machine but we can’t provide support at this time.

You could also take a look at the partnership with Bloq and explore participating in their node.

So ... You work on and release the front-end first (iOS / Android for end-users) then back-end?!!

saurik commented 4 years ago

So ... You work on and release the front-end first (iOS / Android for end-users) then back-end?!!

OK, so, for starters... even if it weren't the case that different people were doing all the recent work on the client from the server (which calls into question any attempt to post hoc rationalize any kind of "priority" between the two), I will argue that would be the correct strategy: get working clients so you build up some level of confidence in the stability and chosen functionality of the server at scale before trying to encourage lots of people to run it (at which point you can no longer upgrade it as easily and start having to add more and more workaround and transitional behaviors to the client).

This just isn't at all strange? Like, I feel like this is the trajectory of just about every "important" network protocol. I guess maybe it is strange "for a blockchain project", where you often think of the backend as forming some kind of network that clients consume, and no one cares that much about intrinsic value? FWIW, Orchid is not a blockchain project: it is a client/server network protocol with a decentralized directory and market that happens to be implemented on someone else's blockchain project (combined with some shareable technology for what some people would call a "layer 2" nanopayments system).

This thread then just in general feels a bit broken :(. Particularly, it feels needlessly hostile? Like, to unpack how this thread started, that first week of May was really really busy at Orchid: a quick spike in the price of gas on Ethereum combined with a long-term trend in the price of OXT led to a market-level coordination problem between our clients and our servers, with existing Orchid accounts not having sufficient deposit to effectively amortize payments to the servers, which necessitated prioritizing UI updates that detected this and encouraged users to add more money to their accounts.

In "response" to this, we had a provider partner providing bandwidth at a loss (due to Ethereum transaction fees); this is not a moment during which you either have time or even want to be bringing on even more servers. But then, when I came back to this thread a week later, it had started to feel kind of pointless to reply... "so is this project like dead or something" on a project with a continual and rich git commit history and which was even publishing public releases to update its software clearly isn't a project that is "like dead or something", so the entire thing just starts to feel like trolling for a response :(.

Honestly, even this last comment... I'm not against issues and comments that are slightly hostile (hell, I'm guilty of this at times), but they have to be a bit constructive, right? I definitely disagree with the thought (and have now defended why), but if you are going to emphatically "?!!" some kind of comment you should probably give some kind of defense or argument for what you think should be happening and why? This is the kind of comment I honestly think is often a bit better to ignore (in order to not encourage more such comments), but in addition to "you finally trolled me into responding" I think I see the pattern!

So, thinking about this with some fresh eyes today, I finally think I have figured out the "problem": this thread isn't actually a developer-level issue in the first place :(. There is just no "bug" here... this is, much more realistically, a request for user-level customer support filed as an "issue" on the bug tracker for our codebase. There is then an expectation that we are prepared to provide user-level customer support, but we simply aren't (yet): you are experiencing a part of an open source project that is still being developed and for which providing user-level customer support would not really help anyone :(.

For starters, it is kind of a waste of effort: as Derek said, a lot of this stuff is in a massive state of flux; like... the hardest part of running an Orchid node right now is the weird OpenVPN requirement; and so, I'm working on removing that entirely, rather than either documenting it or trying to make it easier, as it isn't even what we want in the architecture anyway! We also have realized that there are some "sharp edges" to our directory contract that make it too easy for someone staking to "fat finger" their way into losing money (this isn't a bug, to be clear; but we should introduce some higher-level interfaces).

But like, taking a step further back--and tying this into the question of "why are you working on clients"--if asked the question "why do you want to run an Orchid server, today?", the answers (other than "I found a bug in the client I want to sit around and debug", in which case you are reading the code...) don't really "work": essentially they come down to (and this seems to be the motivation of at least multiple people on this thread) wanting to do the usual thing of "I would like to run a node so I can help the network operate", and quite likely also "and maybe I'll even get paid for contributing to doing that".

To give some background, most "blockchain projects" (which again, Orchid does not take the form of) are pretty much giant cons (in the general space of ponzi schemes, microcap stock fraud, and pump and dump scams): you are told you can run a server and make money... but where does that money come from? It either comes from people paying "fees" (which implies the product is already popular, a bootstrapping problem that requires high-quality clients) or it comes as inflation on the currency/token... which doesn't create value, it just "shifts it around" between people who already "invested" (as a form of "security tax" on accounts)...

...and so you then have to ask "why does the token have value in the first place?" and the answer is effectively some other part of the con, with people speculating in the idea that the currency/token might one day have value. It is this speculation that then drives a bunch of people to burn a ton of resources into maintaining an ecosystem that no one might actually be using yet to prevent being diluted by all the inflation (which "at best" cycles back into speculation from investors seeing "activity")... I will posit that that doesn't make any sense and has some ridiculously bad incentives, as the act of running the network isn't creating value.

Orchid, on the other hand, is an actual market: nothing pays you for running nodes other than end users actually trying to accomplish something that they were willing to pay money for, and for which you were more cost effective--even with all of the overheads implied by decentralized payments--than alternatives that were able to solve the same problem. It has a directory that looks a bit like "proof of stake", but as it isn't a blockchain (!!) it doesn't have a "proof of anything" as part of the architecture: we like to think of your stake as more of a cost of business, wherein you are competing for ad space for your services.

When the bulk of the honest participants are primarily being motivated by profit, as is the case in any actual "market", you then have a bunch of "fun" bootstrapping issues: if a dishonest user wanted to take over the entire market (which, from a security perspective, would be a serious problem), the honest participants would "let them" because essentially the dishonest user is willing to drastically outbid the honest user for what amounts to some tiny income stream. We thereby, right now, quite on purpose, have somewhat of a "lopsided" market, with providers who are "partners" being paid by us to "care" about Orchid working.

You then combine the lopsided market (let's call this 1 in the following list) with 2) some scary network security issues that lead to the existence of our federated curation mechanism, 3) that the client actually cares quite a bit about latency and so intends to be doing some "comparison shopping" that will lead it to prefer larger VPN providers over asymmetric "last mile" network connections, and 4) that we honestly are already "over-provisioned" on servers (due to having large initial partners; meaning the basic dynamics of supply/demand is going to push back pretty hard on there being even more servers).

This means that running the server--again, as a user attempting to "provide bandwidth" to the system, as opposed to a developer wanting to do free off-network load testing to debug an issue between the client and server, or wanting to help port the server to run on something it doesn't already support (like BSD maybe)--is not going to help you, and it isn't going to help us: for multiple reasons what is going to end up happening is that you end up running the server and staring at it, wondering why you aren't getting any traffic (due to lopsided stakes, no one curating you, your last mile bandwidth, and low demand).

Like, if you really want to help Orchid: download our client, and encourage others to download our client. If you find problems with the client, or have suggestions for the client, file those as issues so we can work on fixing them. If you believe you have a use case for the Orchid market that isn't a use case addressed by our tunnel client (which in the long term we expect to be just one of many uses of Orchid: I get the weird feeling like people somehow expect to shoehorn uses of our protocol into our existing client, but that doesn't work), send us an e-mail so we can have meetings with you to see if we can help you integrate.

(Even better: if you have a use case for our layer 2 nanopayments system--which is entirely unrelated to our bandwidth market and which usage of wouldn't involve working with either our existing client or server, as it would be integrated into your own software--we would love to work with you! As we have now launched our fiat payment gateway, which is somewhat unique in this space for being a legally compliant way for someone to consume our services without having to buy token on an exchange, this is a great time for people to figure out new ways of using our nanopayments layer--not our protocol--in their own products.)

Thereby, a lot of my focus right now is on expanding the use cases of Orchid, as I need to make sure that there are a lot of reasons to be using Orchid that don't fit into the profile of a "tunnel"; and since this will definitely involve pushing new servers--as right now the mechanism is inherently about 1:1 bandwidth forwarding, which has extremely limited generalization: what you are buying isn't "bandwidth", but is more "indirection", and so none of the use cases for "buying bandwidth" really relate to server as it stands today--this just becomes yet another reason why having more people run servers just isn't helping.

I hope this gives you some insight into what is going on with Orchid, and why conceptions you might have from other "blockchain projects" (aka, "cons" ;P) don't directly apply to our system today. I do hope you are interested in helping, and I hope that any of the options I've described here resonate with you... if nothing else, I would hope that "run the Orchid tunnel client" is something that anyone can do; and, to the extent to which you don't find that compelling, or think the client isn't "there yet", well then that's just more reason why the client needs more work and calls further into question running more servers ;P.

As for this thread, while I don't disagree with the idea of "this project needs more documentation" (and could see having an issue about that, though it seems superfluous), this issue is just "not that", so I am going to close it. If you want to keep conversing, and everyone can be civil ;P, I am going to leave the comments open for now; but, generally, for end-user customer support issues--anything along the lines of "how do I" instead of "why did it"--you should take your question to a user-level customer support channel: email Orchid Labs, send them a direct message on Facebook/Twitter, or possibly reach out on Telegram.

MaHi177 commented 5 months ago

Is it possible to Running a Node now to provide my hightspeed bandwidth.