1. Stable Release:
This page describes the features in Backtalk's 1.3.x stable release. The
section at the end describes additional features in the 1.4.x
1.1. Conference Structure:
Backtalk is based on the Confer model of computer conferencing.
This model is widely recognized as the best way to organize active, open,
This type of conferencing system
has proven an excellent compromise between structure and flexibility
in many places including M-Net, Grex, and The Well.
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
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
Backtalk maintains accounts for each user of the system.
Users can log into their own personal account by giving an account name and
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
Many new bulletin board systems do not do this,
a great leap backward in conferencing technology.
1.2. Access Control:
Backtalk supports a wide range of access control options to control who can
see what, and who can post where.
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
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:
There are currently six different Backtalk interfaces flavors
available, three web interfaces included in the main distribution
(pistachio, vanilla and abalone), two separately distributed add-on web
interface (bubblegum and papaya), and one command-line interface (fronttalk).
The web interfaces are designed to be simple enough for new users
to readily understand without having to study a manual, and powerful
enough to provide experienced users with a range of options, but to have
very different looks and controls. We'll describe the features of the
main interfaces, pistachio:
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
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
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
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
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
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
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
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
They can set the time zone to use in displaying dates and times.
They can even delete their own accounts.
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.
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.
It has almost as complete a feature set as Pistachio, and will likely
replace Pistachio as the "flagship" interface someday.
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.
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.
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
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:
There is also support for
but these are best regarded as expressions of geek humor, not serious
RSS-2.0 with Dublin Core extensions
1.4. Fairwitness Powers:
Fairwitnesses or conference hosts are users assigned to oversee a specific
conference. Normally the job is best done by gentle persuasion, but Backtalk
can be configured to allow fairwitnesses special 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
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:
Backtalk includes a complete set of administration tools for maintaining
conferences and user accounts.
There are both web-based versions and command line tools, the latter being
designed to be usable both directly and from custom scripts.
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
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
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.
Backtalk is designed to be portable and configurable, and to be
able to coexist with other conferencing systems.
Picospan and Yapp compatible.
Backtalk uses the same database structure as the popular text-based
conferencing systems Picospan and
Yapp 2.3 or
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.
The authors of Backtalk recognize that the needs of different systems and
users vary widely. Backtalk is designed to be extremely flexible and
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.
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.
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,
account administration tools cannot be used with real Unix accounts
(use the Unix tools instead).
Backtalk was developed for use on Grex,
a low-budget system which had about 30,000 users running on an
antiquated Sun-4 server.
This machine was always seriously overburdened,
so to make Backtalk at all
usable there, we have made performance a high priority.
All the features described above are in the current stable release of Backtalk.
New versions of the stable release contain only bug fixes, no new features.
A development release is also available. This is where we do new feature
development, which always has some risk of introducing new bugs.
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.
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.
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.
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
Or, if you are as paranoid as you probably should be, you can make it
inaccessible to anyone except system administrators.
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.
The wasabi interface is the interface developed specifically for the
Great Green Room. It's kind of a blog-like
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.
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.
E-Mail Jan Wolter
Thu Sep 29 20:36:21 EDT 2005