An update about durability and data traffic in Ukraine and Russia

Node Operators
1

As you are most certainly aware, war has broken out in eastern Europe. Storj is a US company. We stand firmly with Ukraine, and also recognize that the Russian people are not responsible for the recent actions by their government. We have a blog post coming about our support for Ukraine shortly.

As a US company, we must comply with any sanctions the US government imposes. The current sanctions do not require us to stop payment to Russian storage nodes. We will do our best to support storage node operators wherever they are while still complying with the laws that apply to us.

Currently, the only related sanctions we must comply with, in addition to sanctions in place prior to 2022, are for nodes operated in Luhanska Oblast, Donetska Oblast, and the Crimean peninsula, including Sebastopol. Nodes operated in these regions are currently under sanctions. This means that payment for these nodes will not go out. The situation is active and constantly changing, and if new sanctions are posted, we will comply with them.

Most recently, there has been some concern that Russia will decide to cut itself off from the global internet. This is not the first time Russia has considered this. Storj has been contemplating this possible outcome for some time, but believes the likelihood of this event has increased due to recent events.

Storj expects to occasionally have advanced notice of risks impacting storage nodes’ internet connectivity. While we make every effort to be prepared in advance for a situation such as this happening without warning, an unexpected event of this magnitude could have a major impact in repair load after the fact, even if no data is lost (we do not expect lost data even if this were to happen unexpectedly). It would be better to spread this load out in advance. In the case of a hurricane, for instance, we may temporarily halt new uploads to a suspected affected region, and increase repair rates around that region during that time.

The Russian internet connectivity concern is no different. Storj believes there is potential for risk, and as a result, has temporarily halted new uploads to storage nodes in Russia and once more increased repair thresholds.

If you’ve been seeing recent code changes: we made these changes by excluding certain regions during uploads and during our health evaluation phase, but have so far not chosen to actually instruct the repair workers to treat pieces in excluded regions as failed.

We are hoping for peace and are eager to look back on this step as overly cautious. Please stay tuned for an update about what we’re doing to support Ukraine, and as always we are eager for feedback on what more we can do to facilitate peace and stability during this time.

29 Likes
2

Tunneling traffic, via VPN or other methods, to an “approved” IP address would probably allow an SNO to avoid such restrictions…

Are there node IP tracking policies in place for historical reference?

3

Are you asking if we have logs of the history of a node’s set of IP addresses? Yes. We’re also keeping an eye on traffic tunneling.

1 Like
5

I do not support the Russian government’s actions, but I fully agree with Krey:

in the sense that you signed for the fact that you could not create a decentralized cloud storage.

1 Like
6

It’s not an IT company… Storj is a US IT Company.

The company is required to abide by the policies of the US. It doesn’t matter if the Storj company agrees with the current politics of the situation or not.

Don’t blame Storj. Blame the US Government.

5 Likes
7

91 posts were split to a new topic: Politics and consequences of the conflict

10

There are ~1400 nodes in Russia of ~13000 total in the network. As a node operator in Russia, I hope that storj will find a solution that will allow us to continue to support the decentralized network. Unfortunately, this is a lesser problem than the one faced by the citizens of Ukraine. Make love not war

14 Likes
15

I think we just need to put people with inappropriate comments in read-only mode for some amount of time. What we need to focus on is how to maintain our relations with storj in best interest of both. I hope storj will think of a better solution than stopping ingress. The so-called “cheburnet” was in talks for quite a big amount of time, so rather than cutting off ingress I think it is better to make some gradual solutions.

2 Likes
16

We don’t need a moderator for that. Just flag the comments as inappropriate.

2 Likes
17

I seen some stuff in canada happen and i don’t even agree with my government I live in ottawa canada and i support peaceful people and not wars governments have to much over reach of power, an i’m talking about canada and usa here. As a community and the world we need love and peace not hate. As a grown man i haven’t cried as much as i have the last 2 months. we can hate each other again later but we need to put our differences a side for this. We went from a long pandemic to a war, just listen to real peoples stories.

5 Likes
18

Could you please tell me as node operator - should I make a graceful exit or not ?
What would be a best choose if I would like to stay my node working for future ??

2 Likes
20

If you would like to stay just keep your node online. At the moment we are basically in a light emergency mode and preparing the network for the worst case. So for the moment just wait.

The ideal solution we would like to implement with more time:

  1. The repair checker adds the segments at risk early into the repair queue. The repair checker should assume the nodes will get disconnected soon.
  2. The repair worker should also assume the nodes will get disconnected but otherwise doesn’t penalize the nodes. One way to do so would be to upload additional pieces without replacing the nodes at risk.
  3. Take a look at file uploads. Currently, we do not upload to the nodes at risk. If we have implemented the first 2 points lets revisit the node selection and think about a better solution.

Just in case the worst situation might kick in and the internet gets split in half. For some time we might have problems staying in contact. Hopefully one day the conflict gets resolved. I would say from our side we would like to get you back into the network and together we could discover some options we might have.

8 Likes
23

Yes, sure
you could try other approaches instead of cutting off all traffic to Russia
for example, let people decide which locations they want to send traffic to and which they don’t. The decision to create a satellite in the Russian segment would look logical.
For example, if a fake cheburnet happens, let the store traffic in this segment continue to go and be calculated

PS I’m not going to discuss politics on IT resources, in fact, this was the point of my first post in this thread. Although a few lines were so superfluous.

2 Likes
24

Unfortunately, we would be unable to maintain that satellite ourselves anymore. So it would need to be a community satellite. I am not sure if we can get a community satellite running in a short amount of time.

It seems to be important for you to call it fake. Please note that it doesn’t matter if it is fake or real. It doesn’t even matter who will enable it. The outcome is always the same.

Let’s say there would be a community satellite running and we wouldn’t have to maintain it. That also includes storage node payouts and customer invoices. We wouldn’t be able to run these operations as well. So that would also fall into the responsibility of the community satellite.

6 Likes
26

But why? this is probably the same question as why the Asian satellite is disappearing. Who is stopping you from keeping a couple of specialists in the Russian and Asian segments on a salary?

27

We have specialists in Ukraine. I hope that answers your question…

6 Likes
28

Could it be possible to “freeze” affected nodes in such case? I don’t mean including data, just put it out of suspension and save the “age” of node on satellites. It would be less painful to start over without 15 month penalties.

3 Likes
29

I can’t promise it. Let’s hope it is not needed in the first place. I can think of different ways to make the start less painful. Since I am not the one that has to implement it at the end my target is more to kindly request that we regroup even after losing contact.

3 Likes
30

the network should be geo aware and thus be able to locate data so losing a geolocation wouldn’t matter… ofc that isn’t really the case and it’s a difficult things to do… if even possible.

31

Hello. I’m from Belarus and today I doesn’t have ingress traffic too.

3 Likes