Storj - Potential?

[Heisenberg420]

Am 24.11.2020 um 05:05 schrieb GhostTyper:

Ich hab' mir jetzt übrigens die 256 TB gekauft.

Die sind aber nicht alle für Storj oder? Wenn doch auf wievielen Subnetzen? Das dauert ja gefühlte 20 Jahre bis die voll sind 😲

 

Am 24.11.2020 um 03:30 schrieb skunk:

..ob ich mir pünktlich zum Black Friday ein paar zusätzliche Festplatten gönnen soll..

Hab ich auch getan. Alle meine 8TB Nodes sind nun durch 14TB ersetzt. Die 8TB Festplatten werden dann als "kleine" Nodes eingesetzt. Somit betreibe ich dann an beiden DSL Anschlüssen jeweils 20TB.

Mein erster Node ist gerade beim letzten rsync durchlauf. Leider entsteht dadurch wieder eine Downtime von einem Tag.

Ich weiß nicht ob es am RaspberryPi und dem USB Port liegt oder ob es einfach die Masse an Millionen von Dateien sind die dafür verantwortlich sind dass ein einziger Durchgang über 12 Stunden dauert. Mein Node ist nun seit gestern 13.30 Uhr offline, vor einer Stunde hab ich den Durchgang mit --delete gestartet. Ich hoffe dass ich die 24 nicht voll bekomme, gehe aber davon aus dass es nun noch mal 12 Stunden dauert und dann bin ich gespannt- oder auch besorgt wie sich mein Online Status verändert.

Auch habe ich leider nach wie vor Probleme mit meiner immer wechselnden IP wegen der Zwangstrennung. Dadurch wird es für mich leider sehr schwer den Online Status wieder nach oben zu bekommen. Ich habe fast täglich immer 2 Minuten die Probleme machen weil das Update der IP nicht schnell genug statt findet. Und durch die immer wiederkehrenden 2 Minuten Downtime sinkt mein Online Status von Tag zu Tag ganz minimal und ich erreiche die 30 Tage gar nicht damit er wieder steigt. Ist ein großes Problem für mich und eine Dauerhafte Beschäftigungstherapie in den letzten Wochen um da eine Lösung zu finden 🥱

 

Insgesamt bin ich nun mit 6 Nodes in 4 verschiedenen Subnetzen dabei mit einer Gesamtkapazität von 56TB.

[GhostTyper]

vor 5 Stunden schrieb Heisenberg420:

Die sind aber nicht alle für Storj oder? Wenn doch auf wievielen Subnetzen? Das dauert ja gefühlte 20 Jahre bis die voll sind 😲

Ich habe jetzt 14 Nodes auf 7 Subnetzen. Alle Nodes sind redundant angebunden, was Strom, Klimaanlage und Netzwerk/Internet betrifft.

Ich habe 120 TiB (also 132 TB) Nutzplatte auf diesem Storage für Stor-J-Nodes committet (nicht alle Nodes liegen an dieser Location). Ich habe noch 20 BTFS-Nodes und sonstige Daten darauf.

vor 5 Stunden schrieb Heisenberg420:

oder ob es einfach die Masse an Millionen von Dateien sind die dafür verantwortlich sind

Die Nodes machen eigentlich gar nicht soooo viele Dateien. Ich formatiere mit einer Inode-Größe von 256KB.

 

[Heisenberg420]

Achja du lässt ja alles im RAID laufen. Würde ich nicht machen. Dann lieber noch mehr Nodes 😁 Aber das ist ja jedem selbst überlassen und das schöne bei Storj, dass man ein bischen experimentieren kann.

Nach 23 Stunden waren die letzten 2 rsync durchgänge abgeschlossen. Insgesamt habe ich nun wieder 10 Tage für 7.4TB in 5 Durchgängen benötigt wobei die letzten beiden bei ausgeschalteten Node liefen. Ich hatte so eine Gesamtoffline Zeit von 28 Stunden. Meine Online Zeit ist von 99.8% auf 95.7% - 95.9% gesunken. Wenn man bedenkt dass der Node 28 Stunden Offline war erscheint mir das sehr fair. Ich hab schlimmeres befürchtet.

 

Ich hatte auch noch drüber nachgedacht anders zu formatieren, da hatte ich aber schon 6 Tage hinter mir und kein Bock mehr noch mal neu anzufangen 😅

vor 21 Stunden schrieb GhostTyper:

Die Nodes machen eigentlich gar nicht soooo viele Dateien. Ich formatiere mit einer Inode-Größe von 256KB.

Bei mir sind 5.854.680 Inodes für 7.4TB belegt. Die zu löschen würde allein 2 Tage dauern 😒 Ich hatte bei der letzten Migration noch andere Daten auf der Festplatte und konnte die HDD nicht formatieren. Im Nachhinein wäre es schneller gewesen die übrigen Daten runter zu ziehen und die ganze Platte bzw. Partition zu löschen.

Naja learning by doing 😄

Bearbeitet 6. Dezember 2020 von Heisenberg420

[GhostTyper]

vor 11 Stunden schrieb Heisenberg420:

Achja du lässt ja alles im RAID laufen. Würde ich nicht machen. Dann lieber noch mehr Nodes 😁

Schwachsinn. XD

Ich hab' richtige Enterprise Hardware für viel Geld. Und da provisionier' ich doch keine einzelnen Disks 'raus. Auch sonst finde ich Raid >> einzelne Disks. Alleine schon wegen der rohen Lesegeschwindigkeit, wenn ich eine Node umziehe. Eine 12 TB Node ziehe ich in guten drei Stunden um. Und Du so?

Ich muss die Nodes zur Not weg werfen können, wenn zahlende Kundschaft kommt. Da migriere ich dann doch nicht einzelne Disks wieder in das Raid zurück.

vor 11 Stunden schrieb Heisenberg420:

Ich hatte bei der letzten Migration noch andere Daten auf der Festplatte

Na zum Glück brauchen diese die Ausfallsicherheit eines Raids nicht. XD

[Philbert]

Ich würde jetzt gerne auf meiner NAS einen oder mehrere Storj nodes laufen lassen.
Offensichtlich haben die meisten hier mehrere Nodes angelegt. Warum macht das Sinn? Braucht jeder Node eine eigene Identity?

Im Storj Forum hab ich jetzt folgendes gelesen:

Zitat

We filter out nodes behind the same /24 subnet of public IPs.
In other words, all nodes behind the same /24 subnet of public IPs are treated as a one node for uploads and as a separate ones for audit and uptime checks.
You will not receive more income with multiple nodes. It makes sense only if you have separate HDDs.

Eigentlich wollte ich 4 x 14TB als Raid-5 laufen und 30 TB für Storj verwenden und den Rest für anderen Kram. Ich könnte aber auch Einzelplatten konfigurieren ... 2 x 14TB und die anderen beiden Platten als Raid-1.

Was spricht dagegen einen einzigen Node mit 30 TB zu machen? Vielleicht krieg ich die Qnap Storage Node Docker App auch für 2 oder mehr Nodes am laufen ... soweit bin ich noch nicht. Was könnte damit gemeint sein: "It makes sense only if you have separate HDDs."?

[Heisenberg420]

Am 6.12.2020 um 20:39 schrieb GhostTyper:

 Eine 12 TB Node ziehe ich in guten drei Stunden um. Und Du so?

😆👍 Genau das wollte ich wissen.

 

vor 7 Stunden schrieb Philbert:

Offensichtlich haben die meisten hier mehrere Nodes angelegt. Warum macht das Sinn? Braucht jeder Node eine eigene Identity?

Weil's Spaß macht 😅 Storj ist ein sehr Interessantes aktives Projekt mit einer noch aktiveren Community. Und 'ne gute Anlage ist es auch noch.

Ja, für jeden Node umbedingt eine eigene Identity erstellen.

 

vor 7 Stunden schrieb Philbert:

Was spricht dagegen einen einzigen Node mit 30 TB zu machen?

Zum aktuellen Zeutpunkt würde es Jahre dauern bis der gefüllt ist.

Außerdem wird seitens Storj max 24TB pro Node empfohlen.

Bearbeitet 7. Dezember 2020 von Heisenberg420

[Philbert]

Ok, danke schonmal. Es ergeben sich dann doch noch ein paar Fragen.
Ich hatte eigentlich gedacht, das Storj Netzwerk würde die einzelnen Nodes entsprechend ihrer Internetanbindung und dem allokierten Speicherplatz unterschiedlich behandeln. Aber das ist wohl gar nicht so? Ist der erzeugte Traffic und die Datenmenge die gespeichert wird davon völlig unabhängig?
Wenn ja, könnte ich ja auch einfach mal einen 4 TB Node basteln und den Speicherplatz, falls er zu 70% gefüllt ist, einfach erweitern?
Der Docker Node lässt sich ohne Handarbeit offensichtlich nur einmal auf der NAS installieren. Aber ich hab noch Windows-Rechner die 24/7 online sind. Ich könnte also durchaus noch 1 oder 2 weitere Windows-Nodes installieren, die den Speicherplatz auf der NAS nutzen. Ich hab aber immer noch nicht verstanden, ob ich bei 2 Nodes im gleichen LAN zusammen mehr Daten bekomme als mit einem einzelnen Node.

Im Übrigen war es gar nicht meine Intension hier mit haufenweise Festplattenplatz den großen Reibach zu machen. Die NAS brauchte/wollte ich sowieso. Bei den Platten bin ich jetzt mehr oder weniger von Hölzchen auf Stöckchen gekommen: Erst wollte ich nur 2 kleinere Platten... dann hatte ich aber die Idee, lieber direkt größere zu nehmen um möglichst lange mit der Festplattengröße auszukommen. Dann hab ich gemerkt, dass ich doch einige TB im Haus verteilt habe, die ich zwar nicht zusätzlich sichern möchte, aber die ich auch nicht verlieren will. Also sollen die auch auf die NAS aber dann eben im RAID. Also nochmal 2 Platten geordert...
Dass das durch Storj nicht bezahlt werden wird ist klar ... aber wenn was zurückkommt wäre es natürlich trotzdem nett.

[skunk]

vor 4 Minuten schrieb Philbert:

Ok, danke schonmal. Es ergeben sich dann doch noch ein paar Fragen.

Fangen wir mit der offensichtlichen Frage an. Warum noch wach? Husch husch ins Bett mit euch  

vor 4 Minuten schrieb Philbert:

Ich hatte eigentlich gedacht, das Storj Netzwerk würde die einzelnen Nodes entsprechend ihrer Internetanbindung und dem allokierten Speicherplatz unterschiedlich behandeln. Aber das ist wohl gar nicht so?

Der Speicherplatz ist egal. Eine Node mit 5 TB bekommt genauso viele Daten wie eine Node mit 500 GB freien Speicher. Ansonsten gewinnt die schnellere Node. Ich habe sehr gute Erfahrungen mit ZFS und einer Intel Optane als Write Cache gemacht. Damit kann ich eingehende Daten zügig speichern und gewinne die Upload häufiger als mit meinem alten Setup bei gleicher Internet Anbindung.

vor 5 Minuten schrieb Philbert:

Ist der erzeugte Traffic und die Datenmenge die gespeichert wird davon völlig unabhängig?

Der Download Traffic skaliert mit belegten Speicher. Willst du mehr bezahlten Download traffic, brauchst du mehr belegten Speicher. Der Repair Traffic folgt je älter die Node ist. Am Anfang ist der Repair traffic zwangsläufig 0.

vor 12 Minuten schrieb Philbert:

Wenn ja, könnte ich ja auch einfach mal einen 4 TB Node basteln und den Speicherplatz, falls er zu 70% gefüllt ist, einfach erweitern?

Es macht keinen Unterschied ob du eine Node erweiterst oder einfach eine weitere Node startest. Ich lasse schon vorsorglich ein paar alte 1 TB Festplatten mitlaufen. So habe ich immer ein paar NodeIDs auf Vorrat um sie später auf größere Festplatten zu schieben. Kleiner Nebeneffekt ist, dass die alten 1 TB Platten so nochmal etwas Payout generieren können. Ich würde eigentlich erwarten, dass die alte Festplatte sich irgendwann verabschiedet. Bis jetzt deutet aber nichts darauf hin.

vor 20 Minuten schrieb Philbert:

Der Docker Node lässt sich ohne Handarbeit offensichtlich nur einmal auf der NAS installieren.

Es gibt inzwischen auch Linux Binaries. Du kannst das also auch ohne Docker machen. Egal ob mit oder ohne Docker du kannst in jedem Fall mehr als eine Node laufen lassen.

[GhostTyper]

vor 3 Stunden schrieb skunk:

Fangen wir mit der offensichtlichen Frage an. Warum noch wach? Husch husch ins Bett mit euch  

He, Moment, Du bist doch auch noch wach!

vor 3 Stunden schrieb skunk:

Ansonsten gewinnt die schnellere Node. Ich habe sehr gute Erfahrungen mit ZFS und einer Intel Optane als Write Cache gemacht. Damit kann ich eingehende Daten zügig speichern und gewinne die Upload häufiger als mit meinem alten Setup bei gleicher Internet Anbindung.

Also, ich möchte hier einwerfen, dass meine Tests etwas anderes sagen. Ich habe meine Nodes lange Zeit auf teurem SSD-Speicher gehostet, bevor ich die meisten davon dann auf Spindeln (HDDs im RAID) verschoben habe und der Performance-Unterschied zwischen Nodes mit SSD-Speicher und HDD-Speicher ist gleich 0.

Und mein SSD-Speicher ist deutlich schneller als der HDD-Speicher was Durchsatz und Latenz angeht.

[skunk]

vor 5 Stunden schrieb GhostTyper:

der Performance-Unterschied zwischen Nodes mit SSD-Speicher und HDD-Speicher ist gleich 0.

Solange du schnell genug bist Ja. Probleme haben eher die Nodes, die zum Beispiel ihre Daten auf ein Netzwerk Laufwerk schieben oder auf ein weniger performantes Dateisystem setzen. Diese und andere Fehler machen sich dann schon bemerkbar.

Das ganze ist ein Wettrennen. Du musst nicht mit SSD Speicher der schnellste sein. Du musst nur schneller sein als die letzten.

[Heisenberg420]

Am 8.12.2020 um 05:44 schrieb GhostTyper:

der Performance-Unterschied zwischen Nodes mit SSD-Speicher und HDD-Speicher ist gleich 0

Das habe ich damals auch festgestellt als ich für einige Zeit die Datenbank auf der SSD hatte. Es hat keinen Unterschied gemacht weshalb ich die Datenbank dann wieder zurück auf die HDD geschoben habe. So spart man sich eine mögliche Fehlerquelle. Es macht ja eh keinen Unterschied.

 

Ich hab auch lange überlegt meine zweite DSL Leitung auf 100Mbit zu upgraden. Es würde aber nichts ausmachen zum jetzigen Zeitpunkt. Dafür müsste ich dort schon mindestens 30TB+ stehen haben. Wenn es sich irgendwann lohnen sollte wären es mir die 5 Euro mehr aber locker wert.  Bisher sind meine 11Mbit Upload lange nicht ausgelastet.

Festplatten hab ich noch genug aber bei derzeitigen Ingress machts keinen Sinn mehrere Nodes an der gleichen IP füllen zu lassen. Gestern kamen im Schnitt nur 7GB rein inklusive Repair.

[skunk]

Jetzt verabschiedet sich bei mir die erste Festplatte. Die darauf befindliche Storage Node arbeitet erstmal noch normal weiter aber iowait geht durch die Decke. Vermutlich ist ein Sektor hinüber und ZFS hängt in einer Schleife fest und versucht den immer und immer wieder zu laden.

Jetzt muss ich timeout und retry runter setzen damit der Read mit einem Fehler abbricht und nicht im iowait fest hängt.

[GhostTyper]

vor 3 Stunden schrieb skunk:

Jetzt verabschiedet sich bei mir die erste Festplatte.

OH! Noooo...

Wann verbessert sich der Traffic wieder, @skunk?

Status ONLINE
Uptime 219h11m14s

                   Available        Used      Egress       Ingress
     Bandwidth           N/A     1.30 TB     1.05 TB     259.07 GB (since Dec 1)
          Disk       1.70 TB     9.30 TB

[skunk]

Am 18.12.2020 um 15:54 schrieb GhostTyper:

Wann verbessert sich der Traffic wieder, @skunk?

Meine Storage Nodes verzeichnen aktuell einen höheren Upload und Download Traffic. Das scheint aber nicht alle Satellites zu betreffen. Je nachdem wieviele Daten du von jedem Satellite hast, bekommst du eventuell auch nicht die gleiche Menge an Download Traffic.

Ich habe eine Vermutung wo der zusätzliche Traffic jetzt her kommt. Wir arbeiten aktuell an einem neuen Gateway. Eine erste Testversion läuft bereits und wurde schon von einer Handvoll Kunden ausprobiert. Ist aber noch etwas früh um dazu eine ernsthafte Aussage zu machen. Ich denke wir werden bald mehr erfahren.

[skunk]

Es lag am Ende nicht an der Festplatte sondern am Kabel. Im Moment verzeichnet mein System mehr Uploads und Downloads als üblich. Neu an dieser Situation ist, dass dieses mal eine Platte davon betroffen war, die bisher nicht genug Daten hatte um nennenswerte Last zu bekommen. Ohne Last macht das schlechte Kabel keine Probleme. Sobald aber Last auf dem System ist, scheinen Übertragungsfehler auf zu treten. Der SATA Kontroller kann diese bis zu einem bestimmen Punkt kompensieren in dem er einfach immer wieder anfragt. Irgendwann bekommt die Storage Node aber mehr Upload und Download Anfragen als mit dem schlechten Kabel transferiert werden können.

Einige mal Kabel und SATA Ports durch probiert und jetzt laufen alle 6 Festplatten wieder auf Voller Kapazität. Na dann lassen wir sie mal weiter laufen. Ich habe noch 2 Kabel vom gleichen Typ im System. Die werde ich wohl irgendwann vorsorglich mal gegen bessere Kabel austauschen müssen.

[Feres]

Hallo zusammen,

ich hab vor einem Jahr an zwei verschiedenen Standorten jeweils ein Storj-Node auf einer Synology-Nas installiert. Seither laufen sie problemlos vor sich hin ohne sie viel zu beobachten. Beide Nodes (16TB und  9TB) sind mittlerweile voll. Ich überlege sie nun mit bereits vorhandenen Festplatten zu erweitern. Hierzu müsste ich mich aber erstmal wieder mit der Materie beschäftigen. Ich erhoffe mir von euch daher ein paar Tipps, Schlagworte bzgl. der bestmöglichen Methode (best practice). Ich beziehe mich bei den Fragen jeweils auf ein Synology System.

 

Standort 1: 
An die Nas soll eine Erweiterungseinheit angeschlossen werden. Auf dieser wird ein separates Volumen (Volume2) installiert auf dem dann auch der zweite Node kommen soll.

Frage:  im Docker der Synology läuft bereits ein Storagenode und Watchtower Container. Jetzt müsste ich ja beide Container nochmal hinzufügen. Geht das so einfach, also das zweimal das gleiche Abbild installiert wird? Ich möchte ungern durch ein falsches Klicken meine bereits laufende Storj Anwendung zerstören.

Standort 2:
An der dortigen Nas muss ich den kompletten Raid auflösen. Um dies tun zu können würde ich den Node erstmal auf eine andere Synology-Nas übertragen, damit dieser während ich die alte Nas neu aufsetze weiterlaufen kann. Danach müsste den Knoten wieder auf die neu aufgesetzte Nas übertragen.

Frage: Ich hatte bereits gelesen, dass dies mit rsync möglich ist, korrekt? Gibt es hierzu eine kurze Anleitung? Wie genau geht man hier vor.

 

Vielen Dank im voraus!

Norman

[Heisenberg420]

Am 2.1.2021 um 10:37 schrieb Feres:

Jetzt müsste ich ja beide Container nochmal hinzufügen. Geht das so einfach, also das zweimal das gleiche Abbild installiert wird? Ich möchte ungern durch ein falsches Klicken meine bereits laufende Storj Anwendung zerstören.

Den Watchtower Container löschst du und fügst den neu hinzu und gibst dort einfach den weiteren Docker Namen an bzw. passt ihn an.

Hier ein Beispiel wie ich es an einer zweiten Location habe:

docker run -d --restart=always --name storj-watchtower -v /var/run/docker.sock:/var/run/docker.sock storjlabs/watchtower storjnode2 storjnode6 storj-watchtower --stop-timeout 300s

EDIT: Du kannst natürlich auch einfach einen zweiten Watchtower Container hinzufügen.

Dann einfach

docker run -d --restart=always --name watchtower2 -v /var/run/docker.sock:/var/run/docker.sock storjlabs/watchtower storagenode2 watchtower --stop-timeout 300s

 

 

Beim zweiten Docker Node musst du die Ports ändern.

    -p 28968:28967 \
    -p 14003:14002 \

Und natürlich den Pfad zur Identität und Datenordner + Docker Name anpassen.

    --mount type=bind,source="<identity-dir-node2>",destination=/app/identity \
    --mount type=bind,source="<storage-dir-node2>",destination=/app/config \
    --name storagenode2 storjlabs/storagenode:latest

https://documentation.storj.io/setup/cli/storage-node#running-the-storage-node

 

Am 2.1.2021 um 10:37 schrieb Feres:

Frage: Ich hatte bereits gelesen, dass dies mit rsync möglich ist, korrekt? Gibt es hierzu eine kurze Anleitung? Wie genau geht man hier vor.

https://documentation.storj.io/resources/faq/migrate-my-node#migrating-with-rsync

 

Den Node erst bei den letzten 2 durchgängen ausschalten. Offlinezeit ist aber derzeit auch kein Grund zur disqualifizierung. Mit dem nächsten Update wird aber für Offlinezeit die Suspendierung wieder eingeschaltet.

 

 

Am 18.12.2020 um 15:54 schrieb GhostTyper:

Wann verbessert sich der Traffic wieder

Sehr wechselhaft momentan. Wobei der Ingress sehr Low im Moment ist. Hoffe dass das mit dem neuen Satelliten wieder mehr wird.

Bearbeitet 4. Januar 2021 von Heisenberg420

[skunk]

vor 2 Stunden schrieb Heisenberg420:

Hoffe dass das mit dem neuen Satelliten wieder mehr wird.

Das war ein taktischer Fehler. Damit hast du persönliche Daten über dich preis gegeben. Gleich morgen werde ich die Weltherrschaft an mich reißen. Narf.

[Heisenberg420]

Ich meine vor einiger Zeit mal im Forum gelesen zu haben dass die ganzen Migrationen aufgrund eines neuen Satelliten statt finden oder gefunden haben. Das war reine Spekulation.

[skunk]

vor 9 Minuten schrieb Heisenberg420:

Ich meine vor einiger Zeit mal im Forum gelesen zu haben dass die ganzen Migrationen aufgrund eines neuen Satelliten statt finden oder gefunden haben. Das war reine Spekulation.

Verdammt dann wird das heute nichts mehr mit der Weltherrschaft. Ich hatte dir unterstellt im Forum schon den Draft für das Changelog gesehen zu haben.

[Heisenberg420]

Da hatte ich ehrlich gesagt gar nicht dran gedacht, ich hab noch nicht lange den Status.

Aber es war vorrauszusehen dass für den Stefan Satellite ein neuer kommt. Ich hoffe dass es nun nicht an meiner Aussage lag dass die Neuigkeiten schnell bekannt gegeben wurden 😮😅

[skunk]

vor 1 Stunde schrieb Heisenberg420:

Ich hoffe dass es nun nicht an meiner Aussage lag dass die Neuigkeiten schnell bekannt gegeben wurden 😮😅

Nein. Wir verfolgen da den Ansatz, dass wir eigentlich alles mit der Community teilen solange es keine Gründe gibt es geheim zu halten. Es ist ohnehin in der Github Historie zu sehen was voraussichtlich ins nächste Release kommt. Ich fasse den Teil nur zusammen und schreiben daraus ein kleine Changelog. Die Information ist zu diesem Zeitpunkt so oder so schon öffentlich nur vielleicht nicht für jeden abrufbar.

Die Verzögerungen sind leider notwendig weil der neue Satellite noch nicht so läuft wie gewünscht. Ich habe den zuständigen Entwicklern schon meine Meinung dazu gesagt. Es läuft bereits besser als beim letzten mal (ohne jetzt zu sagen welches Thema das damals war) aber da ist noch ein wenig Verbesserungspotential drin sodass wir beim nächsten mal nicht so viele Point Releases hinterher schieben müssen.

[skunk]

Wer hat lust einmal im Testnet zkSync aus zu probieren? Gibt es irgendwelche Fragen zu dem Thema?

[micro1]

@skunk kannst du erklären wie Storj es geschafft hat US Gesetze zu umgehen bezüglich Cloud Act. 

[skunk]

vor 45 Minuten schrieb micro1:

@skunk kannst du erklären wie Storj es geschafft hat US Gesetze zu umgehen bezüglich Cloud Act. 

Der Cloud Act sagt ja nur, dass Storj den US Behörden unter Umständen Zugriff geben muss. Was sollen die US Behörden aber mit verschlüsselten Dateien anfangen, die selbst Storj nicht entschlüsseln kann? Sogar der Dateiname ist verschlüsselt.

Darüber hinaus ist Storj kein reines US Unternehmen sondern ein globales Unternehmen. Was hindert Storj daran nicht einfach seinen Firmensitz nach Deutschland zu verlegen und trotzdem weiterhin die US Entwickler für ihre Dienste zu bezahlen? Muss sich das deutsche Unternehmen auch an den US Cloud Act halten nur weil US Entwickler am Projekt mitarbeiten?