diafygi

byoFS

HTML2014–2016

diafygi / byoFS

byoFS

Bring Your Own Filesystem

Systems & Infrastructure

Explore on GitHub Read Hacker News discussions

2Distinct people

8Mentions

0Explicit recommenders

69GitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

Bring Your Own Filesystem

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

remotestorage/remotestorage.js · linked in 2 of the same discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by month8 dated mentions

Observed mentions: 2014-06-17 12:44:03 UTC to 2016-05-01 00:40:41 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Comments
Jun 2014	2014-06-01 00:00:00 UTC	2014-07-01 00:00:00 UTC	2	2
Jul 2014	2014-07-01 00:00:00 UTC	2014-08-01 00:00:00 UTC	1	1
Aug 2014	2014-08-01 00:00:00 UTC	2014-09-01 00:00:00 UTC	0	0
Sep 2014	2014-09-01 00:00:00 UTC	2014-10-01 00:00:00 UTC	1	1
Oct 2014	2014-10-01 00:00:00 UTC	2014-11-01 00:00:00 UTC	1	1
Nov 2014	2014-11-01 00:00:00 UTC	2014-12-01 00:00:00 UTC	1	1
Dec 2014	2014-12-01 00:00:00 UTC	2015-01-01 00:00:00 UTC	0	0
Jan 2015	2015-01-01 00:00:00 UTC	2015-02-01 00:00:00 UTC	1	1
Feb 2015	2015-02-01 00:00:00 UTC	2015-03-01 00:00:00 UTC	0	0
Mar 2015	2015-03-01 00:00:00 UTC	2015-04-01 00:00:00 UTC	0	0
Apr 2015	2015-04-01 00:00:00 UTC	2015-05-01 00:00:00 UTC	0	0
May 2015	2015-05-01 00:00:00 UTC	2015-06-01 00:00:00 UTC	0	0
Jun 2015	2015-06-01 00:00:00 UTC	2015-07-01 00:00:00 UTC	0	0
Jul 2015	2015-07-01 00:00:00 UTC	2015-08-01 00:00:00 UTC	0	0
Aug 2015	2015-08-01 00:00:00 UTC	2015-09-01 00:00:00 UTC	0	0
Sep 2015	2015-09-01 00:00:00 UTC	2015-10-01 00:00:00 UTC	0	0
Oct 2015	2015-10-01 00:00:00 UTC	2015-11-01 00:00:00 UTC	0	0
Nov 2015	2015-11-01 00:00:00 UTC	2015-12-01 00:00:00 UTC	0	0
Dec 2015	2015-12-01 00:00:00 UTC	2016-01-01 00:00:00 UTC	0	0
Jan 2016	2016-01-01 00:00:00 UTC	2016-02-01 00:00:00 UTC	0	0
Feb 2016	2016-02-01 00:00:00 UTC	2016-03-01 00:00:00 UTC	0	0
Mar 2016	2016-03-01 00:00:00 UTC	2016-04-01 00:00:00 UTC	0	0
Apr 2016	2016-04-01 00:00:00 UTC	2016-05-01 00:00:00 UTC	0	0
May 2016	2016-05-01 00:00:00 UTC	2016-06-01 00:00:00 UTC	1	1

What Hacker News says

8 sources

nickpsecurity·May 1, 2016

Thanks for bringing the unhosted trend to my attention. I haven't heard of it. I'm a bit skeptical about the graphic in the front page given applications often need to perform computations on the data itself. There's probably something in the site that addresses that. I'll read it in a few days and then maybe look at your tool. Btw, you need to correct the WebCryptoAPI link in "Security and Philosophy" part of this page: https://github.com/diafygi/byoFS Clicking it gives me nothing. Copy-and-pasting the link results that resembles spyware. I think it's just missing a colon after http is all.

In Lavabit code open sourced

diafygi·Jan 25, 2015

Here's some projects you should check out: * RemoteStorage.js[1] (they plan on adding support for Dropbox, Drive, etc.) * CloudRail[2] (nonfree source) * CloudDock[3] (proxy service) * byoFS.js[4] (encrypted cloud storage, I maintain this) [1]: https://github.com/remotestorage/remotestorage.js [2]: http://cloudrail.com/ [3]: http://clouddock.co/ [4]: https://github.com/diafygi/byoFS

In Paperwork: An open source Evernote alternative

diafygi·Nov 4, 2014

There are several JavaScript projects that aim to let you connect your own storage from a varity of locations. They are still pretty early on in development, though. 1. http://remotestorage.io/ 2. http://cloud-rail.com/ 3. https://github.com/diafygi/byoFS Disclosure: I maintain byoFS.

In Amazon Prime Members’ Newest Benefit Is Free, Unlimited Photo Storage

diafygi·Oct 11, 2014

Looks neat! This sounds very similar to the concept of unhosted.org[1], where the user provides their own data storage location. Being based in Europe, have you had any interaction with the unhosted team or their remoteStorage.js[2] library? It seems like they are trying to integrate in Dropbox/GoogleDrive into that library, too. Also, you mention encryption in the Example Applications section. I've been working on a similar concept of having a client-side javascript library that creates an encrypted filesystem on Dropbox/Google Drive, called Bring Your Own Filesystem[3]. The most interesting thing with the system is that these storage locations allow for public files, which means you can set up end-to-end encrypted communication between two Dropbox accounts[4]. I'd love to learn more about your implementation of the encryption layer and

Read the rest

how you plan to develop that further. What plans do you have for privacy/encryption? [1] - https://unhosted.org/ [2] - https://github.com/remotestorage/remotestorage.js [3] - https://github.com/diafygi/byoFS [4] - https://www.youtube.com/watch?v=WTPimUSIWbI

In Show HN: One Adaptive API for Dropbox, Google Drive, OneDrive

diafygi·Sep 18, 2014

Heh, I do: https://github.com/diafygi/byoFS

In Keeping your stuff safe, simply

diafygi·Jul 2, 2014

Yes! The basic philosophy is called "unhosted"[1], and there are several libraries that are made to help build unhosted apps. For example, I made a library called byoFS[2] that let's users connect Dropbox as an encrypted data store. It has several proof of concept apps like an encrypted diary[3] and end-to-end encrypted chat[4]. [1] - https://unhosted.org [2] - https://github.com/diafygi/byoFS [3] - https://diafygi.github.io/byoFS/examples/diary/ [4] - https://diafygi.github.io/byoFS/examples/chat/

In Protecting Your Anonymity: A How-to for Sex Workers

diafygi·Jun 18, 2014

One aspect of in-browser functionality OP mentions is "offline". However, browsers are pretty cool in that they can mix offline and online. You can open a local html file and it can then make online requests. Alternatively, you can request an html file online that then can access local files. This ability to mix offline and online content is something that I think has a lot of potential to improve client-side encryption. Specifically, client-side encryption coupled with an unhosted webapp[1]. I've been exploring this potential for my byoFS[2] project, and made an example end-to-end encrypted chat demo[3]. You can request the app anonymously (or even save it and open it locally). The app then lets the user connect an online datastore (e.g. Dropbox) to save the encrypted chats. This separates who serves the anonymous static webapp and the a

Read the rest

uthenticated datastore, and makes it much harder to target a javascript attack (the most common attack from the Snowden leaks). [1] - https://unhosted.org/ [2] - https://github.com/diafygi/byoFS [3] - https://diafygi.github.io/byoFS/examples/chat/

In A Criticism of JavaScript Cryptography

diafygi·Jun 17, 2014

I submitted a Show HN yesterday what I believe a potential legitimate use case for javascript crypto (or more specifically, in-browser client-side crypto): Bring Your Own Filesystem (https://github.com/diafygi/byoFS) Example chat demo: https://diafygi.github.io/byoFS/examples/chat/ It seems like an unhosted-style app (unhosted.org) can mitigate all of the OP's concerns. > Secure delivery of Javascript to browsers is a chicken-egg problem. I address some this in the byoFS README[1] and again in an /r/crypto discussion[2]. Since the webapp is unhosted, the webapp is built to work when being served from anywhere, including your local filesystem. This means that you could download the webapp anonymously, inspect/audit/checksum it, then run it from your local filesystem in the browser (try it! just right click and Save As...). Alternatively, y

Read the rest

ou could load it from a server that you would trust to kill itself rather than comply with a secret court-ordered compromise (e.g. Lavabit, Internet Archive, etc.). Additionally, since the webapp is just static files, all the webapp server sees is anonymous requests (over https to prevent MITM). It doesn't know who is requesting the static files, so it would be difficult to perform a targeted malicious injection. You would have to broadcast the injection, which is generally ill-advised since it might be spotted by a vigilant third party. Most of the surveillance injection attacks that have been leaked have been targeted, so this basically cuts off that attack vector. So, in order to compromise this webapp through injection, you'd have to hack into the trusted static server and blindly serve the injection to everyone who requests the webapp (hopefully including your target). This is basically the same attack vector you'd have to do if you were trying to inject something into a download-and-install local application. I don't think javascript crypto is universally a good idea, but for this unhosted use case, it can limit attack vectors to the same as download-and-install local applications. > Browser Javascript is hostile to cryptography. True, which is why WebCryptoAPI should be prioritized, and I can stop using SJCL in byoFS. Once APIs for crypto primitives are baked into browsers, this argument disappears. > The "view-source" transparency of Javascript is illusory. It's certainly much better than inspecting desktop apps. Also, if your webapp is unhosted, you can certainly publish a signed hash of the static files, which can be verified after you download the app and before you run it. One infrastructure improvement that might be very helpful would be to be able to buy an SSL certificate from a CA that is limited to a particular file hash, which the browser checks before showing the connection as "validated" (maybe a checkmark beside the https lock?). [1] - https://github.com/diafygi/byoFS#security-and-philosophy [2] - https://pay.reddit.com/r/crypto/comments/289w7x/bring_your_o...

In JavaScript Cryptography Considered Harmful