YAPP 3.0 FEATURES

The original feature set of Yapp 3.0 — the conferencing software that ran spring.net from 1996 to 2001.

Source: armidalesoftware.com/yapp/features.html · Reproduced for design reference

Each feature carries a status flag for the 2026 reconstruction at austinspring.com: HAVE already implemented · PARTIAL partly working · TODO on the roadmap · PASS deliberately not adopted

Customizable

Site-wide and per-conference theming PARTIAL

A system administrator can tailor (via the WWW) the overall look and feel of Yapp's web pages to fit their web site. Each conference can optionally be tailored by the host(s) of the conference. In Unix text-mode, each user can customize the formats of various tables as well. This should be true in the near future for the WWW as well.

2026: Single phosphor CRT theme across the whole BBS. Per-conference theming and per-user table format preferences are not implemented — Paul could add a theme picker (e.g. “1996 mode” vs current dark, sepia, etc.) and per-conference accent colors.

Expandable

Scriptable, Unix-pipeline-friendly PASS

Because of the scripting-language capability of Yapp, anyone with Unix access can expand WWW functionality by writing scripts to access Yapp information. Also, Yapp is able to interact with other Unix utilities, pipe output through filters, etc.

2026: The Flask + SQLite stack is itself trivially extensible from Python. The Spring 2026 doesn't expose a scripting layer to end-users — that role is filled by the build scripts Paul controls (build-thread-pages.py, etc.). Could add a JSON API at /bbs/live/api/ for external scripts.

Hierarchical administrative model

Per-conference hosts overseen by site admin(s) TODO

Yapp allows each conference to be directed by a different set of hosts, each with administrative power over that particular conference. The hosts are overseen by one or more conference administrators, who have control over conference creation/deletion etc. This allows administrators to delegate authority over specific conferences to others, instead of having to oversee everything.

2026: Schema has is_admin on users but no host-per-conference. Add a conference_hosts(conf, user_id) table; let admins delegate; show a “host” pill next to host posts. Highest-leverage governance feature.

Conferences linked to mailing lists

Email integration both ways TODO

Yapp allows each conference to be optionally linked to an email list. Thus, all messages sent to the list will appear as Yapp responses, organized into topics by subject. When a mailing list consists of several Yapp systems, this allows a conference to be shared between any number of remote sites. Another important use is to allow users to keep up on a Yapp conference without logging in by joining a mailing list.

2026: No email layer at all. Lowest priority for now (deliberate — The Spring 2026's no-email ethos is part of the appeal). But a one-way digest email (“here's what's new on Porch this week”) would be light-touch and high-engagement.

Text-based mode

Telnet/SSH terminal access, PicoSpan compatibility PASS

For systems which allow access via Unix logins, being able to access the full functionality of Yapp from any type of terminal can be very important. Compatibility with PicoSpan means that users already familiar with PicoSpan from the WELL, etc. don't have to re-learn anything. Also, all data files are compatible, so that Yapp and PicoSpan can even co-exist on the same system using the same files.

2026: Web-only. Telnet/SSH BBS access is a romantic feature but unused in 2026. The phosphor CRT styling already gives the “terminal” aesthetic in the browser.

Rich feature set

Search, link, freeze, censor, forget, list PARTIAL

Yapp contains many features which have proved very useful for large conferencing systems over many years of experience. These include, but are not limited to, searching for text either in topic subjects or in the text of topics, linking topics to multiple conferences, freezing topics so they don't allow responses, censoring responses, letting users “forget” topics they aren't interested in, and listing the participants of a conference.

2026:

Search — TODO — Flask /search endpoint, grep across cached thread bodies + comments + new posts
Link to multiple conferences — TODO — could be tags (e.g. #colin-firth tag spans drool + movies + tv)
Freeze a topic — TODO — threads.frozen bool, hosts toggle
Censor a response — TODO — soft-delete with reason
Forget a topic — TODO — per-user hide
List participants — HAVE at /bbs/live/members

Public read-only conferences

Browseable without login HAVE

Yapp optionally allows special “public” conferences which can be accessed in a read-only fashion via the WWW without authenticating. This is useful when you want to “advertise” information from Yapp and provide links to the information from outside pages. This way, users are not bothered with having to go through the new user or login procedures in order to access those pages.

2026: All conferences are public read-only by default. Login required only to post. Matches the original yapp affordance perfectly.

Simple, secure URLs

Stateless, bookmarkable, no idle timeout HAVE

Since no user state is encoded in the URLs, any Yapp URL can be referenced anytime, anywhere, by anyone. Thus, no “half-hour security holes” exist as might exist with advertising your URLs into other Web BBS systems. Also, Yapp does not impose any “idle time” limit when reading conferences.

2026: URLs are stateless and bookmarkable: /bbs/live/archive/drool/116/?page=5#r234 goes exactly where you'd expect, anytime, no session encoded. Sessions are cookie-based, separate from URLs. Aligned with original yapp principle.

HTML sanity-checking

HTML in responses with validation PASS

Yapp allows HTML in responses, and can detect invalid HTML, allowing the user to correct mistakes before the final submission.

2026: Plain text only, escaped at render time. Markdown would be a better fit for 2026 (familiar to anyone who's used GitHub, Discord, etc.) and avoids the XSS surface of raw HTML. TODO — switch comment bodies to Markdown rendering.

About this page. The plain feature descriptions above are reproduced verbatim from the Yapp 3.0 feature list at armidalesoftware.com/yapp/features.html. The status flags and the “2026” commentary boxes are specific to this reconstruction, written by Paul at austinspring.com to track which yapp affordances The Spring 2026 has, lacks, or has deliberately departed from.

Companion pages: users guide · manual (same as users guide) · quick help · archive index · live BBS