Show HN: The Concept of a Personal File System
There is a small overlap between a ton of things I&#x27;ve been considering recently, and your ideas. We both want persistent storage of versioned files that can be shared <i>directly</i> with others.<p>I&#x27;ve been reading up on the Memex, as described by Bush in 1945. He saw it as the most important challenge facing mankind, and I think he was right. I think we blew it, big time. HTML and the Web isn&#x27;t close to what he was describing. It&#x27;s different in some key ways.<p>The Memex was a <i>personal store</i> of knowledge. All storage was local, and hyperlinked. There was a feature for exporting a &quot;trail&quot; of documents to an external storage medium. (Microfilm, in his case... he held several patents in that area, so it was very familiar to him)<p>The main reason for having the Memex was to hyperlink documents, and store &quot;trails&quot; through them.  Giving things context, and seeing the connections between parts of a very complex idea was where the Memex would be most useful. Saving a single web page with all of it&#x27;s included images in a folder isn&#x27;t even close. It&#x27;s only one document, not a web of them. All of the links outside of the saved document <i>will</i> eventually break.  DRM prevents saving some content.<p>HTML doesn&#x27;t let you mark up Hypertext. It stores the &quot;markup&quot; in with the document, emulating a piece of paper. This prevents many different markups of the same document, as the locations of the underlying actual text in the document move with each change, no matter how trivial.<p>A better way to mark up documents is to store the markup in a layer separate from the underlying text. If you <i>must</i> have it all in the same file, then store it in a zip folder structure, as has become common with open office documents, etc. The base layer should <i>never</i> change with markup. This small change then allows you to use things like GIT to version it, and know the changes.<p>If a system of transforms of the text is used, instead of the line oriented approach of GIT, you can then refer to anything in a document with a range. Those ranges can be transformed to match document versions with some simple math. This is impossible with HTML, in the long run.<p>If you store markup separate from text, then you can easily use a different type of pointer to refer to images, video, audio, or other media in a manner similar with the text markup. It becomes possible to annotate all media with a few relatively small changes.<p>I&#x27;ve become convinced that the best way to deal with the web as it now stands is to ingest HTML, extract out the text layer, and then separate&#x2F;transform the markup to a set of layers in a new format. All markup would point to the underlying text by range, instead of relying on it&#x27;s implicit address in the stream of HTML. Once this is done, it then becomes practical to turn the range into a resource locator.<p>I propose reading <i>everything</i> you personally browse from the internet into a stream of such documents and layers. Each and every object would have an automatic refence count and he included on a list of all available local objects. You could then garbage collect files that were unused after an appropriate amount of time. This would automatically save everything that you created a hyperlink to locally.  You could then move the documents that were in this log, and linked  to, to a more permanent home, and an archive.<p>Making access available to friends and family should be done via a capability object. Usernames and passwords shouldn&#x27;t be used.  This capability would be signed and represent both the address of, and access to, the relevant document(s).  A list of capabilities given would be maintained locally, and checked for revocation by the underlying access system.<p>Wow... that&#x27;s a lot of stuff... I hope some of it makes sense to you, and that you find these ideas useful in some manner. Thanks for sharing, and your time and attention in reading this reply.