Backtalk Features

1. Stable Release:

1.1. Conference Structure:

• An unlimited number of conferences can be created. Conferences are typically oriented around some particular subject area. One or more users can be designated as "hosts" or "fairwitnesses" to watch over each conference. The conference menu design allows related conferences to be grouped together.

• Each conference can contain an unlimited number of discussion topics or items. Only the fairwitness can enter the first item, but after it is entered, any user can start a new item. Each item has a title and a body of text that introduces a new discussion thread.

• Each item can have an unlimited number or responses. Any user can append a response to the end of an item. Responses are always displayed in chronological order, and appear together with the item text on a single page. Because the discussion thread is coherent, linear and sequential, readers do not need to follow branching trees of discussion and posters do not need to quote previous responses in their messages. The whole discussion thread is kept together. If users are inspired to start a new discussion thread, they can enter a new item.

• Backtalk maintains accounts for each user of the system. Users can log into their own personal account by giving an account name and password. This provides access control, and it allows the system to remember for each user which responses and items have been seen and which options have been set.

• Backtalk remembers what you have seen. On each visit to a conference, Backtalk displays only items and responses that you have not seen before, unless you specifically request to see older material. Many new bulletin board systems do not do this, a great leap backward in conferencing technology.

1.2. Access Control:

• Backtalk includes a web-based account creation tool. This allows new users to request an account simply by filling out a short form. The accounts are created instantly and, by default, may be used instantly to access the conferences. Alternately, Backtalk can be set up so that new accounts need to be validated before they are usable, or the account creation tool can be restricted to administrators only.

• The login screen can be either an on-page form or a pop-up box. Backtalk supports both basic-authentication and session-based logins. If the latter option is chosen, working logout buttons appear on most screens.

• Web surfers without accounts can be allowed read-only access. Backtalk can be set up so that users without Backtalk accounts can have read-only access to the conferences. Naturally it does not remember which items and responses have been seen by these anonymous users.

• Individual conferences can be restricted to selected users. Normally all conferences can be accessed by anyone with an account, but it is possible to "close" accounts, either allowing only those users whose name appears on a list, or allowing only those who know a conference password. Other users can either be excluded completely from the conference, or can be allowed read-only access to the conference.

• User groups are fully supported. Administrators can create user groups and assign each user to one or more groups. Access to conferences can be controlled on the basis of groups as well as individual users.

1.3. User Interfaces:

• Lists of recent postings can be shown on entrance page. A summary list of the most recent postings can be shown on the entrance page. This is often a good way to help users find the parts of the system where the most active discussions are occuring.

• Users can maintain their own "hot list" of interesting conferences. It's simple to read all new items and responses in all your "hot list" conferences. Users start out with a system-wide default "hot-list" and can edit it to fit their tastes.

• Users are provided many ways to read conferences. The most common thing people want to do is read all new items and responses, or get a list of current items and responses. Pistachio offers big buttons for these operations. There are less conspicuous buttons that allow you to read all items, or everything posted after some date, or read only selected items.

• Favorite items are shown first. Users can mark items as 'favorites'. This causes them to be shown before all other items when reading a conference. By default, any item entered by the user is automatically a favorite, and any item responded to by the users is automatically a temporary favorite (it is a favorite until the next time it is read).

• Users can ``forget'' items they are not interested in. If you mark an item as being ``forgotten'' then you won't be shown it again when you ask to ``read new'' items on future visits, even if there are new messages posted to it. This allows users to filter out conversation threads that don't interest them.

• Users have several formatting options in postings. Postings can be made as simple plain text. When displayed, URL and references to other items and responses are automatically made clickable. Users can also enter postings containing HTML directives, if the conference is configured to allow it. The HTML in user postings is automatically sanitized, ensuring that no undesirable tags (like <SCRIPT> or <BLINK>) are used and that all tags are closed, so their effects do not run over into other responses. Whether or not images are allowed in responses is separately configurable.

• Users may be allowed to hide or erase prior responses. Hidden responses are not displayed by default, but they aren't very hidden - one mouse click brings them up on the user's screen. Hiding responses is useful for big long things that not everyone will want to see. Erased responses, on the other hand, are no longer viewable by ordinary users (a copy is kept in a log file, so they can be restored if necessary). Whether authors are allowed these powers over their past responses is configurable.

• Users may be allowed to edit prior responses. We think it is usually disruptive to the flow of on-line conversations to allow users to edit things they have said in the past, so we don't encourage use of this option, but it is available.

• Users may be allowed to freeze or retire items they entered. A frozen item can no longer be responded to by anyone else. A retired item is effectively forgotten by everyone - it isn't shown by default, but can still be seen if people specifically ask for it. Whether or not authors of items have these powers is configurable.

• Users may be allowed to retitle items they entered. Sometimes if the conversation drifts onto another subject, it is useful to be able to change the title of the item to reflect this. So you have the option of lettings users retitle items they originally entered. Users can also set "private titles". These are shown instead of the real title for the user who set it only.

• Users can attach images or documents to their posts. Backtalk now supports attaching files of various types to postings. This is similar to the way you can attach files to email messages. There are also tools for adding, deleting or editing attachments on existing responses. There still needs to be some quota system limiting the size of attachments before this is really practical for most systems.

• Users can search the conferences. A flexible search system allows users to search a conference for references to specific words or for postings by particular items.

• Users may reconfigure their own accounts. They can maintain a page of information about themselves that is visible to other users. They can reset their passwords, and change many different configuration settings. They can set the time zone to use in displaying dates and times. They can even delete their own accounts.

• Spell checking. Backtalk can use the ispell or aspell spell checking programs to do spell checking on user's postings.

• Help buttons abound. We have aimed to make the interface as self-explanatory as possible, but most pages have help buttons that provide detailed help messages.

• Abalone Interface. The abalone interface has a more professional and structured look, and does navigation mainly through pull-down menus and pop-up dialog boxes instead of buttons. Style sheets control the appearance of pages. Users and administrators can develop their own style sheets. Unlike Pistachio, it makes heavy use of JavaScript, however nearly all features work even on browsers that do not support JavaScript. (The major exception is the spell-checker, which is too cool to work without JavaScript.) It has almost as complete a feature set as Pistachio, and will likely replace Pistachio as the "flagship" interface someday.

• Bubblegum Interface. The bubblegum interface is a simplified, kid-friendly interface originally developed for the Canton Michigan Public Library's PULSE ("Partnership Uniting Libraries and Schools Electronically") Project. It has a slightly simpler interface and a slightly reduced feature set.

• Gumball and Gumdrop Pseudo-Interfaces. Gumball and Gumdrop are wrappers for the bubblegum interface. They are design to present a view to the user in which only one conference (in gumball) or only one item (in gumdrop) is visible.

• Papaya Interface. The papaya interface flavor provides a look and feel similar to the installation of Yapp 3.0 on Arbornet.org before they switched to Backtalk. It was developed for that site to ease the transition from Yapp to Backtalk. It has a fairly respectable feature set, but is a bit less capable than pistachio or abalone.

• Vanilla Interface. This was Backtalk's original interface. It was designed to work well with text-based browsers like lynx. New features are no longer being added to it.

• Cinnamon Interface. Cinnamon is not a standard user interface, but rather a syndication interface that can generate RSS or Atom feeds for a Backtalk site. It supports a wide variety of syndication formats, including:

  RSS-0.91
  RSS-1.0
  RSS-1.1 (draft)
  RSS-2.0
  RSS-2.0 with Dublin Core extensions
  Atom-1.0
  

  There is also support for RSS-3.0 and ESF, but these are best regarded as expressions of geek humor, not serious syndication formats.

1.4. Fairwitness Powers:

• Fairwitnesses can configure the look of their conference. They can select text and background colors, background patterns, and button styles and colors. They can write custom greeting messages in text or HTML. Users can over ride the "look" settings on a per-conference basis.

• Fairwitnesses can select which item to show to new users on their first visit. In a large conference, having every item be ``new'' when a person first visits can be rather overwhelming, forcing them to wade through years of old discussions to find active discussions. With Backtalk, fairwitnesses can say that only certain items will be treated as ``new'' and/or only items that have had activity within some number of days. Other items will show up as ``new'' on future visits as new responses are made to them.

• Fairwitnesses can link items into their conferences. If fairwitnesses learn of an item in another conference that would be of interest to users in their conference, they can link it in, so that it and all its responses effectively appears in both conferences.

• Fairwitnesses can delete items. Keeping the size of a conference manageable is typically one of the jobs of the fairwitness. Thus fairwitnesses have the ability to remove any item from their conference. If the item is not linked to other conferences, this means it would be removed completely and permanently.

• Fairwitnesses are allowed to freeze, retire or retitle items. Instead of only being able to freeze, retire or retitle items they posted, fairwitnesses can do so for all items in their conferences.

• Fairwitnesses may be allowed to hide, erase, edit responses. If enabled these options allow fairwitnesses fine control over items by operating on individual responses. We think allowing fairwitnesses to edit other people's statements would be an extremely bad idea under almost any circumstances, so the option is turned off by default. The original text of any erased or edited responses is saved in a log file which is accessible by the system administrator.

• Fairwitnesses can control who may access their conference If a conferences is set up as a "closed" conference by the Backtalk administrator to only allow some users in, then the fairwitness has the power to edit the list of users allowed in, or change the password needed to access the conference.

• Fairwitnesses can control whehter robots are excluded from their conferences Backtalk can generate robot exclusion meta-headers on all of its pages. This can be set up so that individual fairwitnesses can decide whether to let robots into their conferences.

1.5. Administration Tools:

• Complete account administration tools. Administrators may create, validate, invalidate, or delete accounts. They may list user accounts sorted by login name, registration date, or last access date. They may edit user's settings and change their passwords. There are good tools for searching for users, and for reaping unused user accounts.

• Complete conference administration tools. The conference administrator may be create, destroy, open or close conferences from the web interface. Fairwitnesses can be assigned and conference menus can be maintained. The administrator also can function as a fairwitness in any conference, and can link, freeze, retire, retitle or delete items, and hide, erase, or edit responses even if those powers are not enabled for real fairwitnesses.

• Administrative ``How-To'' manual included. This describes in detail how to do most normal administrative operations either manually or using the web-based tools.

• Easy to Install. Well, relatively speaking. Backtalk is a complex and highly configurable system that interacts in a sophisticated way with your HTTP server and many other parts of your system. A 'configure' script handles most configuration tasks for you, and a 'make install' script does the installation. There are detailed installation instructions.

1.6. Compatibility:

• Picospan and Yapp compatible. Backtalk uses the same database structure as the popular text-based conferencing systems Picospan and Yapp 2.3 or Yapp 3.0. This makes it possible for Backtalk to either run as a stand-alone system or to share conferences with Yapp or Picospan. It can even generate non-HTML versions of HTML postings so they can be read easily by users of those text-based systems.

• Works on any Unix system. Backtalk runs on almost any flavor of Unix. It has been tested (to various degrees) on Linux, SunOS, OpenBSD, Solaris, Mach, FreeBSD, NetBSD and Ultrix and should port easily to any other Unix system. A Windows or Macintosh OS 9 version is not planned at this time, but Macintosh OS X should work fine.

• Works with any HTTP daemon. Backtalk works with all popular http servers, though some configuration options require Apache.

• Year 2038 Compliant. Backtalk has been thoroughly checked for year 2000 bugs. Backtalk is probably even year 2038 compliant - we'll have to check that more thoroughly when we find a year 2038 compliant version of Unix to test it on.

1.7. Configurability:

• Extremely configurable user-interface. Backtalk is actually an RPN interpreter similar to PostScript. The look, structure, and behavior of the system is all determined by the scripts instead of being programmed into Backtalk. This means a choice of interfaces can be offered to users, custom interfaces (including non-English ones) can be quickly developed, and new HTML features can be rapidly exploited. Backtalk's script language is a full-featured programming language, supporting conditionals, loops, arrays, dynamic variables, regular expressions, and recursion. Tutorial and reference manuals for the script language are included.

• Configurable powers. Backtalk allows each site to decide which powers should be granted to users and fairwitnesses. The abilities to kill or retitle items, or to hide, erase or edit responses are always available to the system administrator, and may be permitted to fairwitnesses for use in their own conferences, or to users for use on their own items and responses.

• Configurable terminology. If you want to use different names for "conferences", "items", "responses" and "fairwitnesses" (e.g., "forums", "topics", "postings", and "hosts") you can configure them into Backtalk.

• Alternative user account database structures. Site administrators often want users to be able to log into a conferencing system and other web applications using the same login and password, without having to re-login when moving from one site to another. Backtalk is designed to be easy to adapt to do this. It's user and password databases interfaces are very modular. Modules are included to authenticate from flat text files, four kinds of hashed db files, or an SQL database. Interfaces for MySQL and PostgreSQL exist, and ones for other SQL servers could readily be developed. The SQL interface is very configurable, so that almost any pre-existing set of tables can be used. A separate manual describes how Backtalk's authentication system can be linked to other web applications.

• Direct authentication with Unix accounts. Normally user accounts for Backtalk are completely separate from actual Unix accounts on the host system, so conferencing accounts can be given to users without giving any other access to the system. But, for compatibility with Picospan, Backtalk can be configured to authenticate with real Unix accounts out of the system's password database instead of using its own internal accounts for authentication. This works securely even on Unix systems with shadow password databases. Doing this requires use of the Apache http daemon, mod_auth_external, and pwauth. Naturally Backtalk's account administration tools cannot be used with real Unix accounts (use the Unix tools instead).

1.8. Performance:

• C Language. Many bbs systems today are written in an interpreted language, like Python, PHP, or Perl. Being written in C, a compiled language, gives Backtalk a substantial performance advantage.

• RPN Script Language. The interfaces are implemented in a custom RPN script language, vaguely similar to Postscript or Forth. RPN script languages were invented to squeeze the most performance possible out of relatively weak processors. (Postscript was designed to be run by embedded processors in early printers, and Forth was designed to be run by early telescope controllers.) What RPN languages lack in legibility, they make up in execution speed.

• Script compilation. Unlike most other script-based web conferencing systems, Backtalk pre-compiles its scripts into a binary format that can be executed more quickly than the text format. These compiled scripts are saved to a file so they do not have to be recompiled for every hit. The compiler includes structures similar to C-language "#ifdef" and "#define" statements so that chunks of code not used in your configuration are can be omitted from the binary files. It does a fair amount of optimization.

• Item indexing. Backtalk's database structure is compatible with that used by Picospan and Yapp, but has been extended to overcome some of the significant weaknesses of that file format. Backtalk adds item index files that allow rapid access to arbitrary responses while maintaining complete compatibility.

2. Development Release:

Major features in the 1.4.x development branch include:

• Improved Email Address Security. Users are offered a four different options to protect the privacy of their email addresses. If, like me, your email address is already all over the net, you can have it publically readable and clickable. If you'd like most humans to be able to get it, but would like to make it hard for robots to harvest your email address, then you can choose to have it displayed by tiling it out of images and not making it clickable. If you want a bit more protection, you can make it readable only to registered users. Or, if you are as paranoid as you probably should be, you can make it inaccessible to anyone except system administrators.

• Proxy Mailer. If you want to send mail to a user whose email address is secret, and if the user has permitted it, then there is new a backtalk page that you can use to send mail to that user. The mail is sent by backtalk with the reply address set to the sender's address.

• E-Mail Address Validation. System administrators can now configure Backtalk to do email address validation, in which a message is sent to the user with a link in it. If the user clicks on the link, their address is validated. Backtalk requires that your address be validated before you can send or recieve proxy mail. Once we teach it to mail new postings to users, they'll need to have validated addresses first. Alternately, administrators may configure the system so email address validation is required before a new user's account can be used at all.

• Wasabi Interface. The wasabi interface is the interface developed specifically for the Great Green Room. It's kind of a blog-like thing.

• SQL Conference Indexing. Historically Backtalk (and Picospan) kept meta information about conferences, items, and responses in files. We have started to implement an option that keeps this kind of data in an SQL database instead. This is incomplete and should probably not be used for anything except running Wasabi, which requires it.

• Anonymous Posting. You can optionally allow users who are not logged in post items or responses. This defaults off, but can be turned on for any conferences where it is wanted.