Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Webfs: A Filesystem Built on Top of the Web

github.com

Post reply on HN
Print view View original

11–20 of 59 posts

Re: Webfs: A Filesystem Built on Top of the Web

#11

Post by jerry292 »

mirimir wrote: post #9
jerry292 wrote: post #4

Earlier quoted context omitted.

I read you use IPFS. To my knowledge everything on there can be encrypted however not private. Is there a specific way you get around that.

What do you mean by "private"? I mean, if it's securely encrypted, does it matter if others can see it? And indeed, if it's online, you must assume that others can see it. My privacy concern is about IP addresses. So I'd want to use IPFS with Tor onions as stores.

Well I fear even if the information is encrypted alone once quantum computing breaks modern AES encryption standards that’s going to be a yikes. So I’d be more comfortable with encryption as well as access controls.

Re: Webfs: A Filesystem Built on Top of the Web

#12

Post by brendoncarroll »

mirimir wrote: post #8
brendoncarroll wrote: post #3

Hey everyone, I'm the author of WebFS. Happy to answer any questions.

ELI5 please. Where is the data for all of those IPFS hashes stored? And what ensures that it will persist?

WebFS stores data in things it calls "Stores". Stores can be anything that takes data and gives back a key to retrieve the data. Right now we have an IPFS and HTTP store built. An FTP server could also work as a store.

If you or a friend run the HTTP or FTP server then it will persist the data for you. IPFS doesn't incentivize data persistence so if WebFS is working on top of IPFS it inherits that problem. You could run WebFS on top of one of the storage networks and persisting your blobs would be incentivized.

WebFS is storage layer agnostic. Give it a Store, and it will give you a file system.

Re: Webfs: A Filesystem Built on Top of the Web

#13

Post by layoutIfNeeded »

toomim wrote: post #5
brendoncarroll wrote: post #3

Hey everyone, I'm the author of WebFS. Happy to answer any questions.

One issue that networked filesystems have is with mutations, especially with multiple writers. WebDAV, NFS, etc. try to address this with locking, but that doesn't allow simultaneous writes, which means it's dangerous to work offline. It's possible to solve this by using an OT or CRDT algorithm behind the scene. This is what we are building into an extension of HTTP called braid ( https://braid.news ). It could be us…

Thanks for the shameless plug, but what does this have to do with WebFS?

Re: Webfs: A Filesystem Built on Top of the Web

#14

Post by mirimir »

jerry292 wrote: post #11
mirimir wrote: post #9

Earlier quoted context omitted.

What do you mean by "private"? I mean, if it's securely encrypted, does it matter if others can see it? And indeed, if it's online, you must assume that others can see it. My privacy concern is about IP addresses. So I'd want to use IPFS with Tor onions as stores.

Well I fear even if the information is encrypted alone once quantum computing breaks modern AES encryption standards that’s going to be a yikes. So I’d be more comfortable with encryption as well as access controls.

I guess. But access controls really just keep the punters out. Any serious adversary will just track down the stores. And even if they're on dedicated servers with FDE, keys can be obtained from RAM.

Re: Webfs: A Filesystem Built on Top of the Web

#15

Post by mirimir »

brendoncarroll wrote: post #12
mirimir wrote: post #8

Earlier quoted context omitted.

ELI5 please. Where is the data for all of those IPFS hashes stored? And what ensures that it will persist?

WebFS stores data in things it calls "Stores". Stores can be anything that takes data and gives back a key to retrieve the data. Right now we have an IPFS and HTTP store built. An FTP server could also work as a store. If you or a friend run the HTTP or FTP server then it will persist the data for you. IPFS doesn't incentivize data persistence so if WebFS is working on top of IPFS it inherits that problem. You could…

OK, cool. I understand now.

So if WebFS is running on a system with access to Tor SocksPorts, can Stores be onion URLs?

Edit: If not, one could presumably route WebFS through OnionCat's IPv6 /48. But that only works with v2 onions, which are deprecated. However, tinc works with v3 onions. And either of those gives you UDP transport.

Re: Webfs: A Filesystem Built on Top of the Web

#16

Post by brendoncarroll »

jerry292 wrote: post #11
mirimir wrote: post #9

Earlier quoted context omitted.

What do you mean by "private"? I mean, if it's securely encrypted, does it matter if others can see it? And indeed, if it's online, you must assume that others can see it. My privacy concern is about IP addresses. So I'd want to use IPFS with Tor onions as stores.

Well I fear even if the information is encrypted alone once quantum computing breaks modern AES encryption standards that’s going to be a yikes. So I’d be more comfortable with encryption as well as access controls.

This is a legitimate concern. WebFS is designed for the p2p storage use case. Persisting data with p2p storage means that it can live forever. All the secrets in WebFS are randomly generated and there are no user supplied (potentially weak) passwords.

w.r.t. quantum computing: it is possible for WebFS to use symmetric cryptography for all remote data. Although, many Cell implementations in the near term will likely use elliptic curves or RSA.

Re: Webfs: A Filesystem Built on Top of the Web

#18

Post by tootie »

Eikon wrote: post #7
tootie wrote: post #2

Remember WebDAV? It was a similar concept, but never really found its footing and most of the implementations were pretty shaky. I always thought it was a good idea though. https://en.wikipedia.org/wiki/WebDAV

The rfc is super dumb though. For instance, when handling a PROPFIND request (more or less listing files / folders), it’s not mandatory for the server to honor the Depth header (how many levels are returned). There is also no mechanism for the server to advertise whether or not it’s honoring the Depth header. That means the Depth header is useless because the client has no way to know whether there was only one hiera…

There was an even worse protocol back then called CMIS. It was an attempt to define a standard API for content management which turned into this absolute enterprise monstrosity that would make SOAP blush. It was also impossible to implement.

It's interesting looking back but I think developing a standard has a higher chance of success coming from some dude's GitHub than it does with $1T of market cap behind it.

Re: Webfs: A Filesystem Built on Top of the Web

#19

Post by brendoncarroll »

mirimir wrote: post #14
jerry292 wrote: post #11

Earlier quoted context omitted.

Well I fear even if the information is encrypted alone once quantum computing breaks modern AES encryption standards that’s going to be a yikes. So I’d be more comfortable with encryption as well as access controls.

I guess. But access controls really just keep the punters out. Any serious adversary will just track down the stores. And even if they're on dedicated servers with FDE, keys can be obtained from RAM.

Just to clarify: All data is encrypted on the client, going after a server backing a Store will get you encrypted blobs. Encryption keys would not exist on the server in plaintext.

Re: Webfs: A Filesystem Built on Top of the Web

#20

Post by sp332 »

mirimir wrote: post #10
brendoncarroll wrote: post #6

Earlier quoted context omitted.

Yes. WebFS doesn't actually use any of the file/directory functionality provided by IPFS, or any encryption features. We only use the get/put block functionality. Everything is encrypted in WebFS before being posted to a Store. The data encryption keys are generated using a secret and the hash of the data being encrypted. That key is stored in the reference to that data. This continues recursively to the superblock w…

Can one use Tor onions as stores?

Tor is a network layer. It doesn't really store anything.
Post reply on HN