Re: "full-hypertext" publishing on the web

All of the implementations you mention work only on the client side.
That is, to make use of them, the user must choose to use it.
Wouldn't it be better to make each webpage support Drexler's vision of
hypertext publishing automatically, with the browsers that everyone
already have?

For backlinks, the web server could process the referral fields of
incoming requests and save them to a file.  Javascript in the page can
read this file and incorporate the backlinks into the displayed page.
So links to foo.html will have the backlinks stored in
foo.html.backlinks.  Perhaps a small '+' could appear next to
paragraphs that have backlinks?  The user could click the '+' to
display the list of backlink URLs.

Perhaps later, an extra command could be added to HTTP for retrieving
backlinks for a particular URL?  Then the browser could handle
displaying backlinks and facilitate filtering.

Similarly, a command could be added to HTTP for one server to inform
another server of links.  This would allow the linked page to be aware
of back links in new content even if no user has yet clicked on the
links.  Of course, it would be easy for the web server to just perform
normal HTTP GET requests, so an extra HTTP command may not be
necessary.  I guess that HTML authoring tools would take over the job
of "clicking" all of the outgoing links and informing the linked-to
servers of the links.  There is great potential for abuse in such a
system.  I guess that people would quickly write software that filters
out spam backlinks, arranges backlinks by the number of referral hits
received, and uses outside data sources such as Google PageRank.

Queer numbers is a clever idea!  Fine-grained linking has two parts:
1. directing a user who clicks on a fine-grained link to the proper page element
2. allowing a user to discover the fine-grained link to a particular
page element
I think that JavaScript in the page can facilitate both of these.  I'm
a JavaScript novice and don't know exactly how one would go about #1.
For #2, there are many ways to insert a URL unobtrusively into a
document.  Perhaps the first word of the paragraph could be a
hyperlink to that paragraph's fine-grained link?  One could use CSS to
make the hyperlink look like normal text.  Or you could place a '+'
next to the paragraph that displays the URL (and any backlinks) when
clicked.  Of course there are many ways to design the user interface.
Ideally, the web browser would display the fine-grained link of the
currently selected element in the address bar.  Like you suggested,
that could be added with a greasemonkey script.  Can JavaScript in a
page change the URL without issuing a redirect & redisplay?

I think it's interesting that you left out one of Drexler's
requirements: Must handle royalties.  Do you think that it's
unimportant or intractable?  Just today, I spent a considerable amount
of time obtaining a paper that was published in Oxford Journal's "The
Computer Journal" from 1993.  The online archive is available to
subscribers who pay $1,100 a year.  After creating an account on the
website, I was offered the single paper for download for only $23.
This is still a huge royalty.  Eventaully, I discovered a way to
download the paper for free, utilizing my university's library proxy
server.  Still, the library pays a subscription fee which covers the
royalties.  I will graduate next month and lose my offsite library
access.  Then my only recourse will be to pay for such downloads via
credit card or go to the library and download using the computers
there.

For about a year now, I've been thinking about an Internet payment
system that would be suitable for handling the HTTP 402 Payment
Required response, as well as other applications.  Drexler's vision of
Hypertext publishing has waited for almost 20 years and can probably
wait a little longer.  But the billions of people who will get on the
Internet in coming years who do not have access to credit cards will
need a way to buy and sell online.  They won't want to wait.

-Michael