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.

Reply to this note

Please Login to reply.

Discussion

How does peergos compare to Nextcloud when self hosting?

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.

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?

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.

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.

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.

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.

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.)

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.