My dream is that Storj would make it very easy for us (SNOs) to use our token earnings to pay for storage on the Storj network. By “very easy,” I mean that Storj could directly take payment from undistributed payouts and estimated earnings for the current month, before resorting to other payment methods like credit cards or external wallets.
This way, SNOs could reinvest their earnings seamlessly, without the friction of manual transactions or conversions. It would also be a great incentive to actively use the platform and experience it from both sides—as a provider and as a customer.
Ideally, we’d see an option in the billing settings to toggle “Pay for storage from SNO earnings.” Once enabled, it would prioritize using earned STORJ tokens for payments before turning to other payment options. Additionally, I think cunoFS should be free for SNOs—after all, providing storage should come with perks that allow us to leverage the ecosystem ourselves.
If these features were in place, I would definitely move my daily backups to Storj without hesitation. It would be a win-win: encouraging more SNO engagement while growing the overall usage of the network.
What do others think about this idea? Would it be feasible from a technical or financial standpoint for Storj to implement?
First of all, @PieceKeeper your post is a bit off topic in this thread, I expect mods will move it into its own or another already existing appropriate thread soon.
Please note that you can already essentially achieve this functionality by choosing STORJ as your payment method in your Storj Account, then copying the STORJ deposit address that is assigned to your account and pasting it into your Storage Node configuration to be used as your payout wallet address.
Your node payouts will then be used toward paying any usage on your Storj Account, and only if your STORJ balance is insufficient to cover all usage charges will any secondary payment method you have on file, such as a credit card, be used to pay the difference. You will not have to pay any gas fees for depositing the STORJ tokens you earned from running your node(s) into your Storj Account deposit address.
Note that Storj will not make payouts based on estimated earnings of the current month, payouts are on a monthly basis, if your earnings are above the respective payout threshold, or held back until the next month, same as if you used your usual payout wallet address to receive your node earnings. You can also still opt in to zksync Era in order to qualify for more frequent payouts, as Storj accepts both Layer 1 ERC20 STORJ deposits as well as Layer 2 zkSync Era STORJ deposits.
All of this is already possible today, even before storj and cunoFS.
You boot your system via tftp from a nearby (or even remote) server,
,the os mounts cloud storage with rclone with local vfs cache, and you have your bottomless disk.
You were so preoccupied with what you could do that you did not stop and think on whether you should
For this to be effective you need some local caching and/or plenty of ram. 128GB SSD is vastly cheaper than even 8GB of ram, and can fit multiple OS installs. So what would be the point in keeping OS in the cloud, only to download and cache most of it locally anyway?
Local OS is disposable, and best kept local. Data can totally live over cunoFS and Storj. In fact, I’ve been using similar setup of ages – it works very well.
I expect cunoFS to work much better/provide more seamless and compatible FS virtualization, and STORJ to provide excellent connectivity – so this is great news overall of course.
Thanks @heunland for your response! I appreciate the detailed explanation, though I see some challenges with the current possibilities.
The majority of the earnings of new nodes are withheld, which makes it difficult for new SNOs to use their earnings to pay for storage, which is the situation I am in.
The core of my suggestion is to make it a genuinely effortless experience where new SNOs can immediately reinvest what they’ve earned into storage—without thresholds, withholding periods, or manual steps. Ideally, I envision a toggle or setting that automates this completely.
I’m curious whether something along these lines might be considered.
The current process is already very convenient as it is, it does not require any manual steps beyond what you would have to do to define any other wallet address. There are no plans currently to change the way the held back amount works (it may become higher priority in the future) and currently there is not sufficient demand from node operators to use their earnings to pay for using Storj services to warrant investing dev time into the features you are asking for. You can submit them as idea/suggestion on the appropriate forum thread so others can vote to indicate their support for your idea.
Storj is focused on integrating Storj storage with CunoFS and Valdi now, these integrations will allow us to attract more enterprise customers, who in the end are the source of the earnings for our SNOs. Adding the feature you are suggesting is not expected to result in a significant increase in revenue at this time.
i have fantasies … of using home OS setup (with all its installed programs) no matter what PC/Laptop currently at hand!
You know Landing in some Thailand, buying a laptop for $300 and launching my default OS by one button press with all my files just like it was home.
Or to be immune to any hardware failure, or immune to data compromised in case of robbery. (So the data isn’t even on the disk, encrypted, but in cloud)
We’ll veer way off topic here, but you can already do that (and, coincidentally, I do both)
run the machine in the cloud, and connect to it via RDP or VNC from anywhere, including concurrently. This is what many companies do – run stuff centrally, and deploy “thin clients”. In fact, you can take next step and remove the need for RDP/VNS/Desktop – use apps remotely. See the translation from Microsoft Office apps to office365 entirely in the cloud as an example – all you need is a browser and no matter where you are you can continue working on your files. You don’t really need a desktop experience here – but if you want to – you can.
my main computer is macOS, and all data is in the iCloud, including apps, their settings, passwords, etc. So if my machine burns in flames now – I just get another one, login to it with appleID, and continue as if nothing happened, all data available on-demand, and end-to-end encrypted. This gets you performance of the local machine and infinite storage on the cloud. Which one is better – thin client vs local compute power just boils down to how much you trust your provider: you can encrypt all data end-to-end, but if you want to run VM on google cloud and the likes – you have to give up end-to-end encryption.
But both setups assume you have bootable local OS first, to facilitate thin client or barebones OS install.
I guess you can get as close close to this as it gets by keeping VM image on the cloud, using sparse mounter, and running it in local VM hypervisor. For this the filesystem most certainly will need to support features that are hard to impossible to implement with the cloud mounted filesystem without caching substantial part of data locally (mmap is one example). I’m curious how and whether cunoFS handles that.
