Description: A remote app transfers data to Storj cloud via the Storj IPFS compatible gateway installed on a hosted server (public or customer cloud).
Primary Issue this pattern solves: When an IPFS node is backed by the Tardigrade Network, we are able to solve many of the problems that IPFS developers face; problems including
Key Implementation Details: The Storj IPFS gateway is installed on a web application server in the customer cloud or public cloud and accessed online.
The Storj Gateway is designed to upload/download data to/from multiple storage nodes in parallel. This bittorrent-like parallelism provides a sizable performance boost when transferring data. In this pattern, bandwidth is potentially costly as the data uploaded is ingress to the web server, but then egress from the web server to the Storj Network, including the erasure coding expansion data.
With this integration, the data is separated from the IPFS machine. So if the machine running the IPFS node is completely destroyed the data will still be recoverable by pointing a new machine (IPFS Node) at the Storj Network bucket that’s was used by the node that was destroyed.
Note: When it comes to reliable, performant, secure, and economical storage for decentralized apps, a direct connection to the native Storj platform via LibUplink is the more effective integration pattern.