That makes sense on the very surface, but eventually someone's going to lose their config, and all their orphaned storage is just occupied forever in the rest of the group.
I'm pondering an "anti-challenge" primitive, whereby storing nodes can ask the original writer to confirm that it still has the stub file. (Because if that's lost, the data can't be decrypted anyway, there's no point to still saving it.) And if that fails for X months in a row, sorry, time to go. Or maybe raise it for manual review so the node operator can check in with the others before pushing the "reclaim storage" button.
> storing nodes can ask the original writer to confirm
As law enforcement, I would love to know that the existence of encrypted data on your hard drive implies an active, ongoing contact with the online node that bears the key.
Very interesting concept. This has also already been implemented in Tahoe LAFS (www.tahoe-lafs.org) but for some reason it was never really adapted for something that scales beyond local networks.
I always thought that this would be an awesome idea since a lot of people already operate their own NAS, oftentimes with spare disk space that could be used as intended by this project, but don't want to pay additionally for some cloud provider for a decentralised backup.
> more aligned to the internet in the early days when there was more trust.
please for the love of alan turing understand that trust happens iff there are reasonably-enforceable boundaries, and "oh we're friends, let's opt out of reasonable information-theoretic security primitives" is not a healthy or friendly behavioral pattern.
/ if your PKI is so obnoxiously difficult to set up correctly that people are inclined to skip the crypto altogether, please get help.
sorry for the grouchy tone, I'm just sick of hearing software engineers pretend that shoddy quality control issues and products riddled with security holes is somehow positive.
Add a 'high-water' configuration option which, if reached during a file create/copy operation, prompts the user to Authenticate with 2FA and approve the extended budget.
I'd be okay with this feature if I got a 2FA alert that something 'big' was about to happen, and could approve/deny it in realtime when it happens.
> only lets the original writer delete a shard.
That makes sense on the very surface, but eventually someone's going to lose their config, and all their orphaned storage is just occupied forever in the rest of the group.
I'm pondering an "anti-challenge" primitive, whereby storing nodes can ask the original writer to confirm that it still has the stub file. (Because if that's lost, the data can't be decrypted anyway, there's no point to still saving it.) And if that fails for X months in a row, sorry, time to go. Or maybe raise it for manual review so the node operator can check in with the others before pushing the "reclaim storage" button.
> storing nodes can ask the original writer to confirm
As law enforcement, I would love to know that the existence of encrypted data on your hard drive implies an active, ongoing contact with the online node that bears the key.
that is an issue, your anti challenge is a great idea.
Very interesting concept. This has also already been implemented in Tahoe LAFS (www.tahoe-lafs.org) but for some reason it was never really adapted for something that scales beyond local networks. I always thought that this would be an awesome idea since a lot of people already operate their own NAS, oftentimes with spare disk space that could be used as intended by this project, but don't want to pay additionally for some cloud provider for a decentralised backup.
How do you prevent storage exhaustion attacks if a "friend" decides to dump encrypted garbage on your peer node?
It is an idea at the moment, more aligned to the internet in the early days when there was more trust.
As for your question there are ways to mitigate that type of problem, joining fee maybe?
> more aligned to the internet in the early days when there was more trust.
please for the love of alan turing understand that trust happens iff there are reasonably-enforceable boundaries, and "oh we're friends, let's opt out of reasonable information-theoretic security primitives" is not a healthy or friendly behavioral pattern.
/ if your PKI is so obnoxiously difficult to set up correctly that people are inclined to skip the crypto altogether, please get help.
sorry for the grouchy tone, I'm just sick of hearing software engineers pretend that shoddy quality control issues and products riddled with security holes is somehow positive.
Add a 'high-water' configuration option which, if reached during a file create/copy operation, prompts the user to Authenticate with 2FA and approve the extended budget.
I'd be okay with this feature if I got a 2FA alert that something 'big' was about to happen, and could approve/deny it in realtime when it happens.
[dead]
do this with an acual friend.
yes and no