FYI the Node Operators Terms and Conditions are currently in the final stages of getting updated, we are only waiting for final approval from legal before they get published.
9 Likes
Is there any update on the release yet?
Great, because almost the most annoying point of these discussions are the fact that Storj lacks behind current practices and the fact many are referring to the ToS stating this and that (which I don’t read in it).
To be clear, the ToS doesn’t forbid circumventing the /24-rule because it was written before that rule came in. However, it clearly forbids to run more than one node behind a single IP (“5. Restrictions. (…) you will not (…) 4. Operate more than one (1) Storage Node behind the same IP address;”).
So, if we make things black-and-white: the TS actually asks for a way, in which he can live up to the current literal ToS, who even can be rightful confused about current rules. So no point in blaming and shaming node operators. In my opinion, Storj is the only party in this case to be rightfully blamed-and-shamed. The longliving situation, in which you had to extract the “rules” from ToS, manual and forum (contradicting each other and so on), is and was really a situation to be bluntly ashamed of.
TLDR: I’m happy to see the ToS being updated, be lenient for some months to everyone in order to give them time to live up to the new ToS and make sure that you -whoever is responsible at Storj for the task- keep it up-to-date. As side profit of the clarity, it will prevent pointless discussions and unnecessary naming and shaming.
2 Likes
Any TOS is pretty useless in a decentralised type of service, without an automated mechanism to enforce it. The trustless nature of decentralisation can’t work based on trusting unknown members/parteners/providers/clients to play by the TOS rules.
Ok, rewrite the TOS, state your conditions, but don’t expect everyone to follow them just because… tell me to not do this and that when you have a mechanism to compel me to comply, that I know of, is automated and is guarateed to work if I breach the TOS.
4 Likes
Indeed, but having no applicable or outdated rules in your ToS and threatening people to disconnect / invalidate their nodes on socalled rules that aren’t stated explicitly somewhere, is walking on legislative thin ice. You first have to formulate the rules, you’re judging regular people (as node operators usually are) by. If it’s not a priority and you don’t care, than say it blunt in your ToS and don’t tell people they’re cheating because they found out a loophole. It only underlined the fact, you don’t have to neglect your ToS the way Storj died. And I agree, the more you enforce within the network, the less you have to write down in your ToS.
And to be honest, the earlier we have a clear ToS (hopefully abandoning more than one IP per user) preventing pointless discussions and unfounded threats, the merrier I am.
Agree. We need the new ToS, but in the same time we need the enforcer mechanism. If you lack this mechanism, is better to not make the rule in the first place. That’s what I’m saying. I’m all pro-decentralisation and rules that assures that, because without it, we wouldn’t be here. Untill now, the only rule that has an implemeted mechanism in support for it, is the /24 subnet limitatation. It limits the traffic for all nodes per /24 subnet to the same traffic as one node, but it dosen’t prevent circumventing it with VPS and VPN. So, if you can’t stop people using it, don’t say “circumventing it is unacceptable and we will ban you,… maybe”. What this does is just creating the situation where sno’s are using vps because the certenty of more profits outstands the uncertenty of banning, and Storj is put in the uncomfortable situation to manualy ban them and angree them or allow them and angree the others. Imagine if you ban someone’s nodes that has invested in 30 nodes, 10 of them in different locations, knowing that he can use vps and vpn for the others. He will loose money, he will stop all the other legal nodes and never come back, and make an ugly scene on all forums. And he was a very reliable asset, with deep IT knowledge, willing to run strong nodes for many years, not like someone just using a spare diskspace, ready to close it without any GE when needs the space, or got bored with running a node.
This isn’t true. It’s a legal document which also protects Storj Labs against liability when they take action to prevent node operators from circumventing systems in the network. For legal reasons, they would still need the ToS too. This is also why any ToS tends to include broad language that says you are not allowed to circumvent anything. Which, btw also means we should not expect specific language around circumventing a specific part of the networks workings.
2 Likes
Contradicts:
You have to be as specific as possible, because you don’t have any founded reason to take action at the moment you find some (especially already well-known) behaviour disruptive for your service.
For example, current (outdated) rule of only 1 node per IP easily could be enforced by denying any concurrent connection from the same IP. Can be mentioned in the ToS, but will be self-explanatory at the moment users try to circumvent this rule.
Rules like no more than one IP per physical location (or something like that), one disk/CPU per node, etc. need specifically to be in ToS if you find them important (which I doubt to a certain extent), as long as you don’t have specific and easy to implement ways to enforce them. But you could also list them in a separate list of prerequisites for nodes, which is updated separately and more frequently than the ToS itself; as long as you refer to that list in the ToS and make sure you take the effort to communicate significant changes to your node operators.
The “/24-rule” (which isn’t a rule, see below) is one of the latter, especially because it’s actually a quite raw proxy for location and not easily enforced. As long as we accept the fact VPN’s are being used (also for understandable/acceptable reasons as GC-NAT in my case), you have to be specific on the fact that only one IP per location is permitted. It’s a way the network may become a bit more unreliable, although this shouldn’t be overestimated (see also calculations in the excel sheet). So it’s a precondition for the reliability of the network, not something like “how the network works”, since the network is still working although we assume many people are finding ways to make more IPs bound to one physical location.
Strictly spoken, it’s also not circumventing a rule, because not stated in any legal document. Opposed to, as already argued before, for example the practice of running multiple nodes behind one IP which is explicitly condoned in the manual. So strictly spoken, node operators using a different VPN for every node they start are actually living up to current ToS (and not to be mentioned “cheaters” or whatever subversive language can be used).
So the reason why we’re having this discussion, isn’t the behavior of some node operators (I don’t know whether we even have an estimation how big the problem actually is), but the fact that significant chances in preconditions of the network weren’t reflected in the ToS. So actually legislative/juridical neglect from the Storj-company, which they should account for instead of those some (or many?) node operator.
1 Like
It doesn’t. They don’t need to mention the circumvention of any specific system. They just need to outline the rules so they have backing to van your node if you break any of them.
So, there may be a rule that says you must use a single IP for nodes that share physical hardware. But there won’t be a line to say circumventing the /24 node selection system with the use of VPS or VPN is a bannable offense.
I don’t think we’re in disagreement here. The ToS need to be updated for sure. But it doesn’t stand on its own. ToS doesn’t provide protection against liability anymore if other official communications have repeatedly contradicted a specific point. So those outdated rules have effectively lost their legal teeth.
I also never used the word cheater as far as I’m aware. My objection to helping someone circumvent the selection system is because it would be detrimental to the network as well as other node operators. Despite what the ToS says or doesn’t say, it creates an unfair advantage and centralization of fault domains.
I may have colloquially refered to the /24 node selection system as a “rule”, but never intended that to mean it’s a legally stated and binding rule.
I mean, it literally is. It’s because someone asked how to circumvent that system. My own objections were not based on ToS, but to be fair, the following clause absolutely covers this topic.
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.
2 Likes
I agree on the fact that there’s a need to end the unclarity.
This way of interpreting the ToS, it’s far from a juridical way. It’s so to say anachronical:
- At the moment this 4.1.3 was stated, also 5.4 was stated.
- The /24-“rule” was implemented later.
- Since 5.4 says you only can have one node behind an IP, 4.1.3 wasn’t meant and therefore never can be interpreted as meaning you should use multiple nodes behind one IP rather than gaining multiple IP-addresses for one physical location (as some already have by default, or those using VPS or something alike).
- Aside from the fact not all node operators are aware of the full contents of the manual and the forum, 5.4 is actually juridical considered still to be in effect since every new node operator still has to agree with current ToS notwithstanding the fact the manual is contradicting it. Since the manual is also written by Storj, it’s only an argument to say that 5.4 isn’t enforced anymore; this however doesn’t lead to a broader interpretation of 4.1.3.
So juridical there is no foundation to interpret 4.1.3 this way, nor is there any other rule specific forbidding the use of VPNs or any other means to get multiple IPs for one physical location. Case closed.
So in order to provoke an official statement ASAP, I will provide a brief manual for those looking for a way to evade GC-NAT-restrictions (which can be used for other purposes, of which many aren’t that fond here; use on own responsibility in light of next release of ToS) and even making the play field more equal to those with less programming experience:
- Create a cloud computing instance on Oracle Cloud (if you use only 1 vCPU and 6GB RAM, you can create 4 of them on Ampere A1, which is on ARM-architecture). It’s free!: https://signup.cloud.oracle.com/
- Follow this manual: Hosting services behind a restrictive firewall/CG-NAT using DNAT with iptables on a VPS hosted wireguard endpoint | Trinkets, Odds, and Ends
- Instead of installing Wireguard manual, you can use the Angristan script, to be found here (more convenient): GitHub - angristan/wireguard-install: WireGuard VPN installer for Linux servers
As I hope, we will sort out a usable way to make the network as reliable as possible, using as few as possible redundancy (e.g. reducing the numbers needed for the RS-erasure encoding, lower than current 80 / 29).
I hope, forbidding VPNs at all; checking on latency between nodes / users to find out?
1 Like
It would probably be more polite to do this on a workday, but I like it ^^
Latency might be pretty hard to use for a binary response. We can’t trust users to provide metrics, as they themselves might have unreliable networks or just peering issues. Also, aggregating statistical information from many users is difficult to do accurately. Pinging from satellites is also a problem, as we do want nodes to be located in obscure, far-away places (for redundancy and for customers who happen to also be there).
Storj Inc. probably has some ideas, I suspect they’ll only share them with the new T&C.
BTW, I kind of hoped that the PingNode procedure already collected latency information—apparently it doesn’t.
1 Like
Those things like ToS cant be made asap, it have to be written in proper language and inspected lawyers. This takes time.
2 Likes
The many topics on this subject, already have provided tons of opportunities to do so. Besides, if you look back this topic, you see many likes from people more closely involved with the project liking reactions I think reflecting their way of thinking; without replying, which has even complained about in this topic before (also providing an opportunity). Since I’m one of the VPN-users, evading GC-NAT-limitations, I rather like to know earlier than too late whether I need to look for another ISP.
I can imagine. But VPN, especially further away, quite soon increases latency. For example, even the VPN to my parents-in-law 50km away increases latency by factor 2-3x. And Oracle Cloud located only 1500km away even factor 4-5x. So the upper bound latencies for each country, are most likely VPNs, especially if related to AWS, Oracle, Microsoft or any other VPS corporation.
I mean, even a bad network setup, probably doesn’t account for 30ms difference for the same country.
Ah, that’s why it took ages, while Microsoft, Google and even my ISP are able to update it about every three till six months (at least seven times the length of the ToS Storj has)?
BS, it just wasn’t a priority for whatever reason. That’s why.
It takes time, but ahead of final publication there can be given some raw outlines about what direction we’re heading together.
1 Like
you forgot about scale of company’s I think storj dont have TON of lawyers like google and microsoft has.
I don’t think posting how to get around the /24 rule matters. We’ve been assisting users with VPNs to help with NAT issues since v2. Storj Labs can decide if they want to tighten the restrictions if it is a problem. In the meantime, Legal takes a while when Storj needs an updated or new document. In my experience, it typically takes several months before we see updates. There may be aspects beyond what is currently being discussed here that they want to add or change.
2 Likes
For sure, like you need twenty lawyers to get over it. While even the smallest company needs to have a T&S, and is able to update it more regular then once in two years.
Sounds like good news for @eddy89 and many node operators using VPNs for the time being, although you don’t seem to be on the same page as is @heunland .
I think you’re right BTW, it’s not a big problem as I already did the maths in one of previous topics I was referring in this topic. Using very conservative assumptions. Although in the end you need to account for it, in the calculations of the redundancy rate you’re implementing.
So we’re sticking to the real / current ToS for the time being, except for the rules the manual is evidently contradicting? (Abstaining from referring to ToS, when ToS clearly wasn’t intending that way like in /24-“rule”?).
That free account on Oracle Cloud has a 10Mbps bandwidth per account; add to that increased latency and maybe neighbours, and you get yourself a pretty slow performing node.