In the operator term conditions it’s stated that one should not operate more than one storage node behind the same IP-address (5.4). However, support and multiple answered questions on the forum concerning what to do with multiple hard disks seem to contradict this point. Otherwise, the solution apparently isn’t to avoid this problem by using proxies or VPN.
How does this fit?
Storj has allowed SNOs to operate multiple nodes so its not breach of TOS on SNOs part. Updating TOS takes time and money which could be spent over other important things.
Well, I don’t know why a change in advantage of the SNO’s would be difficult. Let alone it costing money to do so. Perhaps an explanation would be helpful on this part.
The other side is:
It introduces haziness on what we do and don’t have to respect: apparantly we may have multiple nodes behind one IP (invalidating section 5.4, and subsequently section 4.1.2), but apparently we should not use VPN’s or proxies (if not used to overcome the problems of GC-NAT for example) because that’s not in spirit of STORJ c.q. not serving it’s purpose while not explicitly forbidden in the terms and conditions. So essentially it introduces legal uncertainty, which we all hope and expect STORJ will never take advantage of in any future situation when it serves their purpose.
You get it right. You may use multiple nodes behind the same IP (we implemented a filter on /24 subnet of public IPs since the ToS were published, so no damage to the network - all your nodes will get the same amount of ftraffic in total as a one node).
But with VPN you could avoid the filter and it could be possible to have several pieces from the same segment on the same device and location, which is bad for the network. This situation will be treated accordingly ToS as a violation.
Thanks for your answer, because this exactly underlined my point: VPN to avoid the subnet/24-implementation isn’t de facto forbidden by the ToS. But the situation promoted by support is de facto against the ToS.
As the support-page dates back about two years ago, I try to underline the fact we still have to agree to a ToS that effectively is a paper tiger because it’s outdated c.q. lagging behind the encouraged practice.
And I know we still haven’t discussed the practical part of enforcing it, which doesn’t matter because the theory isn’t right at this point.
Can’t, because ToS doesn’t say so. That’s the point I’m making.
Most relevant to this one, would be section 4.1.3. (“You will not modify or attempt to modify the Storage Node Software for any purpose including but not limited to attempting to circumvent the audit, bypass security, manipulate the performance of, or otherwise disrupt the Storage Services for any reason, including but not limited to attempting to increase the amount of data stored or bandwidth utilized or the amount of Storage Node Fees, as defined herein, and you will not otherwise interfere with the operation of the Storage Services.”).
But someone setting up a VPN connection, didn’t change the SN-software, thereby rendering the section useless in this case.
There is no such statement like “Any physical location -being computer or data storage- may not be applied using multiple IP-addresses, as it is against to the distribution-spirit of Storj” (which also incorporates using multiple computers, but same storage by e.g. FTP/SMB/etc. or having multiple IPs at the same address, aside from the VPN-case).
And Storj can’t say it wasn’t aware, see for example 5 nodes on the same HDD vs 5 nodes on a separate disks - #17 by BrightSilence with the only difference that the statement it’s against ToS -bluntly said- is just false.
More like the other section,
5. Restrictions. You will operate the Storage Node in strict accordance with the terms of this Agreement and in no other manner. Without limiting the generality of the foregoing, you will not:
<…>
5.1.7. Manipulate or alter the default behavior of the Storage Network to artificially increase or decrease the value of any reputation factor of any Storage Node;
<…>
5.1.17. In any other way attempt to interfere, impede, alter, or otherwise interact in any manner not expressly authorized hereunder with the Storage Services or the operation of any other Storage Node(s).
but you are correct, ToS need to be updated anyway, the default behavior of the network have changed since publication.
Using VPN, you’re not changing the storage network, but only the way you connect to it. Moreover it’s not about reputation factors, like it’s not changing suspension- or auditscores. At most, you can argue it may speed up vetting. Although I even doubt this makes really a difference nowadays, since before and after 100 audits from every satellite I didn’t notice any difference in ingress in comparison to the younger nodes, although having two vetted nodes over a month of age.
Using VPN, there is no interferention nor obstructive or impeding behaviour acted out on the storage service. The way of interaction is further exactly the same, as would be when not using VPN.
You could only argue that more pieces of the same file could end up on the same system. Although, I think these chances are actually very low due to the many nodes in the network. Besides this problem also arises with addresses having more than one ISP or data centers connecting with an IP-range </24, in which situations different /24-range IP-adddresses can end up using the same physical disk, computer or ethernet adapter but being seen as different nodes from perspective of the Storj-network. But these situations aren’t treated alike here on the forum, although posing a comparable risk.
Indeed, another reason why ToS isn’t usable. Since default behaviour and purpose of the network haven’t been described in the ToS. While concerning a developing service.
So, essentially I’m really wondering 1) why such vague sections are being used in this situation 2) why essentially same situation aren’t treated the same way 3) why we should care about these situations -carrying very low risk of impeding the network anyway- and Storj apparently doesn’t care that much about these risks to address it in an updated ToS, while knowing them.
From legislative perspective, Storj would be on thin ice when deactivating nodes due to use of VPN. Has it been ever? Aside from the fact it would probably be almost impossible to detect it or make difference between the use case to overcome the limitations of GC-NAT for example.
Our engineering team believes that this is should be implemented in the protocol rather to use only ToS:
Yup, but even that thread an offspring of it shows a lot of vaguety. But it essentially boils down to: we rather don’t see it happen, just like applying with same hardware and multiple ISP’s or maybe even many IP’s from same data center; but we don’t have viable options to detect and/or enforce not using save hardware of any kind, so we leave it up to SNO’s to act as much as possible in spirit of Storj.
But effectively, I doubt whether it’s a real problem for multiple reasons. First is that it takes a certain degree of knowledge to be able to set up such design, which usually also entails better network management skills. Second, taking the given example of 5% having 10 different IP’s over VPN’s / data centers / different ISP’s or any kind alike SNO (let’s call them VDI’s). Taking info from https://storjnet.info/ there are 12,000+ active unique /24-subnets, of 23,800+ nodes. Being pessimistic, all VDI’s do have only 1 IP in a subnet (which almost certain isn’t true). Assuming a usual SNO running on average two nodes. Then, 23800 / (95% * 2 + 5% * 10) * (5% * 10) = 4960. So, 4960 out of the 12,000 are maintained by VDI’s, owning all 10 of them (so 496 SNO’s).
Every file is distributed in 80 pieces, of which 29 need to be available in order to recover the file. Chance two or more pieces ends up at one and the same VDI-SNO, is the same chance as 1 - [0 or 1 pieces at every SNO] is about 0.2%. But since we’ve got 496 of them, chance of having no VDI-SNO with 2 or more pieces is (1-0.2)^496 is still about 38%. And then I’m even pessimistic.
SNO with 2 or more pieces:
No SNO’s with 2 or more pieces:
I did the full math today:
Even with very pessimistic assumptions, VPN’s / data centers / proxies are quite innocent actually. These assumptions:
I had to assume very pessimistic, to even see a significant drop in availability: like <80% online-time, >20% chance of loss of a piece at any time.
Actually quite surprising to see how resilient this protocol actually is. Perhaps even the reason, who Storj actually doesn’t care this problem that much.
