Would you switch Anon?
#asknostr
Discussion
Encrypted storage of what? Files? That would probably be via Blossom rather than Nostr.
Thing is, if I want to have private and encrypted file storage that I can access from anywhere, that's what my home server is for. Don't really need a "cloud" option except perhaps as a redundancy, since I run my own "cloud."
I use Blossom to store files I want to share with others on Nostr, so encryption isn't necessary for that use-case most of the time. The exception would be for sharing a file via DM that I ONLY want the receiver to have access to.
Extending the above:
I am not sure how much the total users of smart phones have their own cloud. I would guess, not too much.
So having a cloud service replacing their proprietary one, would be a good start for people who do not have the knowledge so far to run their own servers.
Also having such thing, would allow you to have such servers locally, and use it transfer files e.g. between your devices without internet.
The cool thing about having a layer like this, with the nostr level abstraction, is that it is easy to switch, and gives superpowers to apps with interop.
Also other benefit:
If services optimize for using something through a nostr cloud interface lets say, such as password manager, DMs, image upload, etc. Then you can easily plug in your home instance, and everything works out of the box, but you are more private/less dependent on external stuff.
So it can aid an easy switch for more sovereignity.
> "I am not sure how much the total users of smart phones have their own cloud. I would guess, not too much."
You're absolutely correct there. The question you asked was "Would you switch Anon?" So I was answering from my own perspective. I would not, but that doesn't mean it wouldn't be useful for those who won't or can't run their own home server.
> "Also having such thing, would allow you to have such servers locally, and use it transfer files e.g. between your devices without internet."
If you're going to run such a server locally, it's probably best to just run a home server. That said, I could see it being easier to just run a program on your PC that turns a directory on it into a local cloud that can be accessed by other devices on the local network.
> "The cool thing about having a layer like this, with the nostr level abstraction, is that it is easy to switch, and gives superpowers to apps with interop."
The power of protocols, for sure! Build an app that "speaks the same language" as the server that has the data, and your users can easily connect your app with their data, secured with their private key.
Not sure I would want to tie something like this to my Nostr keys, though. Or at least not to the same key I use for social media clients. We've seen already that keys can easily end up compromised, and if using this with encrypted file storage, a compromised private key would mean anyone who got access to it would also have access to your encrypted files.
Yes, that would make it less convenient, but it also depends on what types of files you are storing and how destructive to your life it would be if they were accessible by a malicious actor.
I think the benefit for you, without knowing what you self-host is, that you could use apps using your data storage, instead of proprietary e.g.: Email. Of course this needs the presence of data layer, plus new apps.
The running server locally, I meant like citrine. It would run on your phone, and you could share files with someone else on the go. But can also be an easy PC app. The idea behind this would be a way to support something similar like apple handsoff.
I was also thinking about the whatif of key compromise. I guess, you have the same with using a google account. But at least there "they can save you", but also "lock you". On the other hand, you can change passwords.
I would definitely not use the same keys.
Lets make a thought experiment.
Whatif
- you have "master key", "recovery key, "account keys" and "action keys"
- "master key" is your login, and it is not connected to any account.
- "recovery key", is to reset your account if you lose the "master key"
- account keys are the keys you post on behalf of
- "action keys", delegated keys to use inside apps (what nsecbunker and remote signers already do)
- you can make as much account and action keys as you want
- you can set max priviliges/allowed set of actions for all action keys, meaning all child keys can have a separate purpose. If they are lost, the damage is minimised.
I am using Nextcloud, which is open source and which can be accessed by an open protocol called WebDAV. Any application that "speaks" WebDav can be used with my Nextcloud server to access my files. It's pretty awesome.
Now, when it comes to something like Citrine, that can only store Nostr notes, which are all just json text files. You would need something a bit more versatile for storing other types of files, like a Blossom server. Of course, you would also want to have the ability to encrypt those files. I don't think Blossom would reject encrypted files, but encryption and decryption is done client side, so you would need to have a client that can encrypt the file before saving it to the Blossom server.
Now, things get really complicated when you start dealing with multiple keys and encryption. For any "key" that you want to have access to a file, you need to have a separate version of the file saved that has been encrypted to that key.
The other option is to have one key for encrypting files that gets shared to each user you want to have access to that file, but then you need to have the encryption done on a per-file basis, and have a way to securely get that file's key to the users you want to have access to the file. You cannot use the same key to encrypt multiple files or else giving the key to a user so they have access to one file will give them access to all files that use the same key, which may not be desirable.
I think you may not have a clear understanding how nsecbunker works. When you create a remote connection with nsecbunker, it's not really a "child" key that signs instead of your nsec. Instead, it's a separate set of keys that are only used for passing messages between an app that is requesting a signature and your signer application. The "payload" of the message being sent from the app to the signer is an unsigned Nostr note, and the signer then uses your regular nsec to sign it, not any child key or "action key" or anything else you want to call it. Your nsec is the only key that can sign Nostr notes for you, even when using a remote signer. Then the signer app just uses its key to send the signed note back to the app that made the request.
1. I also have a nextcloud. And also using WebDAV. Actually, it did not came to my mind to check how that works. Thanks for the hint.
2. I meant here if we have a nostr cloud solution, that apps use. Can store data on any nostr data storage/cloud. However we call it. Then we can just have a simple app like citrine, but for files like blossom. The voilá, you can transfer files with your local server instance without internet.
3. Good enrcyption is not easy.
4. What I meant here is, that nsecbunker has 1+n keys. 1 signs, rest can be created on the fly for all apps seperately, that is used only for communication with nsecbunker. Then bunker sings with the one and only. I would only extend it, with 2 things:
- There would be a "placeholder" account, that has multiple signing keys inside. The placeholder key is only used to manage your keys. (To have multiple keys, and a simple manner to manage them. But I mean, not really important, only if you want some features between accounts of same user.)
- Each connection key could have a max allowed actions. Like you say, it cannot decrypt dms. So if that is requested with that connection, the bunker just declines. (Minimize damage)