3 ms·
Some quibbles: * URNs weren't just for ISBN-like identifiers from an assignment authority. Some of the early writing talks about that use case, but the key fea
by gojomo 11y ago
Some quibbles:
* URNs weren't just for ISBN-like identifiers from an assignment authority. Some of the early writing talks about that use case, but the key feature was "location-independent persistent names", for which hash-names have always been a good fit. Nothing in the relevant specs precludes hash-names as an URN scheme – it's not "breaking the spec" – and a number of projects have used hash-named URNs. While there's a policy for registration, in practice some URN namespaces have been 'de facto registered by use', much like common-law trademarks and a lot of URI/URL schemes. (Of course, the neat "URLs and URNs as distinct subtypes of URIs" view never fully took root, as W3C's 2001 "Clarification" note acknowledged.)
* Magnet-links were absolutely designed to promote P2P/CDN-network-agnostic content-addressing. But, they were also made flexible enough to squeeze in other descriptive metadata, aliases, or fallback locations as well. The JS-launching was an adaptive hack; the descriptive (and usually hash-based) content-names were the point. A key early use case was making a common, vendor-neutral hash link for competing Gnutella clients, but the loose stuff-anything-useful-in generality saw magnet-links adopted by other software (such as DC++ and BitTorrent) as well. The 'magnet' URI scheme was only ever 'common-law' registered.
* It's a bit odd to consider the algorithm the URI 'authority', though if I squint I can see a sort of funhouse-logic to it. Notably the similar URI-scheme that's made it through IETF standardization, the 'ni' scheme (RFC6920), usually leaves the 'authority' component blank, so three slashes appear in a row – but alludes to the optional declaration of an 'authority' that might be able to help accessing the referenced content.
- chmike 11y agoThe authority is optional in an URI, the path is not. A blanc authority is not the same as an absent authority. Look at the examples in RFC3968 in section 1.1.2 at page 6 in https://tools.ietf.org/html/rfc3986 https://tools.ietf.org/html/rfc3986. The URI for the mailto scheme has only a relative path without authority and subdirs.
- gojomo 11y agoThe RFC3986 path may be empty – which is essentially the same as absent. Also, when magnet-URI was composed, the URI spec was RFC 2396, which clearly describes <path> is one of the elements that "may be absent": https://tools.ietf.org/html/rfc2396#section-3 https://tools.ietf.org/html/rfc2396#section-3 Also both RFC2396 and RFC3986 allow for URI schemes where everything after the 'scheme:' is opaque, and need not be strictly interpretable as authority/path/etc. (RFC2396 mentions that it will still refer to this opaque-part as a 'path', because "they are mutually exclusive for any given URI and can be parsed as a single component".)
- btrask 11y agoGreat points, you've clearly read the RFCs. :) - You're right that URNs were not just for ISBNs, but they shaped the formation of the standard and (IMHO) made it inapplicable for hashing. A content addressing system that can't resolve any of the standardized URNs wouldn't be very useful. FWIW one of my earliest prototypes used URNs, and I still use them for ISBN links! - Magnet links work fine today, but if you look at the original proposal[1], they really were designed for all of the wrong reasons (including explicitly popping up a JS handler). In practice everyone who uses magnet links tunnels URNs through them, which serves no point for a general purpose system. A system that supports magnet links must also support URNs (meaning the arguments against using URNs apply, and magnet: doesn't add much value). - I've considered eventually adding ni support to StrongLink, although it's not like anyone else uses it so it wouldn't be an interoperability win. I think my hash scheme proposal is much better, so I'm hoping we can just forget about ni entirely. (But to be clear, it's extremely easy for a system to support both.) [1] http://magnet-uri.sourceforge.net/magnet-draft-overview.txt http://magnet-uri.sourceforge.net/magnet-draft-overview.txt (warning: SourceForge link)
- gojomo 11y agoI wrote the original magnet-URI proposal, so trust me when I say the JS-stuff was a demo hack, and the content-based names the real point. (Essentially no one ever implemented the JS-handler-negotiation, which was a quasi-web-intents mechanism before that concept was named.) Magnet-URI's immediate predecessor was the Hash/Urn Gnutella Extensions, 'HUGE' [1], and the reason that all the examples in the magnet-URI spec are hash-URNs, and that such hash-URNs are the main way magnet-URI has been used, is because that's what magnet-URI was for. I respect that your design opinion is that URNs aren't good for this; it's just false for you to say hash-names are against the URN specs. Neither the language of the URN specs nor historical practice supports that idea. And, hashes are, as you clearly agree, a great way to generate "persistent, location-independent, resource identifiers" (the stated purpose of URNs). A system (P2P, CDN, local content-addressed stores, etc.) can be plenty useful even if it chooses to support only some URNs, or only some magnet-URIs. All the magnet-using systems have essentially ignored standardized/assigned URNs, and instead used ad-hoc hash URNs, and in total they've been quite useful to a lot of people. [1] http://rfc-gnutella.sourceforge.net/Proposals/HUGE/draft-gdf-huge-0_93.txt http://rfc-gnutella.sourceforge.net/Proposals/HUGE/draft-gdf...