Oddbean new post about | logout
▲ ▼
laanwj | 1 months ago (raw) | root | parent | reply | flag 
 i dunno, blossom is mostly intended to host media for publishing, it's as far from a private E2E encrypted cloud as you can get
▲ ▼
Gzuuus | 1 months ago (raw) | root | parent | reply | flag +1 
 I remember that nostr:nprofile1qqszv6q4uryjzr06xfxxew34wwc5hmjfmfpqn229d72gfegsdn2q3fgpz9mhxue69uhkummnw3ezuamfdejj7qgjwaehxw309ahx7um5wf6k2tnrdakj7qg6waehxw309ac8junpd45kgtnxd9shg6npvchxxmmd9usc5pxf had some drive encryption spec for blossom, don't know the state of it rn. But yea is a complex problem
▲ ▼
hzrd149 | 1 months ago (raw) | root | parent | reply | flag +1 
 It was a really simple implementation. just encrypted the files by map of files with a password. probably worse than using an encrypted zip
▲ ▼
Gzuuus | 1 months ago (raw) | root | parent | reply | flag +1 
 Just reading the spec bud01 there is an optional authorization method: The server may optionally require authorization when retrieving blobs from GET /sha256, returning 401 if not properly authorized
▲ ▼
laanwj | 1 months ago (raw) | root | parent | reply | flag 
 sure, one could make storage/retrieval authenticated and end up with something like dropbox; files are encrypted in transport but the server can read them

the lack of partial updates (as they would change the SHA256 hash) would bring some inefficiency for cloud uses compared to other network file protocols

the E2EE layer exists on top of that, and that paper is about how it's very hard to achieve without leaks of some kind, so that's where the challenge starts 😀