Choosing between names and identifiers in URLs
The article talks about referring to resources by using URLs containing opaque ID numbers versus URLs containing human-readable hierarchical paths and names. They give examples like bank accounts and library books.<p>This problem about naming URLs is also present in file system design. File names can be short, meaningful, context-sensitive, and human-friendly; or they can be long, unique, and permanent. For example, a photo might be named IMG_1234.jpg or Mountain.jpg, or it can be named 63f8d706e07a308964e3399d9fbf8774d37493e787218ac055a572dfeed49bbe.jpg. The problem with the short names is that they can easily collide, and often change at the whim of the user. The article highlights the difference between the identity of an object (the permanent long name) versus searching for an object (the human-friendly path, which could return different results each time).<p>For decades, the core assumption in file system design is to provide hierarchical paths that refer to mutable files. A number of alternative systems have sprouted which upend this assumption - by having all files be immutable, addressed by hash, and searchable through other mechanisms. Examples include Git version control, BitTorrent, IPFS, Camlistore, and my own unnamed proposal: <a href="https:&#x2F;&#x2F;www.nayuki.io&#x2F;page&#x2F;designing-a-better-nonhierarchical-way-to-organize-files" rel="nofollow">https:&#x2F;&#x2F;www.nayuki.io&#x2F;page&#x2F;designing-a-better-nonhierarchica...</a> . (Previous discussion: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=14537650" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=14537650</a> )<p>Personally, I think immutable files present a fascinating opportunity for exploration, because they make it possible to create stable metadata. In a mutable hierarchical file system, metadata (such as photo tags or song titles) can be stored either within the file itself, or in a separate file that points to the main file. But &quot;pointers&quot; in the form of hard links or symlinks are brittle, hence storing metadata as a separate file is perilous. Moreover, the main file can be overwritten with completely different data, and the metadata can become out of date. By contrast, if the metadata points to the main data by hash, then the reference is unambiguous, and the metadata can never accidentally point to the &quot;wrong&quot; file in the future.