Alphabetical Site Index


Truth Distribution Network (TDN)

A major goal of Project Media Matrix is to end the advantage that the Bad Guys now have in communications with each other and in lying to the people about News Events.

We can't change the Media Establishment. So we must build a new and better news and communications network to bypass it. I call this the Truth Distribution Network or TDN.

The TDN. must be good enough that news consumers and activist groups prefer it over the Media Establishment and communication methods in use today. And it must be impossible for the Bad Guys to censor the TDN the way they can now do Internet Censorship.

Here I describe what I think the TDN should be, and how it should be built. The first subsection describes its general requirements. The last 3 subsections describe more specific requirements and give suggestions for implementation, and are intended mainly for the computer people that will build it.

[Click on (Back) button now.]

TDN General Requirements

The TDN should satisfy the following requirements.

A network of personal computers, with the correct software, would satisfy all these requirements.

Computers are currently very popular, almost like TV sets, and not a lot more costly.

Most computers sold today, in addition to displaying plain text, can display color images and play high fidelity sound. They have point-and-click graphical user interfaces. With good software, computers are very pleasant and easy to use.

Personal computers have modems, network interfaces, or removable disks which permit the creation of various types of networks for the exchange of information with other computers.

Most importantly, a computer is programmable. It can do very complex and repetitive tasks, if programmed with the correct software. The TDN software should perform the following functions.

The next sections discuss these ideas in more detail, organized by user features, development, and security.

TDN User Features

Here are the requirements for the TDN user features. Here are the TDN User Features again in more detail.

TDN Development

The TDN software will consist of multiple communicating software components, with many features. Building these components will require many people. Coordination of their efforts will be necessary for the building of TDN software of high quality.

I think that the best model for TDN software development is the open-source software model (Live Web Page: here). In this model the source code for the software is freely available, and is generally included free. This model is used for the Linux kernel, the GNU Project, and other software.

Open-source software development has many advantages over the methods used to develop most commercial software. Because source code is available with the software, it is easier for anybody who wants it to contribute to the software development effort. It is easier to detect and correct security problems, whether they are intentional or not. Because work on these projects is not directed by the profit motive, it is not vulnerable to discriminatory enforcement of business laws, which is a very powerful method of control. And it is possible to organize open-source software projects without a centralized leadership that is vulnerable to outside control.

Open-source software projects do not work well beginning from scratch. Fortunately TDN development does not need to. There are E-mail readers, browsers, and other components that may be used as starting points for the TDN components. In many instances it might be more sensible to influence the development of existing components and integrate them into the TDN, and not fork the code.

Since many TDN users won't be experienced computer users, TDN software releases should put more emphasis on stable bug-free versions than most other open-source software, which is usually targeted for computer professionals.

On what part of the TDN should you work? I am not certain, but here are some ideas.

TDN Security

The TDN will be an Intelligence network for the people. When Project Media Matrix is successful the TDN will replace today's Media Establishment as the people's main source of news. The Bad Guys won't like that, because the people will no longer believe their lies.

The only way the Bad Guys could continue the delivery of their lies to the people is by interfering with the TDN with Counterintelligence operations, and if possible completely neutralizing it. This section describes possible attacks against the TDN, and how to defend against them. In other words it discusses TDN Security.

It would be good if the TDN could use the Internet's World Wide Web, E-mail, and Usenet news systems, to deliver complete and accurate news. But the Internet has security problems, as evidenced by various Documented Internet Censorship activities. More problems will appear if the TDN uses the Internet. So some of the following sections are about Internet security problems and whether and how the TDN could deal with them.

[Click on (Back) button now.]

Easy To Use

Using the TDN should be as easy as changing channels on a TV. If it isn't, then many people won't use it to obtain their news. Ease of use is the most important requirement of the TDN, and it should be designed into all TDN components from the beginning.

Making the TDN Easy To Use is very important because people are very busy today. Generally more than one member of the family is working, many have more than one job, have children, or various other things keeping them busy. Every thing done to make the TDN Easy To Use will will mean an increase in the number of people who will prefer the TDN instead of the outlets of the Media Establishment.

All the TDN features that I suggest are for ease of use for the unsophisticated user. But I do not want to discourage the development of more advanced features. So I make the following recommendations.

Interactive User Interface

The TDN's basic Interactive User Interface should look similar to a Web Browser.

This interface is okay for computer geeks, but not everybody wants to sit in front of a computer clicking a mouse to get news. So it should also be possible to interact with the TDN using a handheld remote control from a comfortable chair or the dinner table. It should be as easy as using the TV or radio.

If possible, the computer should be integrated with other electronic components, such as the TV, and sound systems. When it's easy to switch from existing entertainment devices to the personal computer, the computer and the TDN will be used more. Everything, including the computer, should be controllable using one handheld remote control. The hardware to do these things already exists.

The computer should appear to turn on as fast as the TV set. Some computers have a sleep mode that makes this possible.

Simple menus should be displayed, or spoken in computer synthesised voice, or both, listing the available choices for the user.

The user could make his choices using either the keyboard, mouse, or remote control, whatever is most convenient at the time. If the computer is equipped with a microphone, the user should be able to make selections by speaking a small set of commands which the software would recognise and execute. The handheld remote control and voice commands would give the user the convenience of making choices without being near the computer.

Noninteractive User Interface

Some people might not want to interact much with the TDN. They would prefer to use the TDN the way they read newspapers, listen to the radio, or watch TV; at least at first.

The TDN should be able to serve these users by outputting documents in non interactive ways. The TDN could output them in several ways, depending on the capabilities of the user's computer.

In all cases, the selection of the documents to output, and their placement in the output, should be based on scores calculated by the document Review system.

Information Overload

A big problem today is Information Overload. We receive large amounts of information, from many different sources, including TV, radio, newspapers, magazines, E-mail, and the Web. Most of us can not separate what is important from what is not important and make sense of it all.

Computer Information Overload could become a big problem for people that try to use their computer to get most of their news. The TDN must handle this problem.

I make the following suggestions for solving this problem in the TDN.

These methods are discussed in more detail below.

Report Writing Tool

A problem with writing for Web Pages, or any medium that might be seen by many people, is writing something that we would be proud to show other people. Regrettably, for many people, including me, quality writing is difficult. One might blame the government schools, but that wouldn't solve the problem. If this problem is not solved then the TDN will have many poor documents or have only a few good ones.

The most practical solution to this problem eventually might be to add writing tools to the TDN. These tools might be difficult to build, but if built well would be worth the effort. I don't mean tools to help with page layout. I mean tools to help write English text.

Here are some suggestions about a tool to help write a raw news report about an event.

In addition to increasing the number and quality of reports published on the TDN, writing tools such as this, combined with spelling checker and synonym substitution software, could be used protect the anonymity of writers by removing personal writing style from reports. Similar technology might be useful for the translation of reports to other languages.

Abundant Hyperlinks (AH)

A hyperlink is a link from one place in a hypertext document to another. The Web is a hypertext medium. It is the links that make the Web a web. When you click on a link in one place, your Web Browser shows you the information at the other place.

Links often appear on Web Pages in seperate lists such as tables of contents, indexes, and links pages.

Sometimes links appear on Web Pages within ordinary text, but not often enough. There should be Abundant Hyperlinks within text. These links should link to: glossary entries, footnotes, or sections of other documents; that support statements or explain terms that appear in the text. Why?

What should be linked? Ideally anything and everything about which the reader might have a question should link to a section of an explanatory Web Page. This includes persons, places, things, events, companies, governments, articles, books, and unusual words and phrases.

But creating hyperlinks manually requires time. So, whenever possible, the Report Writing Tool should create them automatically. When text in a report matches an entry in the Topic Index the Report Writing Tool should automatically make that text into a hyperlink with the associated URL.

A Web-based authoring system that partially automates this process is the Wiki Wiki Web. Any text consisting of two or more capitalized words, such as "WikiWikiWeb" (Live Web Page: here). is converted to a link.

To support links to arbitrary points inside existing documents that can not be changed, and in which those points are not already labeled with an < A NAME= > anchor, the TDN browser should support a string search anchor. For example, when the browser follows the link

it would display the document TargetFile.htm positioned at the second instance of the string "Target String" in that file. It should highlight the string the same way the Find commands do in existing browsers. If no FIND string is provided then the browser should search for "Link String" instead. The INSTANCE attribute is optional. If not provided then it is assumed to be 1.

Topic Index

The Topic Index is a list of entries. Each entry relates a topic, represented by a word or phrase, to a document or document section that explains the topic.

To facilitate the automatic creation of Topic Index entries from documents, I recommend that topics be the text enclosed by HTML TITLE tags or A tags with a NAME attribute. The TDN software should automatically add these entries when new documents are received or created by the user.

The Report Writing Tool should automatically create Abundant Hyperlinks to explanatory information by making text that matches entries in the Topic Index into hyperlinks to the explanatory information.

For example, somebody writing a report about gun control might input the following text: "The second amendment to the Constitution of the United States says: A well regulated Militia, being necessary to the security of a free state, the right of the people to keep and bear Arms, shall not be infringed". If the Topic Index has matching entries, then the Report Writing Tool should automatically make "Constitution of the United States", "Militia", and "Arms" into hyperlinks to the explanatory information.

A large Topic Index might also have entries for the words: amendment, security, free, state, right, people, and infringed. You might say that this is going too far, and people should know the meaning of these words. That doesn't change the fact that some people will be confused by some of these words. Converting them to links to glossary entries is a small price to pay to keep these people reading, especially if the conversions are done automatically.

It is possible for the same word or phrase to have more than one entry in the Topic Index.

The user should be able to manually add other entries to the Topic Index when he wants. For example, when the user sees a Web Page that appears to explain an idea very well, but it does not satisfy the criteria the TDN software uses for the automatic creation of a Topic Index entry, it should be easy to manually create one.

Whenever the Topic Index changes, especially when entries are added, the Report Writing Tool should examine any documents written by the resident TDN user and determine whether any links should be added, deleted, or changed. If there are then it should inform the user, and make the changes if the user approves.

The TDN software should exchange Topic Index entries with TDN neighbors. This will mean more successful Topic Searches and documents with more Abundant Hyperlinks.

Topic Search

The Topic Search does a quick search of the Topic Index. This provides a simple fast search capability that does not need an Internet Search Engine.

The Topic Search function could be used both in the Report Writing Tool for the automatic creation of Abundant Hyperlinks, and as part of the solution to the problem of Interference With Search Engines on the Internet.

With a good Topic Search function, a TDN user will be able to quickly locate the documents needed to easilly learn the complete and accurate truth about any subject that's in the news, or should be in the news.

Event Notification

People do not read news documents about which they do not know. This is a problem with which the TDN must deal.

There are several ways now for people to learn about new news reports on the News Web Sites of the World Wide Web.

But each of these methods would be unsatisfactory for the TDN, for one or more of the following reasons:

For these reasons and others, the TDN should have an automatic Event Notification system. The information sent automatically to neighboring TDN nodes should include:

The TDN software should automatically process this information. The user should not need to deal with it.

[Click on (Back) button now.]

Filtering

The word Filtering, when used in the context of Information Overload, means a system, often an automatic system, the purpose of which is to prevent information of low value getting to the user and wasting his time.

But document Filtering has problems. Because it completely removes some documents from consideration by the user, it is difficult to know when over Filtering is happening. This makes Filtering tempting for those that would use it covertly for censorship.

So I believe that the TDN should not do document Filtering. Instead it should only provide help by prioritizing documents by Review scores.

Reviews [click to view]

Folder Metaphor

I do not recommend using the Folder Metaphor for organizing documents.

Much computer software now uses a Folder Metaphor to organize documents. The computer folder that stores computer documents is the electronic equivalent of the cardboard file folder that stores paper documents. There can be a hierarchy of folders, because like cardboard folders, computer folders can contain other folders.

But the Folder Metaphor has a problem. It is awkward if a document fits in more than one catagory, and it usually does.

Think about the example of E-mail. An e-mail message can have many different attributes, for example: Business, Personal, Advertisement, News, Humor, Flame, Interest-X, Interest-Y, Read, Unread, Needs-A-Reply, Needs-No-Reply, Has-Reply, Accurate, Inaccurate, etc. Each message probably has multiple attributes, at the same time. It isn't practical to build a hierarchy of folders to represent each possible combination of attributes by one position in a folder hierarchy. One would need to put a message into more than one folder. This might be wasteful of space and very confusing to the user.

So I recommend using Document Attributes to organize documents instead of the Folder Metaphor.

Document Attribute

Because of the problems with the Folder Metaphor and other single hierarchy ways to organize documents, TDN software should instead use Document Attributes.

This is not a new idea, but it is only recently coming into popular use. It is also known as "tagging".

Instead of listing documents in a folder, for example the "In" folder, the TDN software should list documents which have particular combinations of attributes, also known as "tags".

Examples of combinations that might be used to select documents for viewing, are:

It should be possible for any type of document to have attached attributes. Whenever a document is displayed, the attributes that are attached should be displayed with it.

Some attributes should be attached to the documents automatically. For example, each document should be assigned the attribute Unread when first received, and this attribute should be removed from the document after the user reads it.

The attachment of some attributes should be semi-automatic and controlled by options chosen by the user. For example, one user might configure e-mail software to assign the attribute Personal to a message when it's received from his mother, or assign the attribute News to messages received from news sources.

It should be possible for anybody to make new attributes, and manually or automaticly attach them to documents or detach them when desired.

It might eventually be good to allow attaching attributes to objects inside a document, in addition to the entire document. By this I mean paragraphs, sentences, or even smaller objects. For example, you might want to mark a particular sentence Inaccurate or False by attaching to it one of those attributes.

The TDN should support hierarchical attribute names, similar to the names used for Usenet news group names. These hierarchical attribute names should be used to specify political, managerial, or geographical subdivisions such as country, state, county, town, and precinct. For example a report about an event which affects all of California would have an attribute:

but one about an event that affects only the city of Burbank would have an attribute: An article about a railroad right-of-way passing through the Massachusetts towns of Bedford and Lexington that is being converted to a bicycle path would be tagged with two attributes:

These geographical attributes could be used to route documents and document references around the TDN and determine which documents are saved for the user. A TDN user would normally receive news about subdivisions in which the user lives. For example, a TDN user living in Bedford, Massachusetts would initially receive and read documents with any of these attributes:

But the user should be able to change the attribute set that describes the documents that he wants to receive and read.

Threads

A good way to organize documents is by thread.

Threads are often used to organize messages, by listing with a message all the responses to that message. Web based forum discussions, and some e-mail and Usenet reader software do this. For example, when a message is displayed, it might be followed by links to all the replies to that message, or the replies themselves. Thread displays are helpful because they display documents together by subject, and in logical sequences.

I recommend that threads be used to organize and display TDN documents. When the TDN displays a document, it should also display with it a list of links to other documents are related to that document. These include:

The TDN thread displayer should work with all types of documents with which the TDN might deal, including Web Pages, not only messages.

When a popular document is displayed, the list of links to thread-related documents might be long, or open ended. Those links should be grouped by type and each group should be displayed in order of decreasing relevance, using document Review scores if available.

[Click on (Back) button now.]

Distributed Control

No one person or computer should control the TDN. No small group of persons or computers should control the TDN. If it was controlled this way then it would be very vulnerable to control or sabotage by the Bad Guys. The Bad Guys can and do control organizations, for example corporations in the Media Establishment, by controlling only a few upper management positions.

Instead the TDN should use Distributed Control. Each TDN computer should be able to control itself, without help from other parts of the TDN. It receives data from its TDN neighbors, such as documents, reviews, and network management information, which it uses to make decisions. But it should recieve no commands. The only commands that a TDN computer should receive and execute are the ones from its user. This is the communcation network equivalent of the Leaderless Resistance.

Interference With Domain Name Servers

A way to interfere with the Internet is with Interference With Domain Name Servers. Domain Name servers are the computers and software that translate alphabetic Internet Domain Names, such as yahoo.com, to numeric Internet IP Addresss. This service is very centralized because there's a central registry for all those names and their translations.

Interference with these servers could cause Web Sites to appear to respond slowly, or appear unreliable, or disappear completely, or be replaced by imposter sites. This interference could be done with political control of the organizations that manage the servers, with technical interference with the servers themselves, or with imposter taps in the network connections to the servers.

The problem of Interference With Domain Name Servers could be controlled with Network Problem Tracking, or by having TDN software save or cache Domain Name translations locally. In this case, the TDN software could use the saved translations to recover from interference. If the server does not respond, or returns a translation that is obviously incorrect, then the saved translation could be used and operations could continue. Information about the problem and the correct translation would be communicated with TDN neighbors.

Network Problem Tracking

One way to limit the effectiveness of Counterintelligence activities against the TDN, is to record information about network problems and communicate it with others. Information about possible Interference With Domain Name Servers, Web Site Overload, and other problems, would be recorded and routed to others that could help to identify the cause of the problem. This information would be included in the Event Notification information communicated between TDN computers.

In theory this will make it easier to diagnose a problem, and fix it, or identify it as the result of malicious interference. In either case this should decrease the frequency of such problems.

Interference With Search Engines

Much evidence of Hiding Web Pages From Search Engines has been observed. This problem is interfering with people's Internet research. The problem seems to be worst when searching for documents containing politically sensitive news.

The problem of Interference With Search Enginess could be reduced by putting some Search Engine functionality in the TDN software. A search should search both the TDN document cache or the Topic Index and do the same search with a regular Search Engine, such as Google. The results from both searches should be presented. When the local search produces the better result, that result should automaticly be communicated to the user's TDN neighbors.

Disappearing Web Page

One problem with Web Pages is that they sometimes disappear. It isn't uncommon for a controversial report published on the Web to be unavailable a short time later, with no reason given. It is as if somebody read the report and told the publisher to remove it.

If the TDN is going to support Web browsing, the TDN software ought to be able to easily save permanent copies of the pages which make up the news reports. If a report later disappears from its original publication site, it wouldn't be lost, and could continue to be distributed in other ways if desired.

The documents are saved in the Document Storage system.

Document Storage

Web Browsers save copies of Web Pages in something called a cache. Usually this is a folder on the user's disk. These copies are made for performance reasons, to avoid needing to reload the same files from the Internet if referenced later. They are not permanent copies. The oldest documents are eventually deleted automatically to make room for new ones when the space allocated to the cache is filled.

The TDN's browser should also save copies of Web Pages. But it should store them with other types of documents in a general Document Storage system.

I suggest that the TDN Document Storage system have the following characteristics.

Changing Web Page

Another way that news might be lost is for a Web Page to change. In this case the page continues to exists, but its old content is replaced by new content.

Some changes are legitimate. For example some are corrections. Also some publishers reuse file names on their Web Sites. In some cases all reports, even the noncontroversial reports, are gone in less than 24 hours, replaced by new ones.

But some changes appear to be deliberate attempts to hide information. A report could be replaced by a different one, or very important facts could be deleted or changed.

To prevent loss of important information, the TDN software should compare remote pages viewed with any older copies of them in the Document Storage system. Unless the page is known to change often and legitimately, the old version should be saved, and changes should be reported to the user by displaying both versions in a way that highlights the differences.

Whenever the browser displays a document, it should indicate whether it has more than one version of it, and allow the user to easily view and compare the different versions.

Web Site Overload

A potential problem with Web Pages is overload. A Web server can become overloaded temporarilly if a new interesting report is published on it, or permanently if the site becomes popular. The problem would be worse if the site served streaming audio or video also.

The result of overload is poor response time, and the Internet Service Provider (ISP) might want to charge the site owner more. These things discourage Web publishing.

One solution used today is mirroring. Mirroring is the duplication of pages of one site on another site, spreading the load. But if the TDN uses mirroring then it should:

Another solution is Internet multicasting, if it could be made to work well. Some people claim (Live Web Page: here) to have something similar working for Internet radio. Maybe it could be adapted for the TDN.

Government Meddling With The Web

The Web is probably the least regulated of the media, but that might change.

The Internet is increasingly subsidized by our government through various taxes. The subsidies pay for high speed Internet access for government schools and libraries. Some say that this is good, but this subsidized access often has filters on it, usually to filter pornography. Pornography filters can, and have been used, to filter other types of information.

Here are some ideas about Internet regulation that have been implemented or have received serious discussion.

These rules burden a small ISP more than a big one. They will put the small ISPs at a competetive disadvantage, and force many of them out of business. A few big ones are easier to control than many little ones.

Internet laws, as all laws, can be discriminatorily enforced or used to harass. This has occurred with broadcast and print media. ISPs which permit the publication of unapproved material will be targeted most frequently and suffer the most damage.

Realize that the potential audience of every Web Page is a lot larger than the most powerful radio or TV station on the planet. This causes a large incentive to control the Web. So I would not be surprised to see many of the regulations on broadcast media proposed soon for the Web. For example:

These proposals would severely limit how the Web could be used for publishing. They would force the TDN to use Web Alternatives.

Web Alternatives [2006/08/11 updated]

If covert interference or overt prohibition makes TDN publication of unapproved news on the Web impractical, then it must be done using other methods. There are many alternative methods. Here I mention a few possibilities.

Some methods are more automatic, and the TDN user doesn't need to become involved in the routing of documents, for example:

But in some methods, the user must become very involved with document routing.

With these methods, TDN users manually pass TDN documents among themselves, with the help of TDN software. Each user selects which other TDN users, called neighbors, with which to exchange those documents. They might select their neighbors geographically, as is done with a Distributed Alert Network (DAN). Or they might use other selection criteria.

As with any type of large network, for data to spread rapidly, most TDN users should have no less than three reliable TDN neighbors with which they exchange data regularly.

Other network alternatives are possible with other technologies, such as radio wireless Internet, if there are enough users with those capabilities.

Freenet

One Web Alternative might be Freenet (Live Web Page: here). They state:

It seems to solve many security problems, but it needs work to make it Easy To Use.

Publication By E-mail

If covert interference or overt prohibition makes the publication of unapproved news on the Web impractical, then it might be necessary for TDN documents to be published by private e-mail. In other words, unapproved material goes directly from one person's or organization's TDN computer to another, using the Internet for e-mail transport only.

The TDN software would automatically e-mail new documents to the user's TDN neighbors, and it would would automatically receive documents and store them on disk for viewing by the user.

The user should not need to deal with any of these messages, and should never see them. The TDN software should handle them all. The user should see only the documents they carried.

Publication By Telephone

One Web Alternative might be Publication By Telephone. TDN neighbor computers can use their modems to communicate on their own by telephone and exchange files without using ISPs or the Internet at all. Windows Dial-Up Networking has these capabilities built in.

To minimize expenses, TDN neighbors can be local telephone calls. Wide distribution without toll calls is possible because local calling areas overlap.

Networks have been implemented this way before, for example the Fidonet (Live Web Page: here).

Publication By Sneaker Net

One Web Alternative is Publication By Sneaker Net. It is the slowest method, but it is also the most secure. It is a last resort in case electronic networks become unusable.

The Sneaker Net was the first type of computer network ever used. It got its name from the fact that data stored on removable media was carried by people on foot from one computer to another.

TDN software should be able to read to and write from popular removable media, all the latest news, documents, and data. Convenient portable and removable storage media include:

With today's advanced technology, people can not only carry media with them, they can carry portable computers with them. This includes laptop computers and PDAs (Personal Digital Assistants). Depending on the capabilties of these devices, users could exchange data using:

There are several ways that TDN users can use the above methods to implement a Sneaker Net to exchange documents and data.

For convenience, your sneaker net TDN contacts can be co-workers or people in the geographic neighborhood. But for rapid spreading of news, it would be better if most of your TDN contacts are people that do not live near you.

The reason is simple. If all your TDN contacts are next door neighbors, then news could travel only a few hundred feet per day. But if you exchanged disks with co-workers at work, then news could travel many miles per day, at least on workdays. And if you or one of your contacts work for a transportation company, then news could travel hundreds or thousands of miles per work day.

Not all of your sneaker net contacts need to be weekday contacts. For example, you could exchange TDN media with people that you see at weekly meetings, such as church services.

You should have at least 3 sneaker net neighbor contacts. 4 would be better. You could have more, but remember that more contacts means more work for you. And if you have a lot more contacts than most others, then you become a more attractive target for network disrupters, because losing you would damage more of the network.

For some helpful ideas about selecting and managing network neighbor contacts, see the Distributed Alert Network Guide (DANG).

Guaranteed Delivery

Information must flow between TDN neighbors. This information includes documents, messages, Topic Index entries, Reviews, and network management information. The TDN could be sabotaged by interfering with this flow.

For example, e-mail and Usenet messages could be sabotaged, either by interfering with message delivery, or by breaking into a communication link and becoming an Internet address imposter, also known as a man-in-the-middle-attack. An Internet imposter could make it appear that a message was delivered to its destination when actually it was delivered to the imposter. Imposters are able to block, discriminatorily forward, or in sensitive situations change and forward messages.

A countermeasure against delivery sabotage is the use of acknowledgements. This is a technique used in many communication protocols. When a TDN computer sends any information to a neighboring TDN computer, the second computer should send an acknowledgement back to the first. If the first computer receives no acknowledgement then it resends the information until acknowledgement is received or a time limit is exceeded. The user is informed only if the limit is exceeded. Normally he should not need to deal with acknowledgements.

Guaranteed Accuracy

In addition to Guaranteed Delivery of information, one must guarantee its accuracy.

To prevent unintentional errors in the information of a communication, it is common to use checksums or CRCs (Cyclic Redundancy Checks). But these are easy to fake. To prevent intentional errors in the information of a communication, something else must be used.

Pretty Good Privacy (abbreviated PGP) (Live Web Page: here), might be a way of providing Guaranteed Accuracy of communications for the TDN. PGP is encryption software. PGP and compatible software can make messages unreadable by all but the intended recipients. But something more useful to the TDN is PGP's ability to add unforgeable signatures to messages to stop imposters. With unforgable signatures one can:

The TDN software should use PGP to automatically sign all outgoing communications. This includes both regular information and acknowledgements.

The TDN software should automatically try to validate signatures on all incoming communications. If a signature is not valid then this should be reported to TDN neighbors, and the contents of the communication should be ignored.

A problem with automatic signing is the need to repeatedly input the user's pass phrase. A solution that I have seen used with PGP in e-mail software is the use of a pass phrase timer. The user is not required to input the pass phrase again if a signing operation occurred in the previous few minutes. The theory is that until the timer expires, the person in front of the computer is probably the same person who input the pass phrase the last time.

But this solution did not work well for me, and I eventually deactivated PGP signing. Though I sat working at my computer for hours, the times between messages sent was often many minutes, so I needed to input the pass phrase repeatedly. A better solution would be for signing software to act similar to a screen saver. Instead of reseting the pass phrase timer with signing operations, it should be reset with any keyboard or mouse input.

Repeated Acknowledgement

Because most of the distribution of a document happens shortly after it is first created, a document can be effectively censored by a short but concerted effort to disrupt its early distribution.

The TDN might not be able to prevent the initial censoring of a document, but it can make long term censoring expensive and impractical, and thereby make the initial censoring counterproductive.

To prevent this censorship, TDN protocols should repeatedly acknowledge all of the documents that they have sent to or received from various sources. Also they should do it in a way that makes it obvious what documents are missing.

If this is done, then to censor a document, not only must its initial distribution and acknowledgment be blocked and faked, also all future acknowledgements must be faked. Eventually the document will get through and be flagged as probably very important.

The idea is simple. When the receipt of a message is acknowledged, the receiver also acknowledges receipt of all the other messages that it has received from the same author.

Because the number of documents is so large, Repeated Acknowledgement might seem to be impractical. But Bulk Acknowledgement can make it practical.

Bulk Acknowledgement

Because of the large number of documents passed between nodes by the TDN, and the much larger number of Repeated Acknowledgements of those docuements needed for TDN Security, it is important to encode acknowledgements efficiently.

One way to encode acknowledgements is to identify documents by an author ID and a document sequence number. If done this way, then most sets of documents can be represented compactly.

For example, the short string

would represent over 200 of JoeAuthor's documents, numbered 1 through 205, 207 through 209, and 211.

If this represents a set of JoeAuthor's documents received by a TDN node, then documents numbered 206 and 210 are missing and should be resent. Documents with numbers 212 and higher should be sent also, if they exist.

Graceful Degradation With Bandwidth

The TDN could do more with more bandwidth, for example, reports with pictures, audio, or video. The TDN should eventually be able to use high bandwidth if it is available. But it should not be crippled if it is forced to move to lower bandwidth networks such as the sneaker net. It should be able to adjust the way it sends reports based on the bandwidth available, automatically if possible.

Here are some bandwidth dependent ways that a multimedia report might be sent, with higher bandwidths listed first:

Note that a transcript can always be read by computer synthesized voice.

Reviews [click to view]

Malacious Software

A way to sabotage the TDN is with a special computer virus. The virus would spread quietly, but do nothing else until the user installs or uses TDN software. At that time the virus would cause the computer to malfunction. To the user it appears that the TDN software is bad, and it would probably be uninstalled.

Another way to damage the TDN is to build similarly harmful code into another popular application program or the operating system. Microsoft did this and harmed a competitor using what became known as "The AARD Code" (Live Web Page: here).

I am not certain that there are solutions to these problems. If the security of the Windows operating system can not be improved, then it might be necessary to replace Windows completely and execute TDN software on only more secure operating systems. This is a drastic action. There are other cheap operating systems available, but they generally don't execute Windows programs. Unfortunately many users would not want to switch to another system.

It is possible, but trickier, to have both Windows and a secure operating system on the same computer. The user could use the secure operating system for the TDN software, and use Windows for the Windows software. This could be done by putting the operating systems on separate partitions of the same disk, or on separate disks. The important security requirement is that potentially destructive Windows programs must be unable to detect the presence of the TDN software or the secure operating system on which it runs.

[Click on (Back) button now.]

Reviews

The TDN must be able to handle false information which might deceive users, and useless information which in large amounts might cause Information Overload. To do this the TDN needs a document Review system. Similar systems already exist and work well, for example the comment moderation system at Slashdot.

A document's Review is a number that represents the document's value. I suggest a range of -1 to +1. A good, accurate, and true document should have a high value. A bad, inaccurate, or false document should have a low value.

A TDN user beginning a viewing session should be shown a list of unread documents, with the documents with the highest Reviews first. This helps the user find and read quickly what are probably the best documents. But the user has the option, an option not available in a Filtering system, of reading documents whose Reviews are not so good. This option will prevent a few erroneous Reviews permanently blocking a document.

Whenever the TDN software displays a document it should also display nearby its Review value.

A document's Review value is either the Review Input from the local TDN user, or a weighted average of Review Inputs from other TDN users, which is made possible by Review Sharing.

Each document always has at least one Review, the one made by the TDN user that published it on the TDN.

Review Input

To make document Reviewing easy for the user, it should be combined with the commands that are used to move from one document to another.

For example, instead of a single Back Button there would be a button array.

Bad,
Back 		Neutral,
Back 		Good,
Back

Clicking one of the buttons would simultaneously record a Review of the present document and go back to the previous viewing location.

Here is a diagram of a simple input button array for moving to the next or previous document.

Bad,
Previous 		Neutral,
Previous 		Good,
Previous
Bad,
Next 		Neutral,
Next 		Good,
Next

If the user clicks on a link in a document then this button array

Bad,
Continue 		Neutral,
Continue 		Good,
Continue

would appear under the cursor, and the user would click on a button to continue.

The TDN software should provide audio feedback for each button clicked, to instantly confirm the user's input. The feedback could be tone sequences or words. If the user makes a mistake then he can immediately undo it and click the correct button.

It might be worthwhile to provide more granularity in the buttons. Instead of only 3 review values, a larger number or a continuous range might be better. But it should not make selection more difficult.

Review Sharing

Document Reviews are not very useful if they are not shared.

The main purpose of document Reviews is make it easy for a TDN user to find documents that he wants to read. But how do you know that you like a document before you read it? You use the reviews of others that have read it. This means Review Sharing.

The TDN software should pass document Reviews around the network with the documents (or document references) with which they are associated, or alone if the associated document has already been passed.

Here is a diagram showing how document Review scores might be calculated. Document IDs go in at the top. User IDs go in at the left. Document reviews come out at the bottom. User reviews come out at the right. 

TDN Document Review Value Calculation

o-----------< User IDs
|
|   o------< Document IDs
|   |
|   o-> -- ID1 -------------- ID2 --------------..
|
|           v                  v
|  Local    |                  |
   User     |                  |
IUL >-------|------o-----------|------o---------->..
            |      |           |      |
|           |      v           |      v
|           |     +---+        |     +---+
|           o---->|DR |->o     o---->|DR |->o
|           |     +---+  |     |     +---+  |
|           |            |     |            |
|           |            v     |            v
|  Remote   | o<---------o     | o<---------o
   Users    | |                | |
IU1 >-------|-|----o-----------|-|----o-------->..
            | |    |           | |    |
|           | |    |   o--< 0  | |    |   o--< 0
|           | |    | o-|-------|-|----|-o-|----<..<---o
|           | |    | | |       | |    | | |           |
|           | |    v v v       | |    v v v           |
|           | |   +-----+      | |   +-----+          |
|           o-|-->| CR  |      o-|-->| CR  |          |
|           | o-->|     |      | o-->|     |          |
|    0 >----|-|-->|     |------|-|-->|     |--->..>---o-> RU1
|           | |   +-----+      | |   +-----+
            | |        |       | |        |               |
IU2 >-------|-|----o---|-------|-|----o---|---->..        |
            | |    |   |       | |    |   |               |
|           | |    | o-|-------|-|----|-o-|----<..<---o   |
|           | |    | | |       | |    | | |           |   |
|           | |    v v v       | |    v v v           |   |
|           | |   +-----+      | |   +-----+          |   |
|           o-|-->| CR  |      o-|-->| CR  |          |   |
|           | o-->|     |      | o-->|     |          |
|    0 >----|-|-->|     |------|-|-->|     |--->..>---o-> RU2
|           | |   +-----+      | |   +-----+
|           | |        |       | |        |               |
|           v v        v       v v        v               |
.           . .        .       . .        .               .
.           . .        .       . .        .               .
              v        v       . v        v               .
              o-o      |         o-o      |               |
                |      |           |      |               |
                v      v           v      v               |
               +--------+         +--------+              |
               |1      2|         |1      2|              |
               |Priority|         |Priority|              |
               +--------+         +--------+              |
                   |                  |                   |
                   v                  v                   |
                   RD1 -------------- RD2 ------..->-o    |
                                                     |    |
                                 Document Reviews <--o    |
                                                          |
                                 User Reviews <-----------o
The following abbreviations are used in this diagram.

The review value of each document comes from a Priority gate near the bottom, and is calculated as follows:

The details of the CR (Cumulative Review score) module are shown next. 

CR (Cumulative Review value) module.

                Remote           Remote   Cumulative
              v User           v User   v Document
              | Id             | Review | Review Input
          +---v----------------v--------v---+
          |   |                |        |   |
          |   v                v        v   |
          |  +---+           +---+    +---+ |
>--------->->|DR |----->o--->| * |--->| + | |
Document  |  +---+      |    +---+ ^  +---+ |
ID        |             v          |    |   |
          |           +---+        |    |   |
>--------->---------->| * |        |    |   |
Local     |           +---+        |    |   | Cumulative
User      | review      |   scaled |    |   | Remote
Document  | agreement-> |   review-o    |   | User
Review    |             v               |   | Review
          |           +---+             |   | Output
>--------->---------->| + |-------------|--->--->
Cumulative|           +---+             |   |
Remote    |                             |   |
User      +-----------------------------v---+
Review                                  | Cumulative
Input                                   v Document
                                          Review Output

The following additional abbreviations are used in this diagram.

A document's Review score is either the Review Input from the local TDN user, or a weighted average of Review Inputs from other TDN users. The weights used in the average are the degrees of agreement between the Review scores of other documents that both the local user and other users have read.

So the local user controls his documents' Review scores, either directly by doing them himself, or indirectly by the amount of agreement between him and other reviewers.

The large diagram above explicitly shows only two documents and three users. Double dots represent continuation of the diagram to represent all users and documents.

There will be a large number of users, and a larger number of documents. So cumulative reviews should be computed incrementally. This means that time needed to recalculated reviews is proportional to the number of users or documents added to or subtracted from the system. It does not depend on the total number of users or documents in the system.

To make incremental computations possible, cumulative review values, which represent weighted averages, should be represented and stored as pairs of numbers. The 2 numbers are:

When a real review score in the range of -1 to +1 is needed, the total review score is divided by the total weight, giving the weighted average review score.

This system might be improved by associating Reviews with Document Attributes instead of entire documents. For example, a report about a local event in Bedford Massachusetts might have a high Review attached to the "us.ma.bedford" attribute, but very low scores attached to the "us.ma" or "us" attributes, if any. This would solve the Document Attribute equivalent of a problem known as cross-posting.

Review Prejudice

The TDN's document Review system will not necessarilly rate true documents highly.

If you give high review scores to documents that agree with a Prejudice, then you will tend to see more documents with a similar prejudice. But this is not a problem with the TDN because:

[Click on (Back) button now.]

Alphabetical Site Index