6 ms·

I'll bite. I think some of the crowd on HN might be interested in selling bandwidth. It seems like that's not the focus for orchid at the moment (based on the l

I'll bite. I think some of the crowd on HN might be interested in selling bandwidth. It seems like that's not the focus for orchid at the moment (based on the lack of info on the website and the lack of github build instructions.) Is there a support channel for someone interested in trying out staking, running a node, selling bandwidth, etc.? Is there a roadmap for supporting people interested in that side of things?

saurik 5y ago
FWIW, I'd be surprised if it were difficult for an interested developer to compile Orchid (as stated in the README: go type "make" in srv-shared and install any dependencies you are missing... same way I usually build anything ;P there is also a Docker build script for "docker build" as well as a way to wrap the makefile into Docker, which is mentioned in the README: run env/docker.sh). If you aren't a developer: just download a pre-compiled build; the 0.9.33 build that came out a couple days ago works great. I also have GitHub Actions set up to do a complete build of all of our components every time we do a push, and so you're also able to go back 90 days or whatever they hold on to and download a server asset. This also means I know 100% that it compiles OK ;P. As for actually succeeding in selling bandwidth, that is fully possible right now (and has been since the network launched)... but, very awkwardly, not to the (vast) majority of people who are currently running our client in its default configuration. You will need to get users to 1) purchase OXT and manually set up their account and 2) get them to change the default "curator". This is due to a combination of factors, but the deepest one--as in the one that is serving to be most difficult to fix, both internal and external to the project, as well as the one that personally frustrates me the most (if you know who I am ;P)--is that our users mostly buy in using "in-app purchases", which has led to us implementing various restrictions on spending them. The result, though, is that if you go through all of the trouble to get set up right now, you won't actually get to experience anyone paying for your bandwidth in practice, even though I solemnly swear that the system is legitimately decentralized in that nothing is actively preventing that from happening: the system launched in December 2019 and has been "fully functional" ever since. I, thereby, am quite reticent to publish an easy-to-follow guide where step 5 is "now be disappointed in the result", as I don't even think that is a valuable use of time for the people who are trying to contribute to the system. The best things you can do to help are: 1) lobby against Apple/Google; 2) improve the state of play for wallets; and 3) get people to download/use the client. (As for something like a "roadmap", I try to prevent anyone from telling people about the order/timing of work we are doing because the system should be considered functional "as is"; I think most projects that have "roadmaps" in this space use them to cause people in the ecosystem to speculatively purchase large quantities of what should really be a "utility token". I hope you understand.) (That said, there is some public discussion of this specific task--to make it easier for people who have a copy of the server to run a node--related to an issue that I feel able to point you at: https://github.com/OrchidTechnologies/orchid/issues/103 https://github.com/OrchidTechnologies/orchid/issues/103. I will, admittedly awkwardly, not comment on whether or not I intend to make a commit in the near future to address this deficiency.)
- dlss 5y ago
  > our users mostly buy in using "in-app purchases", which has led to use implementing various restrictions on spending them. Browsing through the code, it looks like Orchid's xdai contract is https://blockscout.com/xdai/mainnet/address/0x6dB8381b2B41b74E17F5D4eB82E8d5b04ddA0a82/transactions https://blockscout.com/xdai/mainnet/address/0x6dB8381b2B41b7... -- which shows in-app purchases of bandwidth being a bit less than $75,000 total for the last two years. Is that right, or am I missing something? > I think most projects that have "roadmaps" in this space are using it to cause people in the ecosystem to speculatively purchase large quantities of what should really be a "utility token". https://www.coingecko.com/en/coins/orchid-protocol https://www.coingecko.com/en/coins/orchid-protocol shows Orchid's trading volume as $22 million for just today...
- caslon 5y ago
  So, basically what you're saying is that it's centralized, just not at the protocol level?
  - saurik 5y ago
    While I think the word "decentralized" has a lot of nuance that people often forget (as an example: federated systems are also "decentralized", though I'd argue they barely live up to the term), the core problem is an equivocation on the word "it": Orchid, with the prepaid access credits system we had to put in place to satisfy Apple/Google, essentially is "a network of networks", all of which share not only the protocol (that would be trite) but share the entire mechanism for staking and selection: there is no difference at the level of the staking system between what "network" you are on for this purpose... there is but one shared pool of servers. The issue is that the money comes in different shapes and forms, and individual users have access to different forms of money and individual servers accept different forms of money... and due to restrictions put in place by Apple and Google, we were forced to go to great lengths to support the ability to pay for the service using "in-app purchases", which results in a very large number of users having money that has been constructed--on the blockchain--to only be able to be spent with a set of servers that we are legally required to collect personal information from, making it "permissioned" if you want to accept that money... which you don't have to, but you aren't going to make much money. It thereby isn't that the software we have released is in any way centralized: it isn't. The directory of providers isn't either. It isn't that any of the "protocols" I designed for this are somehow decentralized vs. centralized (I'm not even sure what that would mean: it would be like claiming OpenVPN is decentralized but NordVPN isn't? at best that would be, as I said, "trite"). The status is more that you are opening up shop in a bazaar, but weirdly most of the customers aren't carrying around cash, but you aren't allowed to accept credit cards. There's nothing preventing you from selling to any of these people, though. There isn't some server I'm running that is holding the entire thing together like the keystone. Where it just kind of burns me up, though, is that the vast majority of people in the crypto space are just looking for "an easy buck", and so what they are looking for are easy to follow instructions to "stake money and get rewards", and the reality is that I know that the current state of Orchid would make those people sad, and so I don't go out of my way to bother making a "guide" where step 5 is "you are now sad"; to me, this is part of "being honest about what we have". But like, it isn't hard to run the server: you just need to be pretty comfortable calling functions on Ethereum contracts with a wallet and be able to deal with a relative paucity of documentation... I think that maximally prevents deception. There are other solutions right now that, in contrast, I would argue "aren't honest": they are actively getting people to run servers, for example, but they don't even have payments at all yet, and have said every month for over a year that they will have payments in place "soon"... or they have a system set up to pay for servers using "inflation" on some underlying investment asset, and then report an APY that is largely based on the value being held up by speculation. Orchid has had payments working--in a way that is absolutely decentralized and which works over a legitimate utility token... but at a small scale--ever since we launched in December of 2019. It is just that we were also forced to build a second set of users by companies like Apple and Google to support their App Store monopolies, and those systems massively out-compete our decentralized users :/.

saurik 5y ago

FWIW, I'd be surprised if it were difficult for an interested developer to compile Orchid (as stated in the README: go type "make" in srv-shared and install any dependencies you are missing... same way I usually build anything ;P there is also a Docker build script for "docker build" as well as a way to wrap the makefile into Docker, which is mentioned in the README: run env/docker.sh). If you aren't a developer: just download a pre-compiled build; the 0.9.33 build that came out a couple days ago works great. I also have GitHub Actions set up to do a complete build of all of our components every time we do a push, and so you're also able to go back 90 days or whatever they hold on to and download a server asset. This also means I know 100% that it compiles OK ;P. As for actually succeeding in selling bandwidth, that is fully possible right now (and has been since the network launched)... but, very awkwardly, not to the (vast) majority of people who are currently running our client in its default configuration. You will need to get users to 1) purchase OXT and manually set up their account and 2) get them to change the default "curator". This is due to a combination of factors, but the deepest one--as in the one that is serving to be most difficult to fix, both internal and external to the project, as well as the one that personally frustrates me the most (if you know who I am ;P)--is that our users mostly buy in using "in-app purchases", which has led to us implementing various restrictions on spending them. The result, though, is that if you go through all of the trouble to get set up right now, you won't actually get to experience anyone paying for your bandwidth in practice, even though I solemnly swear that the system is legitimately decentralized in that nothing is actively preventing that from happening: the system launched in December 2019 and has been "fully functional" ever since. I, thereby, am quite reticent to publish an easy-to-follow guide where step 5 is "now be disappointed in the result", as I don't even think that is a valuable use of time for the people who are trying to contribute to the system. The best things you can do to help are: 1) lobby against Apple/Google; 2) improve the state of play for wallets; and 3) get people to download/use the client. (As for something like a "roadmap", I try to prevent anyone from telling people about the order/timing of work we are doing because the system should be considered functional "as is"; I think most projects that have "roadmaps" in this space use them to cause people in the ecosystem to speculatively purchase large quantities of what should really be a "utility token". I hope you understand.) (That said, there is some public discussion of this specific task--to make it easier for people who have a copy of the server to run a node--related to an issue that I feel able to point you at: https://github.com/OrchidTechnologies/orchid/issues/103 https://github.com/OrchidTechnologies/orchid/issues/103. I will, admittedly awkwardly, not comment on whether or not I intend to make a commit in the near future to address this deficiency.)

dlss 5y ago
> our users mostly buy in using "in-app purchases", which has led to use implementing various restrictions on spending them. Browsing through the code, it looks like Orchid's xdai contract is https://blockscout.com/xdai/mainnet/address/0x6dB8381b2B41b74E17F5D4eB82E8d5b04ddA0a82/transactions https://blockscout.com/xdai/mainnet/address/0x6dB8381b2B41b7... -- which shows in-app purchases of bandwidth being a bit less than $75,000 total for the last two years. Is that right, or am I missing something? > I think most projects that have "roadmaps" in this space are using it to cause people in the ecosystem to speculatively purchase large quantities of what should really be a "utility token". https://www.coingecko.com/en/coins/orchid-protocol https://www.coingecko.com/en/coins/orchid-protocol shows Orchid's trading volume as $22 million for just today...
caslon 5y ago
So, basically what you're saying is that it's centralized, just not at the protocol level?
- saurik 5y ago
  While I think the word "decentralized" has a lot of nuance that people often forget (as an example: federated systems are also "decentralized", though I'd argue they barely live up to the term), the core problem is an equivocation on the word "it": Orchid, with the prepaid access credits system we had to put in place to satisfy Apple/Google, essentially is "a network of networks", all of which share not only the protocol (that would be trite) but share the entire mechanism for staking and selection: there is no difference at the level of the staking system between what "network" you are on for this purpose... there is but one shared pool of servers. The issue is that the money comes in different shapes and forms, and individual users have access to different forms of money and individual servers accept different forms of money... and due to restrictions put in place by Apple and Google, we were forced to go to great lengths to support the ability to pay for the service using "in-app purchases", which results in a very large number of users having money that has been constructed--on the blockchain--to only be able to be spent with a set of servers that we are legally required to collect personal information from, making it "permissioned" if you want to accept that money... which you don't have to, but you aren't going to make much money. It thereby isn't that the software we have released is in any way centralized: it isn't. The directory of providers isn't either. It isn't that any of the "protocols" I designed for this are somehow decentralized vs. centralized (I'm not even sure what that would mean: it would be like claiming OpenVPN is decentralized but NordVPN isn't? at best that would be, as I said, "trite"). The status is more that you are opening up shop in a bazaar, but weirdly most of the customers aren't carrying around cash, but you aren't allowed to accept credit cards. There's nothing preventing you from selling to any of these people, though. There isn't some server I'm running that is holding the entire thing together like the keystone. Where it just kind of burns me up, though, is that the vast majority of people in the crypto space are just looking for "an easy buck", and so what they are looking for are easy to follow instructions to "stake money and get rewards", and the reality is that I know that the current state of Orchid would make those people sad, and so I don't go out of my way to bother making a "guide" where step 5 is "you are now sad"; to me, this is part of "being honest about what we have". But like, it isn't hard to run the server: you just need to be pretty comfortable calling functions on Ethereum contracts with a wallet and be able to deal with a relative paucity of documentation... I think that maximally prevents deception. There are other solutions right now that, in contrast, I would argue "aren't honest": they are actively getting people to run servers, for example, but they don't even have payments at all yet, and have said every month for over a year that they will have payments in place "soon"... or they have a system set up to pay for servers using "inflation" on some underlying investment asset, and then report an APY that is largely based on the value being held up by speculation. Orchid has had payments working--in a way that is absolutely decentralized and which works over a legitimate utility token... but at a small scale--ever since we launched in December of 2019. It is just that we were also forced to build a second set of users by companies like Apple and Google to support their App Store monopolies, and those systems massively out-compete our decentralized users :/.