frictionless linking

what is silk?

silk is a Web-based hypertext system with a focus on linking. silk's design makes linking as easy and frictionless as possible. silk was created as a personal note-taking tool---it is perfect for recording ideas and the connections between them---but it can also be used for multi-user collaboration, much in the same way as a Wiki.

The core idea is that links are important. A well-linked hypertext can be much more valuable than a poorly-linked hypertext. Links add information to hypertext by encoding associations and relationships. We can include this information explicitly in the text itself, but links are more useful than pure-text references because they are much easier to follow. In theory, linking is not a difficult task, as it follows directly from our natural inclination to notice connections between pieces of information. We find it easy to determine what should be linked. Creating and maintaining links, on the other hand, can be quite tedious.

The best way to understand silk is to try it: the silk Sandbox is open to the public.
Think silk is cool? Donate a dollar. [ 0 donations totalling $0 ]

what makes linking tedious in other systems?

In many hypertext systems, to link to a document, you must first obtain that document's identifier, be it a URL (http://www.somewhere...), a node number, or a camel case document title (CanYouRememberThisTitle). Then, you must select or create an appropriate text region as an anchor for the link (for example, a piece of text in the middle of your document). Finally, you must encode the anchored link using some kind of syntax (<A HREF = "http://www.somewhere...").

These steps take time. The time commitment discourages link creation in the first place, not to mention making link maintenance tedious. Since many hypertext systems force links to be anchored to text regions, links can clutter the text and make it difficult to read---yet another factor discouraging well-linked hypertexts. Furthermore, by forcing links to be anchored, these hypertext systems make bidirectional linking awkward at best and impossible at worst.

how does silk make linking easy?

In a silk web, an anchorless, bidirectional link can be created with a single mouse click. Optional link anchors can be specified around text regions using a straight-forward syntax (three characters to start the link region and four characters to end it; or four characters to automatically insert the destination node's title as the link anchor). Internal linking never requires knowledge of document identifiers. silk webs also support links to the external Web, which of course requires URLs as document identifiers. However, a URL can be entered once and used over and over throughout a silk web: after creating an external link, it can be connected to an internal silk node with a single mouse click.

how do i use silk?

Though silk was designed to be easy to use and understand, there are a few subtleties. The silk user's guide provides a complete description of the various features.

how can i run my own silk web?

You need a Web server that supports CGI scripts written in Perl. If you have such a Web server, you can probably run silk without installing additional software. If you think you are missing required Perl modules, take a look at the list of software requirements.

Download the script (v0.1.1), un-tar-gzip it, and place it in your server's cgi-bin directory. Make sure your script is executable by your Web server (for example, chmod o+x You also need to create a directory where silk will store its data (for example, cgi-data/silk). This data directory needs to be readable, writable, and executable by your Web server (for example, chmod o+rwx cgi-data/silk).

Open the file in a text editor and configure the various settings that are near the top of the file. Comments are included in to explain each setting.

If you have installed CGI scripts in the past, installing silk should be easy. If you are unfamiliar with CGI scripts, instructions are available elsewhere on the Web.

how can i report bugs, access code in CVS, etc.?

All of these services are available through the hypertext project page on SourceForge.

how does silk compare to other systems?

No hypertext system tries to make linking difficult. After all, links are what set hypertext apart from plain text. However, the fact remains that the act of linking is difficult in most hypertext systems. This difficulty may be due to the fact that these systems do not focus on easy linking explicitly.

Hypertext predates the Web by many years, and many non-Web hypertext systems featured slick graphical interfaces (for example, the ability to drag an animated arrow from one window to another to create a link). Most of these non-Web hypertext systems are no longer available, though two such systems are still being developed: Eastgate Systems distributes both Storyspace and Tinderbox, with Tinderbox being their more recent offering. Though it is difficult to compare silk's Web-based user interface with Tinderbox's multi-windowed graphical environment, link creation and management in silk is debatably easier (in Tinderbox, a simple operation like deleting a link requires hunting through a menu, manipulating a dialog box, and finally right-clicking to uncover the delete operation). Of course, silk pales in other ways compared to the feature-rich Tinderbox, but what is a hypertext system for if it's not for linking?

Better comparisons can be drawn between silk and other Web-based hypertext systems. First, consider the Web itself. To create a Web link, you first need to obtain the URL of the destination page---URLs are often complicated enough to make memorization impractical, so a copy-and-paste operation is usually necessary. For the sake of a simple example, suppose our destination URL is ( Because all Web links must be anchored inline around text, we must select appropriate text in our source page for the link. If no appropriate text exists, we must add text to our document to serve as the link anchor (for example, click here to visit Google). Finally, we must type the HTML linking syntax (easy to memorize, with practice, but always a pain to type):
<A HREF="">click here to visit Google</A>
Of course, after going through these steps, we have only created a unidirectional link: the multi-owner architecture of the web makes automatic bidirectional linking impossible. Even if we own the destination page, we would have to manually create a back link by repeating these steps.

Linking is not the only operation that is cumbersome on the Web: page creation, in general, can be painful. Wikis were developed in response to this problem, and they focus on making web maintenance quick and easy. Part of the Wiki package is simplified linking: creating an internal link is as easy as typing the destination page's title in camel case (for example, a SamplePageTitle). For people used to the cumbersome HTML linking syntax, this simplified syntax is a breath of fresh air. However, camel case linking, or any title-based linking scheme, is not free of encumbrances. First, you have to know the title of the destination page before you can link to it (perhaps easier to remember than a URL, but still easy to misspell). Second, node titles must be set when a node is created and never changed: changing a node's title would effectively break all links that point to the node, since titles are used as node identifiers. Third, links still must be anchored inline, and furthermore, the anchor text is forced by the linking syntax. If SamplePageTitle does not fit well into the flow of your text, you cannot make a link. Successors to the original Wiki system allow custom link anchor text but introduce semi-cumbersome syntax to support it (though nothing can compare to HTML's linking syntax). Finally, despite the fact that Wikis are self-contained systems, their links are unidirectional (probably because all links must be anchored, and it is difficult to automatically create appropriate anchors for back links). Though it is possible to search for all nodes that link to a given node, this kind of link search does not provide true bidirectionality.

Compared to linking in a Wiki, linking in silk is much easier. First, you never need to know a node identifier (for example, a title) to create a silk link: you simply add the destination node to the list of hot links. Since links do not depend on node titles, you can change the title of any node at any time, and since all links are bidirectional, link lists always show the current titles of the nodes they contain. Second, anchoring links inline is optional, so links can be quickly created without fitting them into the textual flow of the source or destination node. On the other hand, Wikis focus on quick text formatting, with easy syntax for font styles, lists, and indentation---silk focuses exclusively on linking and does not provide shortcuts for text formatting.

Another interesting Web-based hypertext system is Everything2. Links can be created explicitly in Everything2 nodes with a title-based syntax, similar to that of a Wiki, by using brackets around phrases [like this]. Everything2 adds a unique twist: clicking on a link for nonexistent node (for example, if there is no node called "like this") performs a search for the link words. Along with supporting manual link creation, Everything2 creates additional links between nodes automatically based on user traversal patterns---these automatic connections are called soft links. For example, if a user leaves node A by running a search to find node B, soft links are created from A to B and back from B to A. These soft links are sorted by popularity and displayed at the bottom of each node. Because soft links are sorted and potentially dropped according to popularity, and the popularity scale can vary wildly between linked nodes, soft links are not necessarily bidirectional. For example, though a node about the Postmaster may have only one soft link, with that link pointing to a node about Mickey Mouse, the Mickey Mouse node's soft link list may be full of popular soft links (the limit seems to be 48 links) and have no room for a link back to the Postmaster node. Thus, soft links in Everything2 can best be described as semi-bidirectional.

Despite its various linking innovations, Everything2 bears many of the same obstacles to linking that Wikis do. Title-based linking requires knowing the title of the target node and typing it correctly (a point emphasized throughout the Everything2 documentation: the mantra seems to be, "Check your links for typos."). A partial solution to this problem is Everything2's fall-back to searching for unknown link words, but this kind of search adds little utility to a mistyped link (though linking to Potsmaster by accident may produce amusing search results, the intended connection to Postmaster is still lost). Nothing could be "easier" than an automatic link creation mechanism like soft links, and they work quickly to create well-linked nodes with no extra effort on the part of the users. However, soft links do not reduce the friction of intentional linking at all, and they often capture inappropriate, unintentional associations. For example, while you read a node about the Postmaster, the phone rings and a conversation about a broken air conditioner ensues. After the phone call, you perform a search for "air conditioner repair," accidentally creating a useless soft link on the Postmaster node.

can you give a quantitative comparison?

We can count the mouse clicks and keystrokes (user actions) needed to create a link.

To be fair, we will only count user actions for unidirectional links, since silk makes bidirectional links for free and has an unfair advantage. We will use the following linking scenario for our comparison. Suppose we have a page called Home Page and another page called Test Page, and suppose that we already have both pages in front of us (so we will not count actions needed to locate the pages in the first place). We want to create a link from Home Page to Test Page. For the Web portion of the comparison, we will assume that Test Page has a rather short URL,, and we will give the Web a generous handicap: we will allow cut-and-paste operations instead of forcing the URL to be typed out. We will also ignore the user actions involved in accessing pages or saving changes (mouse clicks needed to switch windows or move between pages; operations needed to upload a page to a Web server; etc.).

Some of the operations involved in link creation are one-time actions that do not need to be repeated when creating additional links to the same document. In our comparison, we count the number of user actions needed to create a first link, create a second link, and create additional links.

For the Web, creating links would require the following operations:
Creating the first link
copy Test Page's URL1 keystroke
position the cursor at the start of the anchor text in Home Page1 mouse click
type <A HREF=" 9 keystrokes
paste Test Page's URL1 keystroke
type "> 2 keystrokes
position the cursor at the end of the anchor text1 mouse click
type </A>4 keystrokes
total19 user actions
Creating a second link
select all of <A HREF= "">2 mouse operations
copy the selected link start syntax1 keystroke
position the cursor at the start of the anchor text for the second link1 mouse click
past the link start syntax1 keystroke
position the cursor at the end of the anchor text1 mouse click
type </A>4 keystrokes
total10 user actions
Creating additional links
position the cursor at the start of the anchor text for the link1 mouse click
past the link start syntax1 keystroke
position the cursor at the end of the anchor text1 mouse click
type </A>4 keystrokes
total7 user actions

For a Wiki, creating links would require the following operations:
Creating the first link
position the cursor in the text of Home Page1 mouse click
type TestPage8 keystrokes
total9 user actions
Creating a second link
select all of TestPage2 mouse operations
copy TestPage1 keystroke
position the cursor for the second link1 mouse click
paste TestPage1 keystroke
total5 user actions
Creating additional links
position the cursor for the link1 mouse click
paste TestPage1 keystroke
total2 user actions

For Everything2, creating links would require the following operations:
Creating the first link
position the cursor in the text of Home Page1 mouse click
type [Test Page]10 keystrokes
total11 user actions
Creating a second link
select all of [TestPage]2 mouse operations
copy [TestPage]1 keystroke
position the cursor for the second link1 mouse click
paste [TestPage]1 keystroke
total5 user actions
Creating additional links
position the cursor for the link1 mouse click
paste [TestPage]1 keystroke
total2 user actions

For Tinderbox, creating links would require the following operations:
Creating the first link, a second link, or additional links
click the link start widget on Home Page (or on another node)1 mouse click
drag the link arrow to Test Page and release the mouse1 mouse drag/release
click the "OK" button to dismiss the link dialog box1 mouse click
total3 user actions

For silk, creating links would require the following operations:
Creating the first link
click [hot link] on Test Page to add it to the hot link list1 mouse click
from Home Page, click [+] next to Test Page in the hot link list1 mouse click
total2 user actions
Creating a second link or additional links
from the page to link, click [+] next to Test Page in the hot link list1 mouse click
total1 user action

The following graph summarizes these results, showing how the total number of user actions scales as additional links are created.

what is silk's data model?

The containment model for silk is shown in the following diagram:
Containment modeling was developed by Jim Whitehead. Details can be found in this paper, with further refinements described in this paper.

who wrote silk?

silk was written by Jason Rohrer.
Hosted by:
SourceForge Logo
since April 23,2004 #