Nostr Web Client

I think that is fine. I however don't like the idea of many servers... users (including me) won't enjoy managing all these relationships.

I am not talking about the multiple providers here, for this people can run a mirror on their own device or use a friend as a backup.

I am talking about Blossom being insufficient alternative to Proton Drive or even WebDav... so now if you need end to end encryption and sorted key value store or filesystem semantic... you have to either build that on Blossom only to realise it is a bad design since the server is not doing its part of enforcing access control OR you have to build entirely new kind of servers.

My point is, everything Blossom (or any content addressable chunks server) can do, Proton Drive servers can do, but not the other way around.

So why bother with Blossom at all? Yes they are simpler, but they are not complete and the need for the complete solution doesn't magically disappear just because you wish you didn't need them.

So you tell me, if there was an open alternative to Protons Drive, wouldn't keychat apps benefit from that in ways Blossom can't help with?

Keychat 7mo ago 💬 2

We have considered three scenarios:

The first scenario is hosting images and videos used in chat rooms. These need to be end-to-end encrypted and stored for about one or two weeks. Users typically access them only once within the chat room. No separate interface is needed—configuration can be done in the chat settings.

The second scenario is hosting images and videos for microblog posts. Since they are meant to be viewed by followers, encryption is not necessary, and the files should be stored for a long time. No separate interface is needed—configuration can be done in the microblog client, similar to setting a relay.

The third scenario is backing up important files. These must be end-to-end encrypted, stored for a long time, and require a dedicated interface to display all saved files.

For the third scenarios where files need to be end-to-end encrypted, our idea is to perform the encryption on the client side before uploading. We hope to see a Mini App like this, where users can log in using their own key pair and optionally pay with their wallet.

Reply to this note

Please Login to reply.

Discussion

Nuh 7mo ago 💬 1

You are under selling the need for ordered key value store or a filesystem interface.

Without this consistency of an ordered yet e2e encrypted lists, plenty of apps are simply impossible, unless you fake it using a mutable file and embed an sqlite file in there, however this will suck ass to maintain AND Blossom doesnt have mutable files at all.

Think; how do you build every app in Google suite or Proton Drive apps without this ability?

Or think instead; why do we have filesystems and BtreeMaps if we can build apps with random immutable files?

Finally; you can't slap privacy on top ... it is the HARDEST part, someone has to build this once for everyone and servers have to be involved.. think of all the access control and key management and defense in depth where servers don't give encrypted files to random people even if they can't decrypt it, because eventually they might be able to... etc.

My point is, Blossom won't cut it. If you insist on using it because the availability bias... fine, but maybe check Peergos to get an idea on what can be done.

Keychat 7mo ago 💬 2

Thank you for your analysis and suggestions. Blossom is mainly designed for storing public, unencrypted files.

One more question — are you satisfied with how Blossom performs in the second scenario?

Nuh 7mo ago

Yeah they are alright for public immutable files .. that's what they were designed for and they do well.

But the exact same feature could be achieved with WebDav... so I am not really sure what does Blossom offer more than the ancient and equally simple WebDav... even if you wanted to use nostr keys instead of web fingers or usernames, you could fork a webdav server to support that in a weekend, and you get all the webdav features while at it.

Vitor Pamplona 7mo ago 💬 1

I am quite satisfied with blossom storing encrypted files for nip 17. Not all providers support encrypted blobs, but it works great on those who do.

Nuh 7mo ago 💬 2

Good for you, but that is not what I am talking about, encrypting blobs is easy even on client side and a dumb server, but that is too far from an e2e encrypted filesystem where key management, access control and granting and revoking access is neatly packaged in an SDK.

That is what I am talking about and it is the necessary (and sufficient) feature to build any cloud application where the user come with their own storage... I know that because every Google/Proton Drive provider immediately starts offering stuff like Docs and Sheets etc. Because they can.

Now you can use blobs on Blossom to make up a Cryptree like Peergos, but Blossom is not smart enough to help you with access control (beyond encryption, which is imprtant), and not smart enough to handle the difficult key sharing story, and most importantly it is not smart enough to know what nodes in that tree needs to be deleted to reclaim storage.

If you don't feel the need for an e2e2 key value store or filesystem... then you are not building the apps that do, my point was if we are going to build an open storage protocol, might as well build what is necessary and sufficient for any app that is analogous to native apps but with cloud storage instead of local storage, instead of building Blossom then realising it is not good enough later.

As usual, I invite you and others to look at Peergos or just imagine what you would build if every user had a sovereign version of Proton Drive with open API.

Nuh 7mo ago

nostr:nprofile1qqsyvrp9u6p0mfur9dfdru3d853tx9mdjuhkphxuxgfwmryja7zsvhqppemhxue69uhkummn9ekx7mp0qyghwumn8ghj7mn0wd68ytnhd9hx2tc42aswu of course, there are apps that cant be built even with a Proton Drive like API. Most notably apps like Twitter or any app that needs aggregation of data authored by multiple people and custom API endpoints that are tailored to the UI needs (backend for frontends) ... but I always argued that these are lost cause.

I just want to see something like Proton Drive but open for all quiet apps to flourish there... I dont want the next Obsidian to be closed source, nor its cloud sync to be centralised.

Vitor Pamplona 7mo ago 💬 4

Sure, but that is just a secret management scheme. You can do that regardless of which encrypted blob server protocol you choose. Now that frost can decrypt files with sharded keys, it's just a matter of time until we get a signer that can coordinate secret sharing between many keys.

Nuh 7mo ago 💬 1

You are wrong, but hey, try it and see if you can build an encrypted filesystem on Blossom without changing Blossom and without asking clients to do prohibitively complex work on their side, and while reclaiming storage from previous overwritten state.

Sure your needs might be limited that you can come up with ad hoc ways to satisfy them with Blossom only and few extra tricks on top, but you can't solve for the general problem without servers helping.

I can write about all the challenges involved in a more coherent manner, but honestly I am not sure anyone cares. So it is one of these things where I have to just build what I want and if people think it is valuable they can help themselves to it.

That being said, even without encryption I think I did a very good job while working on Pubky combining WebDav with cryptographic identity and authentication, and people can use that or learn from it if they want. Or not.

AU9913 7mo ago 💬 1

How does peergos compare to Nextcloud when self hosting?

Nuh 7mo ago 💬 1

I am not aware of people self hosting.. but it should be doable it is open source and it should work just fine.

The main downside of peergos is a centralised PKI, but we know how to fix that. And Peergos developers will add something similar to Pkarr eventually.

Keychat 7mo ago

Peergos is based on IPFS. I don’t know much about it — do you think IPFS is actually viable, or is it just a nice idea?

Vitor Pamplona 7mo ago 💬 2

Did you forget I work on health care? Sharing encrypted files, dynamically adding and removing permissions to them is where I spent most of my career. Blossom is fine. Can we do better? Sure. But at what cost? I am not convinced there is any need to make things a lot more complicated just for the sake of sharing permissions to access files. The more complicated these systems get, the worse it is for security and privacy of that data. And usually vendors that are pitching complicated systems are either centralizing things on themselves or finding shady ways to get access to some of the data to sell later (by logging the transport layer, for instance).

Yes, a LOT of functionality can be added to these types of things. But I have not seen anyone actually asking for them on Nostr yet. Which means it might just be middle management bloatware.

Nuh 7mo ago

I don't know how to argue with "no one asked for it on Nostr yet" when I am asking for them, and literally millions of people are spending arguably too much money for Proton Drive to have exactly what I am asking for but without the open API.

But again, if you don't care, you don't care, ain't no arguing with that.

Vitor Pamplona 7mo ago 💬 1

I think an online personal file storage system would be great to have. But the way Google Drive and proton drive work is not good. They are designed to let the company control such files. I think we need a new take that gives more control to users. A private blossom server, where you can have decrypted files for yourself could be a simpler start. If it is not about sharing access to them, all it needs to do is to sync between devices. If it is about sharing access or even enable collaboration (allowing friends to save into your space), then I would say that it is a different solution and it might be a different app just for that.

Nuh 7mo ago

Sharing write access is not the only hard part, sharing read access in scalable and UX friendly way is also insanely hard and this "Blossom is fine" won't magically make it fine.

You can't achieve all this client side. You can't build all these features with only the feature set that Blossom provides... the server needs to understand the format you are using to manage this encrypted filesystem to be able do important tasks like storage reclamation and access denial even for things that are encrypted.

I never said we need to build things like Google, I only said Blossom won't cut it, the full access control of read and write and managing that with filesystem semantics in a UX friendly way is hard work that is inherently complex yet I insist it is necessary for most applications and without it you don't have an open cloud platform.

I am not sure what is the disagreement here. My best guess is that you think you can build this on Blossom, I disagree.

Big Bad John 7mo ago 💬 1

fwiw we are currently working on private data primitives in R&D, so we will see some capabilities there for Pubky this year. (This is aside from Corey's recently vibe-coded PMM release.)

Nuh 7mo ago

It is easy to make primitives that qualify as private in some definition of privacy, but the full solution that I am talking about and that Peergos has is quite difficult and the incentives for putting that effort is not there in Pubky given that the main app doesn't need it (most features can be satisfied with simpler less disruptive solutions), but it sure needs other things and will compete for resources.

More importantly, unlike the current state of pubky core, if you want to achieve what Peergos does, clients will have to get more complex (to manage Cryptrees, remember that name? :'D), in fact they will get so complex that client side signing will become a no brainer as the simplicity that justifies the current sessions model will go away.

If you still are willing to go that painful route, I think you should contact Ian Preston and ask him to consult for that transformation, since he has been there and done that. And I talked to him enough that he understands what Pubky core is.

Or wait till I get bored enough and start implementing all of this myself and see if there are good ideas there you want to copy.

Best of luck anyways.

Nuh 7mo ago

If i understand correctly encryption and decryption with FROST would be asymmetric.. which is not efficient, it would be fine for sharing the symmetric key... but the hard part isn't encrypting a symmetric key for the target receiver... that the easiest part to be honest.

The hard part is when you need to revoke someone access from an entire directory... and now you need to reencrypt everything on write, and you need to share the new keys to all the remaining members and you need to do all of that from an interface that is not any more complicated than Google Drive sharing settings.

Then you need to delete all the previous chunks of the filesystem tree to reclaim the storage. And if you have a builtin history system things get even harder as new keys should be able to decrypt old files but not vice versa.

I am sorry but these problems need to be solved cohesively otherwise you don't have a platform. Access control is not a plug in on S3, it is inherit and it makes or breaks the platform that became later a standard.

Nuh 7mo ago

Addressing files by their hashes only serves popular content so people can share it trustlessly ... user storage on the other hand will be shared by no one.. it is only going to be read by the user and those who get links to these files... so what Blossom does doesn't achieve anything but make most apps harder to implement... even WebDav was better.

Even if you manage to build an interface on top of this, it will be horrendous, because you will have to deal with garbage collection on the client side. Because only the client know which blocks no longer needed for the latest version of the state of the filesystem, Blossom itself doesn't have this information... and leaving garbage collection/storage reclamation to applications is not a good idea.