Freeing the Web from the Browser

We do have a way to create links between two documents without editing either document: create a new document that links to both documents. This is a normal, though informal, activity.

And of course simply linking two documents together isn't that useful, you have to say WHY they are linked. I.e., the semantic triple (https://en.wikipedia.org/wiki/Semantic_triple) of subject–predicate–object, or maybe more informally you are simply saying X relates to Y because of Z, where Z is akin to the predicate.

Currently in HTML hypertext we're stuffing Z into the link text, which sometimes works nicely and sometimes works very poorly. But in an external document you have all the space you want to explain the relation between the documents.

Obviously there's lots of shortcomings of adding a new document to the web to explain every relation between existing documents. But I think it's a good starting point. We're missing things like:

1. Reliable deep linking to documents. We have ids, YouTube timestamps, etc., but finding these is an ad hoc process and they aren't always available.

2. Widespread transclusion tools. We actually have some now, in the form of link previews or OEmbed. When you post a link in a comment or post on Twitter or Facebook, they effectively transclude the link into the document. Not fully interactive, but it might be a better balance between linking and viewing than traditional/literal transclusion.

3. Discovery of these annotations or commentary. There's a hard CS problem here, to maintain privacy while also trying to find serendipitous results. Maybe it involves pre-loading lists of documents from the locations you want to "discover" from. Maybe it requires some understanding of privacy levels, or whether content is personalized or public. Or we use the technique we have now: lead with commentary, with no attempt to discover it after the fact. I.e., I know there are comments on https://www.reinterpretcast.com/open-hypermedia at https://news.ycombinator.com/item?id=17690865 because I found the document on https://news.ycombinator.com/news – is serendipity even a thing in a place as large as the web?

4. Maybe publishing tools... do I want to post a Tweet to describe every relation I see? But maybe I do, because even if organic discovery is possible I probably also want to publish a feed of my own annotations, and I want to be part of a community of people doing this, and Twitter is a reasonable example of this.

5. Some sort of representation of these links when they've been found. Even without fancy discovery this is necessary. Right now if I click on a link from a post like: "OMG this is the stupidest argument ever: http://example.com/some-stupid-document" it will look like any other page I've opened. Only if I remember well why I clicked on the link will I understand that I've been offered something with derision. The browser has to do something here, all it has currently is the back button to understand why you've gotten somewhere (and that doesn't even work consistently in these cases).

Not everyone has CPU cycles to waste, like users on mobile. Even then, the cost of a consumer contributing one connection is an amount of work that's totally tractable by a spammer.

Unless you get into tokens and paying money to contribute. Which defeats the purpose. Why would I pay money to contribute to a decentralized service?

perhaps. I'm hazarding a guess that I found it from slashdot and the slashdot search comes up with nothing for that.. so maybe not.

But what i'm thinking of definitely added a drawing overlay and a chat capability to any arbitrary page.

it was fun for a while to just turn on the plugin to see if any chatter was happening at a specific url on the internet.

The multi-program facet of this reminds me of Plan9's [plumber](http://doc.cat-v.org/plan_9/4th_edition/papers/plumb) concept, which is an OS component allowing communication between programs in the form of "plumbing messages". The plumber processes plumbing messages according to a rules file, passing them on to other applications. This rules file allows the user to easily configure which piece of data gets delivered where in a uniform fashion.

Plan9's plumber was mostly text data oriented, but it could in principle work with any kind of resource (images, audio files, documents). It seems naturally extensible to URIs. It goes a bit deeper than your idea by saying URIs and browsers aren't special and that all kinds of data should be plumbed between all kinds of applications (for instance, a text editor detecting a DOI in a text file and converting it into a clickable link that sends a plumbing message to the browser, which would then open the corresponding doi.org page).