Some words on the entrenched anti-leeching culture of the Web:

"Hot-linking" – now called Cross-Origin Resource Sharing (CORS) – is the practice of using resources such as images, fonts, stylesheets, scripts – even entire Web pages/apps that are hosted on one server in Web pages that are hosted on another server.

The Web has historically been antagonistic to hot-linking. This made a lot of sense in the 1990s, when a personal Web site might have an austere bandwidth cap of, say, 10MB per month. You'd create a cool Web page with some low-res GIFs, and your total page load might amount to 100KB – which meant that 100 people could visit your page in a month before you'd use-up your bandwidth quota. That was all fine and good – until some unscrupulous "leeches" would hot-link your images into their Web pages. Then, you'd be blowing your bandwidth quota in a week, serving images to those OTHER people's pages, and your site would be unavailable for three weeks out of the month! Rude!

Now, some people may not have noticed, but it is not the 1990s anymore.

The "anti-leeching" stance is no longer well-supported by reason of resource limitations. Unless, of course, you're hosting many gigabytes of 4K video from your site – but I don't imagine you'd be serving that from a low-cost shared hosting account, or a free one. And yet, the attitude persists. People don't like their bandwidth being leeched.

The xanalogical model is built on leeching.

Hot-linking by another name is transclusion. Xanalogical documents are transclusion-based documents. A xanalogical server must be ready and willing to serve media resources out to anyone that requests them, regardless of what document they're being requested for use in, and wherever those documents may be hosted.

Now, the "anti-leeching" rationale behind CORS restrictions is not the only one. In fact, it's not REALLY the primary rationale.

The real reason that people don't like to share resources across domains is: authors and rights-holders need you to view their material on their site, and only their site, because this is the only way that they can secure any revenue from it.

If they generate revenue from ad impressions, they need you to be on their Web site to get those ad impressions.

If they generate revenue from product sales, they need you to be able to see their promotions and to visit their eshop while viewing their material.

If they generate revenue from some kind of pay-for-access system (paywalling) then they need you to only be able to exclusively access their work through their site.

There is tremendous value to be derived from exclusivity, and people will go to great lengths to protect that value.

And, there are other issues with hot-linking as well.

One of the reasons that I've said that transclusion is a better way to do documents is that the sources of authored works are discoverable. You like something you find online, right-click on it and go to its source! Easy discovery!

Except that that isn't the way that the Web works right now.

Yes, you can right-click on, say, an image and open that image in a tab all by itself. Not many Web users are going to be paying attention to the URL of the image, so they won't notice whether the image is coming from a different server than the Web page that they were just looking at. But maybe YOU will.

So there you are, looking at http://cool80scars.com/ and you find a great illustration of a Bertone Lancia Sibilo (yes, technically a '70s car) which you notice is coming from http://conceptcars.art. Now what? You don't know what page that image was originally published in, you don't know what its original publication context was, and you still don't know who the artist is – unless this is a one-in-a-million case where the image file name or path has the artist's name in it (fat chance!). Hopefully Google reverse image search can help you out. Hopefully.

Now, the discoverability problem is something that Alph tries to address. The Alph server doesn't just serve media resources as files – it also serves them as Linked-Data Platform Resources, which means that when you host your work on an Alph server, you can specify all kinds of metadata about it, such as authorship information, titles, descriptions, links to a work's original publication context, or to the Web page in which you would prefer that users were viewing the resource from.

The Alph client software tries to make discovery as obvious and straightforward as possible. Rather than even requiring a right-click to inspect an element's metadata, the Alph.js script looks at the headers from every transcluded resource on a Web page to see if it has a Linked-Data representation. If it does, then as your mouse pointer moves across media in a Web page (including text, assuming it's wrapped in an X-TEXT tag) it displays the author's name(s), the title of the work, and the URL that the resource comes from in the info-bar at the bottom of the screen. If no Linked-Data is available, it still shows the URL of the resource, just to make it easier to see where media is being sourced from.

That's great for the discoverability angle. But what about the really intractable issue? Y'know, the MONEY issue?

Well... we could talk about MICROPAYMENTS.