Until now we have said very little about the technology that supports the community network. In this chapter we discuss technological architecture that complements the social and political architecture described in the last chapter. The basic technological architecture (Fig. 9.1) consists of four main components: (1) users (including developers, participants, administrators, information providers, visitors, and others) and user interfaces, (2) the community-network software, (3) the computer hardware (including the various CPUs, memory, disk drives, interface drivers, and so on), and (4) the delivery channels through which users can access the services on the system. In the remainder of this chapter we discuss each component and related issues.

A community network offers a multitude of capabilities to the community. Accordingly, there is a broad set of users of such a system and, ideally, the users are provided with an interface to the system that matches their needs, skill level, and temperament as closely as possible. Additionally, there will be a wide range of ways by which to access the system such as dial-up telephone lines, the Internet, and other ways. "Users" fall into four main groupsadministrators and developers, information providers, basic system users, and "visitors" (nonregistered users). Each group has particular needs in relation to the community network and each group has different levels of access to the network software and hardware. Other computer applications available over the network can also be viewed as a fifth type of user, one lacking flesh and bones to be sure, but a user with distinct, usually precise needs.

A sometimes implicit, but nevertheless critical concept of the community network (pioneered by the Free-Nets) is the decentralization of administration. In a community network, the system is maintained by many people assuming many roles and accessed through a variety of means (Fig. 9.1). Information providers, for example, must be able to add, delete, edit information, or change the menu structure in areas in which they have jurisdiction. On the other hand, they shouldn9t be able to modify information in other areas, nor should other information providers or users be able to modify information in theirs. Administrators and developers need, in general, more access to the computers and devices than the basic user. They will often need special privileges to add new users, install new software, reboot machines, etc. With the decentralized approach, the community network takes on the characteristics of the new community by supporting a network of peers, in contrast to a hierarchy, where rules and system content are developed at the top and "marching orders" flow downwards.

Some users (including, but not limited to, the estimated 49 million disabled people in the United States and the 750 million disabled people worldwide [NIST, 1994]) will find the traditional ASCII text-based interfaces difficult to use. User difficulties might include having limited sight or being unfamiliar with English (or other supported languages). Some users may be most comfortable using a language with non-Roman characters. For those used to non-English languages that primarily use Roman characters (such as Spanish), limitations are not as severe, though in practice users who use these non-English languages have generally seen their special needs ignored. Although the necessary effort would be substantial, instructions and menus of system functions (such as the mail reader) should be available in the languages most used within the community. Additionally, registration information and other important system documents (both on-line and paper versions) should also be available in a variety of languages.

Providing access to all members of the community is an important objective of community networks. The nontechnological aspect of this commitment means providing education and outreach as well as the actual infrastructure such as public terminals. From the technological standpoint considered in this chapter, there are many design decisions that must be made. The main principle is that the system be modular: It must be easy to swap out one piece of software and use another. For example, this principle allows the community-network developer — at least in theory — to provide different "shells" (user agents) to different users. This idea will be discussed in more detail later, but these shells could include a menu-based system, or a Mosaic or Netscape-like Web browser system. Modularity also allows a user to choose his or her favorite text editor, mail reader, news reader, or other generic tool where alternatives exist.

Although different software shells might make certain types of services easier to provide, it is important not to build separate community networks for different classes of users. It is also important to prevent duplication of effort wherever possible. In the discussion on World Wide Web browsers later on in this chapter, we see how it's possible to make the same community-network information available from the FreePort text-based software and the graphic-based (and text-based) Web browser with virtually no extra work. Another important consideration is the issue of where customization should take place — at the information level, the system level, the shell level, or in the users' environment?

Ideally all information would be comprehensible as well as accessible to all people, but in the case of presenting information in other languages, this goal is very difficult to attain in practice. Accommodating every language is impossible, and accommodating just a few is difficult. As mentioned before, all on-line information and software prompts should be available in various languages, especially those most prevalent in the community. The main system software could check if an "environmental variable" USER-LANGUAGE had a value (such as "Spanish," "Laotian," or "Swahili") and display the text in that language, if it existed, to the user when available.

Another way that support for other languages could be done is at the menu level. As shown in Fig. 9.2, this approach would provide a very simple way to offer material in different languages (but with "Arabic" being written with Arabic characters, "Chinese" with Chinese characters, etc.). The National Capital Free-Net in Ottawa, Ontario, Canada has duplicate systems available in French and English.

Since automatic translation by computer is not a reality (and probably will never be!), supporting a multilingual community on a community network may result in separate community networks, each in a different language. For example, the opening screen could say "typez 1 pour francais; type 2 for English." Of course we hope that information intended for the entire community will be translated into many languages, but this can't be required. Multilingual forums should also be promoted where people could converse about language differences as both an aspect of individual culture and as a barrier to effective communication between cultures.

While we are discussing language it is important to note that standards exist (ISO UNICODE, for example) for encoding hundreds of written languages. By means of the standard ASCII character set, various languages can be sent across the Internet and displayed on standard terminals. Software is available to perform both sides of the translation process. The first side (and this software is harder to find) allows users to input text in their own language. It is awkward but doable to use the common English-style keyboard as a way to input text in, say, Chinese, whose characters are composed of individual glyphs. The software then encodes the original language message into a coded message using only ASCII characters. At the other end, the display side, software is used that decodes the encoded message, and displays it in an acceptable original language form. This process presupposes that the terminal is capable of displaying arbitrary pixels on the screen rather than ASCII text only. With a terminal of this sort (known as a "bit-mapped display") it is possible to "paint" any pattern onto the display. Older terminals can only "type"; they're constrained to displaying the letters on a keyboard.

A community network offers a large amount of data and services. Since users must navigate through all these options, the organization is critically important. Many systems use a metaphorical approach where "real world" physical characteristics are used to help orient the user through the computer's artificial landscape. The Taos Telecommunity, for example, divides their system into a North Plaza (Fig. 9.3) and a South Plaza to convey a sense of place. The right metaphor will successfully convey the range of information available to the users and suggest the best way to obtain the information or use the services they require.

Since the computer system is exceptionally pliable, there is a huge range of approaches to organizing the community network. Just as a desktop interface on a personal computer is meant to suggest an actual, physical desktop where people perform certain tasks, community networks (and other network systems) employ a city-with-buildings metaphor to provide a useful organizational scheme. Disparate systems use the metaphor, such as FreePort (used in the various Free-Net systems), InterLink, The Virtual City, and Apple's on-line eWorld service. The city metaphor implies that the information and services available in the community network are organized in "buildings." E-mail, for example, is received and sent at the "post office," whereas city council agendas may be found in a "townhall" or other government "building." Connecting to a community network in another location is accomplished via the "teleport." The main menu and some subsidiary menus from the fictitious Erewhon Community Network are shown in Fig. 9.4.

Placing the information into buildings is usually straightforward, and users generally know where to look. One question is, How far can or should the metaphor be taken? As the amount of information grows larger, say, in the case of legal decisions, one might want to divide the buildings into "floors" and the floors into "rooms." As the system grows larger and larger, the metaphor tends to break down, making other searching and navigating techniques necessary. However, the city metaphor is eminently serviceable and offers a sort of user portability. If users are familiar with the city metaphor in their own community, they should be reasonably comfortable with it in another. Since the number of community networks using a city metaphor is increasing rapidly, adopting it as a standard seems quite reasonable.

The InterLink software (see Appendix D), developed by Eric Raymond as an alternative to traditional (generally FreePort) community-networking software, goes beyond the current community-network city metaphor in many ways. For one thing, it extends the metaphor to include other city amenities: Conveyances include elevators and monorails, while buildings may have desks, drawers, brochure racks, and other "real world" artifacts "inside" them. The InterLink approach as well as a view of how a system might look is shown in Fig. 9.5.

Information and services are found in likely city places. On Tech Street, for example, one can find technical libraries, computer user groups, and other technology-oriented information and discussion, as described below.

You are on a street lined with about equal proportions of low-rent hacker crash pads and gleaming, futuristic buildings (among the latter are the immense flying-saucer shape of the Tech Library and the offices of Frobozz Construction). A moving sidewalk in the center of the street offers easy transportation to either end. The Town Square is visible at the north end, and the Plaza to the south. There is room for new construction here.

One could find business information in the Business Resource Center:

You enter a four story building and walk across the marble floor of the Center's Lobby to the building directory located next to the indoor pond. The directory lists the current resources available and their locations within the Center. You are standing in front of the directory. To your left you notice a rack of brochures and pamphlets.

Here the Virtual City takes the building metaphor one step further by offering virtual elevator rides to more services:

a = Take elevator to On-Line Referral Library Area (1)

b = Take elevator to Direct Assistance Programs (2)

c = Take elevator to Self-Help Oriented Programs (3)

e = Take elevator to Business Events Calendar (4)

Influenced by U.S. politicians Ross Perot and Bill Clinton and the existence of community networks in the United States like Santa Monica's PEN and the Cleveland Free-Net, the Dutch political/cultural party De Babe, XS4all ( "Access for All"), and a handful of imaginative hackers launched "De Digitale Stad" — the Digital City — in Amsterdam in 1993.

The Amsterdam Digital Town was electronically visited by 15,000 people (or 2 percent of Amsterdam's 750,000 population) in its first eight months. Developers have found that users particularly like having access to job and housing information and that there is a large number of independent political groups and civic noncommercial activities represented on the system. There are similar projects in other European cities such as Berlin, Budapest, and Vienna, including some projects employing virtual reality (VR) techniques where users may ultimately be able to view 3-D scenes of the actual city (Dieberger, 1993).

Sending and receiving electronic mail (e-mail) is an essential feature of a community network; this capability allows users to send and receive private messages to and from other users. E-mail users might include people using the community network as well as users of other systems throughout the world including Internet sites, commercial networks like Compuserve and Delphi, and, in many cases, to homegrown, hobbyist networks such as Fidonet, which serves thousands of PCs around the world. Tens of millions of people around the world currently use e-mail, and this figure is growing rapidly (Rand, 1995).

Electronic mail implies an ability to send and receive messages over a network (Fig. 9.6). Those messages nearly always contain text only, but voice or graphic messages are becoming more common. In addition to sending and receiving e-mail, mail readers provide the ability to manage e-mail (Fig. 9.7). A user can view a list of e-mail messages (sorted by date, author, or by subject, for example) and is able to act on them. A user might respond to a message, include it in another letter, or save it as a file on the computer. Mail readers and mail systems also allow messages to be sent to lists of people as easily as they might be sent to individuals, thus making committee or other group work more viable electronically. Thus people often maintain mailing (or distribution) lists that contain e-mail addresses of people concerned about a particular issue.

Listservs and mail lists offer similar approaches to electronic discussions on community networks and on the Internet in general. A mail list is basically just a type of e-mail alias. For example, there might be an alias called "outreach-volunteers" that includes the e-mail addresses of all the members of the outreach committee, and any mail sent to "outreach-volunteers" will be forwarded to every address on the list. A listserv (such as majordomo), on the other hand, is more powerful, as users (including the list administrator who oversees maintenance on the list) can send a variety of commands to the listserv via e-mail, to get the names of all listservs at a particular site, or the names and e-mail addresses of all subscribers, for example.

Electronic forums are essential to community networks. A forum — sometimes called a "room" or "board" or "newsgroup" — enables a group of people to participate in an extended conversation on any topic. The conversation can be tightly focused or extremely broad, loosely conversational or concentrating on specific goals. The tone can be encouraging and welcoming or contentious and abusive. There are two main types of forums: a moderated forum that employs a moderator and an unmoderated forum that does not.

A user that wants to read forum postings will usually select the desired forum with a menu choice or by indicating that he or she wants to bring up a "news reader," which is functionally similar to a mail reader. The main distinction is that a user reads e-mail that is "owned" by that user, while a user reads news (or a forum) that is available to anybody who wants to participate in that particular forum. Many important policy issues associated with public forums were discussed in Chapter 8.

A message sent to an unmoderated forum is automatically posted to the forum. A message sent to a moderated forum is sent to the forum's moderator. The moderator then reads the posting and determines its suitability to the forum according to whatever criteria are relevant to the forum. Ideally, these criteria have been explicitly defined by the moderator and usually include relevance to the topic at hand (including clarity) and respect for other participants. Sarcasm and ad hominem attacks (universally referred to as "flaming") are often screened out, along with profanity and other strong language.

Since conversations in forums (even moderated ones) tend to stray or become fractious, participants often suggest approaches to structuring the conversation in various ways. These approaches ultimately must rely on the participants themselves abiding by a set of agreed-upon conventions, such as the use of key words in the subject line to indicate the conversational "thread" or subtopic within the forum that the posting addresses. The second approach is to let the moderator structure the conversation by guiding the conversation, asking questions, and even annotating postings from other users. Although this approach adds to the workload of the moderator, the result is more likely to be satisfactory. A third way to add structure is again to rely heavily on the good offices of the moderator. A common form of moderated structure is found in the "Question and Answer" (Q&A) forum. In this venue, users submit questions electronically to "experts" or whomever has agreed to find answers. The expert might be the moderator, or a group of people, who then researches the question. When the expert has devised a suitable answer, both question and answer are posted to the forum. Experts have included doctors and lawyers (in the Cleveland Free-Net) as well as automotive specialists (Heartland Free-Net) or ethical investment advisors (Seattle Community Network). The possibilities are endless for this electronic variation on the "Dear Abby" model found in daily newspapers. Scientists, nurses, gardeners, home-repair specialists, educators, policymakers, hobbyists, artists, musicians, craft people, farmers, and so on are all very good candidates for Q&A forum moderators.

Once a structured approach is known, it seems reasonable to develop software that enforces the desired interaction model. The trouble with this approach is that software developers aren't capable of second-guessing the ways in which people want software to mediate their electronic communication. Users in the past have balked at attempts to impose unyielding communication structure on their communication. Researchers at Bellcore damned this approach as "Naziware" when they were asked to use software that classified all their e-mail communication according to a rigid set of conventional conversational types.

While e-mail or posting notes to electronic forums is analogous to sending letters to individuals or to a newspaper, the "chat" capability offered on many community networks is more like a telephone conversation, with the keyboard serving as a mouthpiece. With chat, a user can type at the keyboard and the text is displayed on the terminals of all people who are also currently chatting. The capability often exists on community networks as well as on commercial systems like America Online, where it is frequently used as a social-opportunity on-line singles bar. Internet Relay Chat or IRC (Reid, 1994) is the equivalent of chat except that anybody on the Internet with the IRC software can participate over any number of "channels," generally named for the topic to which the channel is dedicated. Although IRC, like chat, is often used for "idle" conversation, it has also been used as a way to rapidly disseminate information on a current events. For example, the #gulf channel was used to send late-breaking news from the Gulf War to participants all over the world.

Because chat is often used for conversation (as opposed to directed topical conversation in forums) and has been used for flirtatious conversation, it is sometimes considered frivolous by developers or not worth overcoming its costs and hence not instituted or even removed from the system after being in operation for some time. However idle or potentially problematical the chat capabilities are for the community-network organization (because of minors and adults flirting on-line, for example) chat systems offer informal conversational capabilities that are needed in convivial, community settings.

When the amount of information increases to the extent that there is information of interest to everybody, it will necessarily contain more and more information not of interest for an individual person. As the community network becomes larger, the issue of finding information of specific interest becomes simultaneously more important and more difficult. The related issue of navigating through the system as quickly and as effectively as possible also becomes more important, and more difficult.

In the traditional community network, users navigate through the system via a series of menus. At each menu, there are one or more choices that a user can make. Some choices will cause information to be displayed, some choices initiate actions like opening a mail or forum reader, while other choices bring up additional menus. This series of menus can be arbitrarily deep. Navigation through menus is a serviceable method of locating the desired information or service on a community network. It is a method that new users can readily comprehend and use. It's not without drawbacks, however. Many times it is not clear what menu heading should be used, and where specific information belongs. Additionally, when there is a large body of information, a user might have to go through several levels (possibly 5, 10, or more) of menus to find the information they need or the forum they want to read. The FreePort system has go commands that short-circuit the lengthy menu traversal. An SCN user, for example, can type go senior at the prompt and skip immediately to the main senior menu. Using the go commands is like leaving bookmarks in a book to mark particular locations. One can immediately open the book to the marked page without skipping through the book page by page. The Mosaic program (and Netscape and other World Wide Web browsers) has the equivalent of the bookmark idea with its "hot list" concept. When a user reaches a location via Mosaic that they plan on visiting again, they can add the location to their hot list. When the user wants to revisit that location at a later time, the hot-list menu is pulled down and that location chosen from the list of previously chosen locations. When the user indicates which location is wanted, Mosaic establishes a connection with the host computer and downloads the Mosaic "page." Thus, from any location, a user can go directly to a hot-list location, bypassing all the intermediate locations that the user had originally visited.

Ideally, a community network should support browsing as well as searching. Although a FreePort user can get a list of all the go commands which provides some type of global view of the system, there is very little support for a directed search, in which a user is looking for specific information. A community network should have at least one type of search capability. This capability would allow a user to focus in immediately on information in the system even though the location is unknown. Generally a user indicates that he or she wants to search for information and then must provide some indication on what is being sought. Sometimes the user also indicates the range of the search. For example, should the software search through all files on the local system, document files only, information on other systems, or use other specifications? Providing searching capabilities can have some interesting indirect consequences because information may be brought forth from unexpected sources. For example, a libertarian might find some traditional conservative writings that bear on an issue; a community-oriented person on the left might find community-oriented literature from the right, and vice versa.

The user interface to a community network ideally supports many ways for users to accomplish their goals. Terse or complex ways to find and manipulate information may be ideal for experts, whereas menus may be sufficient for inexperienced users. The user interface should also support the complementary modes of searching and browsing: Sometimes a user is looking for something precise — the time and location of the neighborhood Alcoholics Anonymous meeting, for example. Sometimes the user is just curious about the system and wants to casually amble around, heading down paths that happen to be appealing at the moment.

The Mosaic program, developed at the University of Illinois based on work pioneered at CERN, a physics laboratory in Geneva, Switzerland, is probably the most prominent of the second-generation Internet programs. Mosaic established as a reality world-wide hypertext (sometimes called "nonlinear" text because information can contain "links" to other information, providing a portal by which a user can "navigate" readily to the other information). It simultaneously made the Internet more approachable and accessible to the nonspecialist. The Mosaic program (and other Web browsers such as Netscape) enable users on the Internet to build multimedia "pages" that contain links to other pages, which themselves can contain still more links, forming an increasingly vast collection of interlinked documents known as the World Wide Web. Each page is identified with a URL (Uniform Resource Locator) that uniquely specifies its location on the Internet. When the Mosaic client (or browser) on the local machine is aimed at another page's URL, it connects to the other machine, fetches a copy of the page to the local computer, and then displays it on the local machine. Establishing a "home-page" using HTML (Hypertext Mark-up Language) is becoming an extremely popular way to "hang your shingle" on the Internet, and some community networks are providing that capability to their information providers (see Sustainable Seattle page in Fig. 9.13). Since browser software can obtain copies of the HTML version of Web pages, anyone who is new to HTML (or to computer "markup" languages in general) can easily learn by example from existing pages.

Although graphical Web browsers make fairly high-resolution graphic information widely and easily available, some people lack the requisite display devices, while others don't have the desire or patience to wait for the graphics to come streaming in. (Some graphics seem to take forever to load and supply little or no added information.) Enter Lynx, an extremely hardy, public-domain text-only Web browser (Lavender et al., 1995). Providing text-only access to the world of WWW via Lynx is an elegant solution to the dilemma posed by (1) the existence of a wealth of material available on the web, (2) the desire to provide comparable service to all users (especially those with older and less sophisticated equipment); and (3) finite resources. The SCN Webmaster's committee identified several issues that should be considered before providing Lynx to all users. These concerns included: the effects on disk space if Lynx users began transferring large files to SCN, policy implications of having "objectionable" information on the Web, support issues, processing and bandwidth resource issues, and, finally, the effect of this service (which might accentuate nonlocal characteristics of the system) on the community aspects that provided the initial motivation for the system. Currently Lynx is offered to all SCN users.

Other types of lower-tech browsers are also becoming available. The I-Comm browser (see Appendix D), for example, is a relatively inexpensive shareware graphical Web browser ($29.95 or $19.95 to students) that runs on Windows machines over ordinary telephone lines (those not running SLIP, PPP, or other protocols). The Seattle Community Network currently supports I-Comm as an alternative to the text-only Lynx browser, which is also supported. I-Comm finesses some of the issues that Lynx introduces. If users want to download a document with Lynx, for example, they usually must save it to a local file (on the community-network machine) and download it from there to their home or office machine. I-Comm, on the other hand, already downloads the remote files onto the user's machine as temporary files that can be readily saved without the additional step that is required with Lynx. Since I-Comm is shareware, it is perfectly legitimate to allow its downloading from the community network to a user's machine. Moreover, since it employs the public HTTP protocol, this approach does not force users into using I-Comm. Macintosh, DOS, and other non-Windows users, unfortunately, do not currently have an I-Comm equivalent and, as of this writing, must use Lynx or a non-SCN account for access to the Web.

The newer browsers are extending beyond mere information distribution. A new form of browser has emerged that will allow cross-platform (PC, Macintosh, Unix, and so on) information and application distribution. One of these is Sun's HotJava browser that permits distribution of "active content." Conceivably, in the future users would be able to use browsers to participate in virtual forums in which participants could see and hear each other "live." Delivery of application software via browsers may become increasingly common and could ultimately completely change the nature of software distribution.

FTP and Telnet are the two applications that have traditionally formed the backbone of intensive Internet applications. FTP, which stands for File Transfer Protocol, allows a user to connect to another computer on the Internet, list or retrieve files on the remote computer, or transfer files from the local computer to the remote computer. People often set up extensive FTP "sites" where information can be made more widely available to other users. It is common practice to set up public FTP sites where "anonymous" is the login name and the user's e-mail address is the password. The Telnet program enables a user with an account on another computer to connect to the other computer and interact with it as if directly connected. Many community-network systems allow users to Telnet to them and login as "visitor." Some community networks also allow users to Telnet out of the community-network system, but this is often limited to a pre-selected number of other community-network sites.

A wide range of other Internet tools that were developed for the most part by universities are becoming available; these have the potential to be used with community-network systems (Engst, 1994; Liu et al., 1994). Many of these tools have names from the Archie comics family: Archie (for locating files on the Internet), Veronica (a searching agent that's used with Gopher), and Jughead (which is similar to Veronica). Gopher is a network retrieval tool that provides access to files, on-line phone books, library catalogs, information stored in WAIS databases, Usenet news, e-mail directories, and Archie servers, all contained in one easy to use interface.

A MUD (standing nominally for Multi-User Dungeon or Multi-User Dimension) is software that allows multiple users to connect over a network to a shared "text-based virtual reality" (Curtis, 1992), creating a social setting that Howard Rheingold characterizes as a "virtual water cooler" (1993). This type of computer-mediated communication (CMC) allows users to communicate with each other and also to add and modify "objects" (such as "rooms," "notices," or other programmable "things"), which other users can then interact with.

As Pavel Curtis (1992) and others have noted, a variety of social phenomena have arisen in MUDs. But are MUDs little more than a form of entertainment, a diversion for computer technologists and social misfits who are unable to communicate in traditional ways? Curtis of the Xerox Palo Alto Research Center (PARC) and others have been developing MUDs that can accommodate the requirements, skill levels, and tastes of communities with specialized needs. Curtis and David Nichols, for example, have built the Jupiter MUD for Astronomers (1993) and MIT student Amy Bruckman is developing a "MOOSE Crossing" (1994c) MUD for children.

As InterLink creator Eric Raymond (and others) have pointed out, a community network could be a type of virtual reality in which the objects — buildings and the like — could be given certain "real life" attributes like appearance and geographical locations. In fact these virtual cities could incorporate graphic virtual-reality technology over a network to provide graphic images as well as textual descriptions of the city's buildings and other resources. From this insight, it is but a short stretch to envision a community network as a specialized type of MUD.

Developers are currently designing new types of software that may permanently demolish the notion that network media is analogous to non-network media. These new types of software will enable users to develop environments and applications that are more capable of being tailored to the user's own needs; this effort might include setting up new and idiosyncratic services that will act in the user's behalf. Thus a user could receive a regular electronic "magazine" that contained only articles on preselected topics. At the same time, commercial vendors will be spending large amounts of resources on environments and applications that meet their needs with the citizen or user as the intended target.

Filters, especially mail filters, are at the low end of technological sophistication. Mail filters allow the e-mail recipient to set up rules to deal with his or her e-mail. At the simplest level, this takes the form of a "bozo filter" to delete upon receipt any e-mail received from anybody on the user's list of "bozos," generally people that have flamed, threatened, berated, or otherwise earned the wrath of the intended recipient. A more extreme version of the bozo filter is also possible. With this approach, the intended recipient makes a list of people that he or she will accept mail from, and all other mail is deleted. For example, the recipient could accept all mail emanating from specified companies, networks, or machines. Note that in this version, it is entirely possible to disallow a lot of e-mail that a user might really want to receive, such as e-mail from a friend or relative who just established a new e-mail account. In many —but not all— cases, the sender of a rejected message would receive an electronic reply stating that the mail filter rejected the message.

Moving slightly up the technological ladder are e-mail filters that process the contents of the e-mail in some way, generally to automate routine tasks like sorting the mail into appropriate mail folders. Mail from relatives might go into a personal folder and mail from the boss into an urgent folder, for example. A full discussion of processing e-mail is beyond the scope of this book, but the idea does have implications for the community network because collecting e-mail testimony, tabulating votes from an on-line meeting, tabulating survey results, and many other e-mail processing activities are directly related to community networks. Message-enabled e-mail or computational e-mail hold similar potential for structuring communication and for building interactivity into e-mail messages.

"Agents" are a still more unusual software technology. At their most exotic, they're envisioned as being as competent as humans that serve as round-the-clock, unpaid, artificially intelligent assistants. Although many people blithely assume that agents will exist in a few years or so, their existence in this most advanced form depends on developers solving many of the problems that the field of artificial intelligence has largely abandoned (for the second time), such as how to automatically extract "meaning" from text. In a more prosaic form, an agent could be employed to scan an on-line newspaper every day for news on a given topic, say, Romania, and the excerpts then could be e-mailed to the agent's owner. While this would provide handy assistance, it is by no means intelligent (as it just searches character-by-character for words such as "Romania" and "Romanian") and shouldn't be considered in any way as a substitute for a trained —human— librarian or researcher. Such an agent might constrain its results too much so that potentially interesting information is not returned. On the other hand, an under-constrained search might produce a mountain of unwanted information (such as this presumably irrelevant paragraph).

Agents can also search through archives of material in many ways as well as range through a wide variety of archives. One example of current agent technology is Perl or Tcl/Tk-based Web agents that navigate through the World Wide Web examining Web pages for "damage" such as nonexistent locations. At some point in the not-too-distant future agents may even negotiate with other agents for certain pieces of information, acting on the user's behalf. Future users of such agents will be well-advised to temper the zeal of the information ravenous infobot that has access to your credit-card number!

A critical question is how these software services are organized into a unified, coherent community network. There are two general answers to this question and each one has several advantages and disadvantages: You can buy a system "off the shelf" (see Appendix D for more information) or you can "roll your own" using software components that will need to be integrated, adapted, or developed as necessary. FreePort is the original Free-Net menu-based text-only software available from Case-Western Reserve University in Cleveland and is used in many of the Free-Nets. The software costs $850 and is available only to NPTN affiliates (see Chapter 8). The FreePort software is written in C and must be compiled to run on your (Unix) machine. It is available only on an "as-is" basis and modifications may be necessary to get it running properly on your equipment. The nptn-admin mailing list (see Appendix B) provides a good forum if any questions or comments arise about FreePort (as well as other community-network issues). Additionally, the developers at National Capital Free-Net in Ottawa, Ontario, Canada, have developed several software additions and modifications that enhance FreePort considerably. CIX, which is modeled after FreePort, provides additional functionality and is another option. InterLink (discussed earlier in this chapter) offers yet another off-the-shelf solution and is used in the Chester County InterLink community network (see Appendix C). Although large-scale, multiuser network systems have traditionally been hosted on Unix machines, platforms (such as Macintoshes and PC clones) and available networking software have increased in power and flexibility in recent years. FirstClass (BBS) software, available from SoftArc in Ontario, Canada, has been used extensively in Macintosh-based rural Free-Nets, while Worldgroup, a multifeatured BBS system for the PC platform is used all over the world, including the city of Seattle's PAN (Public Access Network) system (See Appendix D.). FirstClass and Worldgroup are client-server-based software and both use a proprietory protocol for "conversations" between the "client" software (on the user's machine) and the "server" software (on the community-network machine). Client software of either system can be distributed at no cost (although FirstClass does charge for use licenses). Moreover, both systems will work correctly (but not ideally) in a text-only mode if a user's machine does not have the appropriate client software.

Finally, the roll-your-own approach exists as an option for community-network organizers who meet any of the following characteristics: (1) they demand a certain style or functionality that can't be found elsewhere; (2) they prefer this approach; or (3) they're on a very tight budget. "Rolling your own" consists of adapting or integrating existing components or developing your own software (a daunting task that can be tempting — sometimes irresistibly — to software developers). Adapting or integrating software from various sources has other problems besides technical complexity, however. Each piece of software carries its own distribution constraint, from being strictly in the "public domain" (do anything you like with it) to GNU's "copyleft" approach to being "publicly available" (Lynx Web browsers) or being shareware (for which users are requested to send a fee to the developer).

Using the Web is a fairly good way of making community-network resources available on the Internet and other network tools such as Gopher and Archie can provide additional useful functionality. Community-network developers will need to integrate a variety of tools to provide the maximum utility. In other words, a Web-based interface to community-network services should provide as much functionality as FreePort or other interface. Designing and formatting information for a variety of accessing approaches, however, takes time and effort on the part of the information providers and developers. Preferably, one shouldn't have a different group of people working on each different interface. Nor should some services and information be available when using one interface while different services and information are available when using other interfaces. This would result in a schizophrenic community network as well as diluting the volunteer and staff effort.

Many community-network developers are currently suggesting that the Lynx browser could form the basis of a community-network shell or skeleton on which to build the entire community network. Lynx can fairly easily be made to provide the same functionality as menu-based approaches while making community-network information and communication services available to outside users with Web browsers as well. Since HTML is becoming a de facto standard for publishing on the Internet, this approach seems quite reasonable.

This approach is not trivial, however, and it does raise some issues. For example, Lynx may not be as easy to use for a beginning user and the Web may not support interaction as readily. Moreover, if Lynx is used to access nonlocal URLs, the distinction between local community information and information on remote sites will become increasingly blurred in the minds of the users. This eventually could raise some support issue, and it could make the identity of the community network as a community network less distinct.

Since the early days of computer systems, the protection of resources and information from unwanted access and control has been a perplexing issue. With the advent of networked computers for which physical isolation is no longer possible (or desirable), the problem has become more acute. Community networks offer a number of challenging concerns to developers, as their very purpose is to provide access to very large numbers of people. Also, during at least part of the time, most community networks will be administered by volunteers, thus introducing some risks due to a possibly transient, uncertain, and inconsistently skilled work force.

User education is critical in community networks, for users are likely to be unaware of security risks and the precautions they should take. This education should include how to choose good passwords and keep them private. Users should also have a sense of how secure the system is, so they can make appropriate decisions regarding how much they can trust the system. This type of education needs to be ongoing: It can be conducted via several routes, including log-in banners, policy statements, informational and alerting e-mail notices, and newsletter articles.

The hardware may be the least complicated aspect of developing a community network. At the heart of the community-network system is a computer (or group of computers) that needs to be an extremely reliable, multiprocessing machine. Its main role will be gathering input from large numbers of simultaneous users (from various delivery channels), running programs, accessing data from disk, and presenting output back to users. The community-network computer must also be configured to communicate with a potentially large number of devices. Since participants will want to save e-mail and other documents (possibly including graphic or audio information), disk drives with gigabytes (or terabytes) of storage will also be required. The community network can be hosted on any number of platforms. As the number of users increases and the services become more sophisticated, the platform must become correspondingly more powerful.

To adequately address hardware concerns developers must analyze needs, select hardware, connect the hardware to the system, monitor the system, and repeat this sequence ... forever. There is a basic sequence of four questions that can be used to guide much of the process. The first question is "What are the services that the community network will provide?" The second question is "What access methods will be used?" The third is "What type of performance is desired?" (relating to the type of service and number of users that will use the system) and the fourth is "How will the components be assembled in a way that meets current needs and that can evolve to meet future needs?"

As Table 9.1 shows, community networks can be characterized as either low-end, mid-range, or high-end systems based on what services are available and how many simultaneous users the system will support. Note that high-end services such as graphical Web browsers can stress the system, particularly in the delivery of the information over delivery channels, while these systems can handle much higher numbers of users that are using only text. A system that offers Internet capabilities such as FTP or Telnet makes some type of Internet connection mandatory, while a system that simply provides Internet e-mail to its users can accomplish this goal in many lower-tech ways such as by e-mail transfers over the telephone using UUCP (UNIX to UNIX copy) or other protocols.

In early 1994, the Seattle Community Network first went on-line. It used a donated 386 clone and donated BSDI Unix operating system. The FreePort software was modified slightly ( "ported") to run under this system. The modest system did surprisingly well — up to 10 simultaneous users could use it and the response was slow, but tolerable. The developers felt that it was important to have an operational system, but stressed that the system was only in "prototype mode." In December of 1994, the SCN organization bought a Sun SPARCstation 5, a fairly high-powered work station for approximately $5000. Plummeting computer prices have made grass-roots community-network projects more viable — a comparable machine would have cost tens of thousands more a few years earlier. In fact, the SPARCstation 4 that is now available is less expensive and faster than the SPARCstation 5 that SCN currently uses.

According to the classification scheme in Table 9.2, SCN is a low-end system. It is not, however, a toy system, and examining its architecture in some detail (Fig. 9.15) would be useful. Most SCN users access SCN from home using a personal computer, modem, and text-only terminal-emulation software. Approximately 20 percent use the 16 modem lines, which attach to the SCN main machine through a terminal server. Forty percent of SCN users reach SCN via the Seattle Public Library, King County Library, and Seattle Public Access Network (PAN) dial-in lines. Fourteen percent of SCN users are logging in from public terminals in the Seattle City and King County libraries. The rest reach SCN over the Internet via Telnet or the World Wide Web.

The SCN main computer (a Sun SPARCstation 5) is attached to the two other SCN machines — the 386 machine (now an administration machine) and a Sun SPARC SLC (the News/Web server) — and to the Seattle Public Library machines via a local area network (LAN). The LAN is attached to the Internet through a router. The SCN main computer has 64 MB of main memory and 4.5 GB of disk space. As of August, 1995, the system has over 5400 registered users and supports over 56,000 log-ins a month with up to 45 simultaneous users. Additionally, the SCN Web server is currently servicing over 4000 "hits" (or individual Web page accesses) a day.

To accommodate large numbers of simultaneous users, it is important to have as much memory as possible because the more memory there is, the less disk swapping and the better the performance will be. The SCN machine currently has 64 MB of memory, and NPTN recommends at least 32 MB of real memory, although 64 MB is better still (1993b).

Disk storage is cheap (now below $300 a gigabyte) and important. The system will need a lot of storage for information-provider areas and user space (allowing 1+ megabyte per user). The operating system requires about 300 MB and FreePort software uses an additional 80 MB. SCSI disks are currently increasing in capacity and becoming faster. In addition, newer storage systems provide high-capacity and redundancy by using RAID (redundant array of inexpensive disks) technology. RAID storage allows for single disk drives to fail without loss of data. NPTN also recommends a terminal server to handle the communication between the modems and the host computer, as they "are relatively cheap and make life much easier" (1993b). They also recommend that you don't skimp on modems, as they will be in near constant use, or on a large tape drive to facilitate making the time-consuming daily backups with as little manual intervention as possible.

The modular approach to system architecture is sound for many reasons. The basic reason is that modularity is a simple way to take advantage of all available components and to spread the processing load among machines. This is often done by turning various machines into servers for different software services, like news reading, Web server, or e-mail. Another advantage is that older components can be replaced incrementally when needed. This architecture also can lead to the situation where a single component of failure will not crash the entire system.

For the extremely cost-conscious community-network developer it is possible to get 486 or Pentium PCs relatively cheaply and run the public domain Unix clone Linux (Welsh et al., 1994) on them. There are electronic distribution lists dedicated to Linux and other appropriate public domain software. Low-end work station pricing has also come way down as there are now machines available for under $3000. These machines can be grouped together in a cluster (where each machine performs a specialized task) and can provide acceptable performance on a small budget.

Besides illustrating how commercial concerns are actively engaged in framing the possibilities of future network use, the advertisement above illustrates the impending uses of new and traditional delivery channels that could radically change some familiar patterns of information and communication in the home, workplace and community. In this section the term "delivery channel" is applied loosely to the physical medium, protocols, and the interfaces that allow information to pass back and forth between the community-network computer and users and services on computers. It is important to think of delivery channels in a general sense because the physical substrate, protocols, and policies are changing rapidly. Because of this rapid evolution, community-network proponents should be active participants in all decisions concerning public uses of delivery channels that might include voice-grade telephone, ISDN, cable television, or radio transmissions.

The term "infrastructure" refers to the base-level technology — both hardware and software — that is used to deliver information; it might be thought of as intelligent wiring or plumbing for information and communication. Currently infrastructure takes the form of telephone connections, cable television connections, and connections via invisible electromagnetic radiation for wireless telephones, radio and broadcast television. In the near future, there will be more types of "wire" — such as LEOS (low-level earth-orbiting satellite), direct broadcast, and other technologies. There will also be "smarter wire," including cable television retooling that would allow communication in both directions, ISDN telephone connections, and integrated technologies such as new set top boxes that can be used to control television sets and also to pull together several other types of communicating devices including the television and the telephone.

Telephone, wireless, cable, TV, and personal computer companies are beginning to compete in many services. One such service is broadcast television offered in conjunction with access to the Internet and, perhaps, thereby to community networks, through personal computers connected to cable networks with so-called cable modems. Soon, the services may encompass interactive video applications made available on computers, and eventually extend to data and video applications on television sets controlled by set top boxes.

The term "information superhighway" evokes many images of an ubiquitous high-speed network, providing information from all over the world to homes, schools, libraries, businesses, and government offices. One image identifies the information superhighway with the Internet, another with cable television networks having the oft-quoted capacity of 500 digitized and compressed video channels. The term originated in the United States as a metaphor for the National Information Infrastructure (NII), a government-sponsored network infrastructure. Though the use of the metaphor has increased with the growing availability of data and video networks, a community network considering becoming an "on-ramp to the information superhighway" should remember that there is no such specific entity as the "information superhighway," and consider carefully the specific nature of any network to which it might connect.

Connecting over existing telephone lines via a modem connected to a personal computer or terminal from home, work, or other locations is probably the simplest and most direct way to access the community network. This access method is open to anybody with a home computer, modem, telephone line, and telecommunications software. And, using SLIP, PPP, or TIA serial line protocols, someone with a home computer can effectively be "on" the Internet, allowing that person to use graphical Web browsers, for example. The variety of possible hardware and software at the user end presents challenges to the person using the community network as well as to the community-network developers who must try to accommodate as many users as possible. For one thing, a long-distance telephone call might be required to reach the community network, discouraging frequent and significant use for a large number of people. Also, modem speeds vary considerably, thus affecting the amount of data that can be sent across the telephone lines. If transmission is fast, then displaying a screenful of information that the user didn't absolutely require would not be terrible. If, however, transmission is slow, the user will not want to be subjected to any unnecessary information. Suppose graphics information is being transmitted over a telephone line, particularly a slow telephone line. Because graphics information is generally orders of magnitude greater in quantity and hence slower to transmit than textual information, it must be specifically needed by the user. If the graphic (or sound video or other large document) is merely decorative, then it is an unnecessary frill that detracts from the system's usefulness.

From the community-network side, it must be expected that users will use a wide variety of means by which to contact the community network. These include anything from a lowly dumb terminal that can only display characters to a powerful multimedia work station. Based on this wide variety of approaches, it is clear that the use of text-only is the lowest common denominator for all systems, and if text only is supported, then all users (that can read) will be able to use the system.

On the other hand, some information is inherently graphic. Maps and other geographic information, for example, cannot be translated into equivalent textual representations. Because of requirements for graphics and the desire on the part of users to take advantage of more advanced hardware, community-network developers are exploring the use of GUIs (graphical user interfaces) and newer software tools like Mosaic in their systems. Steve Cisler's question "How are you going to keep them happy with VT100 emulation once they've seen Mosaic?" (1995a), reflecting the seemingly inexorable push towards graphical approaches, is very relevant.

Whether telephone-based or not, the fundamental issue with client-server architectures is, How does the receiving program know what is data and what is something else? With a strict text-only character-based system, this is not a problem: Everything is either viewed directly as text or downloaded for later viewing. Once out of that regime, it becomes important that the sending system (the community-network system) knows something about the receiving system (typically a home computer). They must "speak the same language."

This shared language can become very sophisticated. It can be used for all types of display screen control as well as more advanced capabilities like information compression (at the sending side) and decompression (at the receiving side). Sophisticated user interfaces can be developed with the right protocol and "intelligence" on both ends of the communications channel or pipe. When software on both ends of the pipe speak the same language, to accomplish fairly complex tasks by working together, this is a "client-server architecture." In the case of a community network, the system is the "server," while the terminals or computer at home, work, or in a public access location are the "clients." Typically a client can only communicate with a server of the same type.

Examples of these client-server architectures can be found in commercial BBS systems (like Coconut, Ripterm, or FirstClass) or in commercial network systems like America Online or Prodigy. The servers on these systems are often able to communicate both with character-based and with full-fledged "smart" clients that are capable of understanding the full language or protocol that the client and server use to communicate with each other. These protocols may, for example, enable a user to resize windows on the local (client) system without sending or receiving any information from the server. These systems are relatively portable across client platforms because the vendors have developed clients with software that runs on Macintoshes, PCs, and other computers.

The trouble with these commercial protocols is — of course — that they're all secret or proprietary. Each protocol is a carefully guarded, proprietary secret that doesn't understand other protocols and whose use in a public way would constitute a violation of copyright. Moreover, requiring the use of a proprietary system to access the system would be contrary to the spirit of a community network. Therefore, public domain protocols are needed. HTTP (HyperText Transfer Protocol) offers one such protocol for accessing multimedia information across the Internet. Unfortunately, Mosaic and other graphical Web browsers are not well-suited for users who use ordinary TTY telecomm programs and modems over telephone lines.

Another criticism of the World Wide Web is its emphasis on "publishing" rather than two-way communication. The Web allows people to "put their shingle up" on the Internet but it's currently less supportive of conversations (using e-mail, forums, or chat, for example). There are several efforts afoot however, to support conversational functionality using the Web (such as Hypermail — see Appendix D), and these should become increasingly common within a few years. There is ongoing work in at least two different languages — Java from Sun (Sun, 1995) and Tcl/Tk developed by John Ousterhout (1994) while at UC Berkeley — to provide "active content" within Web pages. The HotJava and Tcl-based Surfit! browsers are early attempts to extend beyond the Web's publish-only mode. In addition, some new browsers are using the new VRML (Virtual Reality Modeling Language) allowing 3D interactivity over the Web.

Tcl (pronounced "tickle") and Tk, a user-interface toolkit built on Tcl, could also be used as the basis of a high-level client-server system that could be used over ordinary telephone lines (the interface shown for the fictitious Erewhon Community Network in Figure 9-4 is a Tk object). It should be noted, however, that these approaches have the potential problem of executing commands on the user's local machine posing significant security challenges and could have potentially catastrophic results (erasing all files, for example). The safe-Tcl language (Borenstein, 1995) provides one way to address this problem; other approaches are also being investigated.

When people discuss on-line network communications, terms like "cyberspace," the "net," or "the Internet" are often used to describe the totality of the electronic web. The Internet is actually a collection of networks. All of the networks that comprise the Internet use a common language (or set of protocols) called TCP/IP to communicate with each other — to send and receive the bits of data that may be part of a love note, an ad hominem attack, executable software, graphic, video, or audio information. There are literally millions of computers connected together with satellites, high-speed telephone lines, fiber-optic cable, and other connections to form the Internet.

Individuals that use community networks and individuals that develop community networks often want the system to be "on the net." To be "on the net" generally means that you have access to the other computers on the net and can access their information and services with the full suite of available Internet tools, including electronic mail (e-mail), FTP (for transferring files back and forth between the local and remote computer), Telnet (for logging into other computers), IRC (for Internet Relay Chat, allowing multiple IRC users to "chat" together using text on a "channel"), and Mosaic (or Netscape or other Web browsers for Internet hypertext access).

Historically, many community networks have not had ready access to the Internet. There are many reasons for this barrier but it has been very vexing to those in the community-network community. They — very rightly — objected to the fact that their tax dollars had been used for many years subsidizing network use by the educational and technological elite. Many regional providers had contributed to the idea that "ordinary people" had no right to this technology, basically because they didn't have the intelligence to use it correctly or responsibly. Additionally, many people whose use had been subsidized for years strenuously object to subsidizing those in the technological backwater. To them, subsidy to the poor is "socialism," whereas subsidy to the privileged just seems natural.

There are three issues to be addressed in considering the relationship of community and networks to the Internet. The first is, What does it mean to be on the Internet? The second is, How conducive is the focus on the Internet to the principles and goals of community networking? The third is, How should a community network secure an Internet connection should it wish to do so?

What does it mean for a community network to be "on" the Internet? There are various interpretations, and being "on" the Internet is not necessarily an unambiguous proposition. Traditionally, it has meant having a 24-hour-a-day direct connection using a router and a modem over a leased phone line. Minimally, being on the Internet means having an e-mail address that can be used by any other person on the Internet. Hence, my address of "douglas@scn.org" ("douglas" is my logon name to scn; "scn" is the Seattle Community Network's acronym and "org" means that scn is in the "org" domain, a nonprofit organizational designation) can be used to send me e-mail from anywhere in the world by anyone with access to Internet mail. In order for the routing of this mail to happen correctly, several things must have occurred. The first is that the "scn.org" domain name must be registered with the Network Information Center (NIC). The community-network organization must fill out a domain registration form containing domain name, contact information, and Internet provider (IP) address to be used. The NIC will check that the name has not already been taken. The community-network organization would have previously registered with the NIC for the IP address mentioned above or else would have arranged with their local Internet provider for the address to be used. An IP address is a four-part address (four numbers separated by periods) that will uniquely identify (at a low networking level) the machine to which it is attached. An IP address is required for direct attachment to the Internet.

Interestingly, having a name need not imply that the system is directly on the Internet. E-mail can be routed between the computer "on" the Internet and then exchanged over lower-speed telephone lines using any number of existing methods. Besides having a name (e.g., "scn.org") and an IP address, your machine's address must be placed in routing tables. These are used by the computers responsible for distributing data through the web of computers so that the right piece of information ends up in the right location. While Internet e-mail is fundamental to a community network (and available for little cost, especially for creative and enterprising developers), providing full Internet access for all users may be impractical. Fortunately, there is a wide range of mid-range approaches to be investigated.

Many community networks have not had to worry about their Internet connection because they are affiliated with a university, a library, or a local government with an Internet connection. Without that affiliation getting connected to the Internet may be more difficult. The first part of the job is to locate an Internet provider. If you think of the Internet as a huge network of information pipes, your community network won't be part of the plumbing if you can't find a tap to connect your (two-way) hose to. Finding an Internet provider is like locating a telephone company to "hook up" your telephone — only it's somewhat more mysterious.

Historically, there have been few providers of direct-connection Internet services and most access was through a handful of mid-level providers who were themselves connected to the top level of the Internet, the "backbone." Attaching to a mid-level provider was almost always priced in the same way: an annual fee for unlimited access, based on bandwidth. The cost usually ran between $30,000 and $35,000 for a T1 connection (MacKie-Mason and Varian, 1994). Mid-level providers were nearly all nonprofit corporations.

Nowadays, providers are more plentiful and they are far less likely to be nonprofit corporations. Access can be provided now over ISDN, fractional T1, T1, and T3 telephone lines. Mid-level providers are beginning to offer additional value-added services including e-mail, disk space, domain name service, and the like. Connecting directly to the Internet means paying for a fast, dedicated telephone line, a router (a special-purpose computer), and Ethernet interface cards for the community-network computer. Although I had no luck locating Internet providers with the Seattle "yellow pages" telephone directory, I did find relevant lists on-line on both the InterNIC and the Yahoo Web pages (see Appendix D).

Newspaper reporters and others often translate "community networks" as "Internet for the masses" or (worse yet) as an "on-ramp to the information superhighway." Both translations — popularity notwithstanding — are inaccurate and misleading. For one thing, both suggest that individuals and communities need to merge or become one with a global system, thus vaporizing the local community focus that community-network developers are striving to promote. The on-ramp analogy has several unfortunate connotations. One is that on-ramps to actual highways are, at best, necessary evils and, at worse, environmental blots. An on-ramp is generally used to get away from the local scene — usually at a high speed — towards a glittering destination several miles down the turnpike. To place the focus on the on-ramp is to place the focus on a retreat from the local community. In the words of Frank Odasz, this is the difference between the Internet and the "inner-net."

Beyond reporters' spins, what other issues are involved with integrating community networks with the Internet? While there is nothing intrinsically wrong with providing access to the Internet via the community network, there are several practical obstacles that community-network developers may need to face. The first obstacle may simply be a resource-allocation issue among the developers. Where should they be spending their time? Should they be developing local information, capacities and relationships or should they be developing services for accessing the Internet? Since commercial providers are springing up to offer these latter services, perhaps Internet access should not be the primary goal for community networks.

Cable television started as a local entrepreneurial activity in rural areas of the United States in the 1960s, as community antennas were erected to distribute broadcast television signals over cable to homes that were unable to obtain a clear signal. Now, cable companies are extremely large commercial organizations that are searching for new sources of revenue by offering services such as telephone and data connections. To do this, they are investing heavily in market trials and in building cable networks capable of transmitting information not only from the cable "headend" to the home, but also in the reverse direction. At the same time, telephone companies are investigating ways to use their existing equipment to provide broadcast and interactive television, as well as high-speed data.

The networks that supply these cable services will provide higher performance than dial-up and many Internet connections. If the cable system headend is connected to the Internet, all users (scaling issues aside) of the cable system could, in theory, have access to the Internet as well as to cable television. The data will travel on separate channels in the upward and downward directions (from and to the computer, respectively). The relative capacity of these paths is under debate (see Barlow [1995] for example). A network that provides only a small upward path and a large downward path may be suitable for Internet browsing and "interactive" television, but will not facilitate the transmission of large quantities of information from the home. As new applications for computer and communications technology become available to the public, the architecture of the residential broadband network provided by the cable or telephone company may become an issue of concern to community networks.

Users could continue to use computers at home to access community-network data applications, such as e-mail, if residential broadband networks provide the delivery channel. The computers would connect to the network using a cable modem, which must be compatible with the data equipment installed in the headend. The cable modem would connect to a community network in a manner similar to an Internet connection, precluding the need for dial-up access. Data rates of between 1 and 10 Mbps — much faster than dial-up or ISDN — are expected, though this capacity may be shared among several residences in the same area.

Interactive set top boxes will take several years to become common, and when they do, they will probably lack keyboards at first. It is unclear whether the living areas of the home, where people normally watch television, will provide an environment suitable for the focused activity of network access. Until television displays become more sophisticated, their image quality may be insufficient for the kind of work people commonly carry out on home computers. While television can provide a social focus in living areas, computer use generally does not.

Residential broadband networks may provide up to 75 broadcast cable television channels, as well as extra capacity to transmit data and video in response to requests from the individual consumers. Communities, often through their local government, have negotiated access to broadcast channels for many years. In the near future, they will face new challenges‹to present their existing community-network services (perhaps through an Internet connection) and to develop interactive video applications over the new two-way network capacity. It is currently unclear whether government regulation will require cable companies or telephone companies to provide access as "common carriers" to third parties who wish to present services over their networks. Mark Wheeler, an engineer with Apple Computer specializing in cable television applications recommends that community-network organizers find out who the cable contract administrator is for the community, and find out when the current cable contract expires. This information is invaluable for negotiating with cable television providers on PEG (public access, educational, governmental) access issues.

Langdon Winner has referred to applications such as "video on demand" and home shopping, where the upstream channel capacity is extremely constricted, as "interpassive" —rather than interactive— television. Some have suggested that the remote control for an interactive television system will need only one button labeled "Buy." Despite this concern, interest will probably increase in community-oriented interactive television applications. Network providers may wish to offer a local community focus in order to interest subscribers in their revenue-generating services, and community networks will probably need to respond to demands from their constituency for access —as users and information providers— to interactive video. Because the people who express this interest may or may not be actively involved with the data-oriented services of the community network, this may represent an opportunity for a community network to serve a larger constituency. Community networks may come to play an important role in working with network providers to provide interactive video services of value to the community.

To take advantage of residential broadband networks as they become available, community networks will need to consider a wide range of issues: a presence on the network for existing data applications; support of computer software to access existing data applications; access to the network for interactive video applications; production and compression of video content; interactive video application development, or "authoring"; and user-interface development for both computer and set top box. It is clear that community-network developers must broadly define their mission to not only provide access to existing technology but to stay abreast of technological trends. They must be alert to new challenges as well as opportunities for continuing community support.

Although the community network should look like a single integrated system, in reality it is probably a collection of hardware and software working together as a coherent, unified system. The Cleveland Free-Net, for example, "is not a single computer. It is a collection of more than a dozen machines all operating in coordination with each other" (Neff, 1995). This state of affairs is inevitable. Over the years, it is quite natural that the project will accumulate additional computers. At the same time, the number of users will also have grown substantially. For those reasons, it is quite natural to seek a way to connect all of the machines together to take advantage of the cumulative processing power. Since there are a variety of software functions that also need lashing together, a straightforward strategy is to distribute these software functions to the various machines at your disposal. For example, machines can be turned into news servers, gopher servers, Web servers, mail servers, Telnet servers, file servers, and so on. Usually these machines will all be connected via a local area network, and one or more of them are "on the Internet." Additionally, file-storage protocols such as NFS can be used to share disk storage with the other machines.

Community networks also need to be connected to other community networks and to other existing electronic resources, including BBSs. These connections can be invisible to end users, thus helping to create a seamless resource for users. Alternatively, the connections can be visible to users, thus providing users with tools for their own use. Electronic mail is an example of a seamless resource: Sending e-mail to somebody beyond the local community network shouldn't require any additional work of the user.