Building a modern home for more than three decades of demoscene history, while continuing a BBS tradition that has been part of TRSI for decades.
Rebuilding a website for a demoscene group with more than three decades of history sounds simple enough.
Put the old releases online. Add a member list. Write a few articles. Upload screenshots. Maybe add a music player.
That was more or less where we started. It was not where we ended up.
What gradually emerged behind TRSI.org is a much larger system. WESTPOINT is a browser based BBS, archive, content system, media backend and preservation platform. It connects releases, graphics, music, members, articles, party photographs and decades of scene history.
The public website at TRSI.org is only one view into it.
This first part is about why WESTPOINT exists, why it looks like a BBS, and why preservation became more important than simply building another website.
Why a BBS?
The decision to make WESTPOINT look and behave like a BBS was not just nostalgia.
TRSI has a long history with bulletin board systems, both as users and operators, and also as creators of BBS software and tools.
One important part of that history is FAME, a multi-node Amiga BBS system developed by Strider/TRSI in the 1990s. Around FAME, TRSI also produced BBS related tools, and years later the tradition continued with FAME-FTPd, an FTP server for FAME systems. But there are also quite tons of tools and doors that Siegel has created over the years. These are gradually being migrated to Westpoint, but that’s another story, one that Siegel might want to tell himself in an article someday.
So when the idea of a new archive appeared, building it in the form of a BBS felt natural.
The tradition deserved to continue, just in a different form.
WESTPOINT is not an Amiga BBS running behind a modem. It is a modern browser application. But the terminal aesthetics, keyboard navigation, menus, file areas and SYSOP language deliberately continue something that has been part of TRSI for a long time.
There is also a small detail on the first screen that sums up the philosophy rather nicely.
The large WESTPOINT artwork is real ANSI.
It is not a PNG or JPEG made to look retro. WESTPOINT actually renders ANSI data in the browser.
That detail introduces one of the central ideas behind the project: if the browser can be taught to understand the original format, we would rather do that than replace the original with a screenshot.
Figure 1: WESTPOINT deliberately keeps the interaction model of a classic BBS. The large welcome artwork is actual ANSI data rendered in the browser, not a baked PNG or JPEG.
How WESTPOINT began
Over the years, TRSI made several attempts to share and present its history and current activities. There were websites, Facebook, X and other social-media channels. The problem was that projects like these were often driven by individual people.
As long as that person had the time and motivation, everything worked. When they lost interest, a project could become a grave. And, as life has unfortunately reminded us several times in the not so distant past, sometimes people simply are no longer there.
In the worst case, the work, knowledge and content disappear with them.
Madison had already started thinking seriously about this problem and began building a new website. Through many meetings and conversations another idea became increasingly important:
We need our own archive.
What happens if Demozoo, CSDb or another resource we depend on disappears one day?
How do we keep together everything TRSI was, everything it is today, and whatever it may become in the future?
The BBS idea solved two problems at once.
It continued part of TRSI's own software history, and it gave the archive a structure that already made sense for files, users, uploads, messages, operators and public or private areas.
We also wanted people who never owned a modem to experience at least some of what a BBS felt like. Telnet BBSs still exist, but realistically, only a small audience will configure a Telnet client just to have a look.
WESTPOINT therefore had to find a balance.
It should feel nostalgic without becoming unnecessarily difficult to use. Keyboard navigation and terminal aesthetics could remain, while uploads, editors, previews and administration could take advantage of a modern browser.
The result is not an emulated historical BBS.
It is a modern system that happens to speak the visual and interaction language of one.
A BBS with an actual job to do
WESTPOINT still has users, file areas, chat, online-user information, private mail and SYSOP functions.
But those things are only one layer. The same system also manages releases, music, graphics, member data, articles, metadata and Party Postcards.
Figure 2: The SYSOP environment combines traditional BBS administration with content management, submission queues, live chat, archive tools and operational information.
Private communication mattered too, which is why encrypted private messaging became part of the system.
But one requirement stood above almost everything else:
If something happens to one of us, the archive must not disappear with us.
The data had to be portable. Moving WESTPOINT to another server should not require rebuilding a complicated infrastructure. Backups had to exist internally and externally. The documentation had to be detailed enough that another TRSI member or developer could take over without first reverse-engineering years of decisions.
The Public Archive grew out of the same idea. A ZIP archive can survive independently of the live site, and external archival copies add another layer.
Life has shown us that we are not immortal.
But perhaps we can make the data a little more immortal, even when we eventually become the real Sleeping Gods.
Losing TRSI.org taught us what "ownership" really means
There was another experience that strongly influenced this thinking.
We have already lost trsi.org once.
After Steve passed away, control of the domain was lost. It eventually ended up with a third party that wanted a substantial amount of money to sell it back to us.
We were able to significantly lower the price and reclaim the domain.
But the experience was painful because something that had always felt like a permanent part of TRSI suddenly was not ours anymore.
That changes how you think about infrastructure.
Today, continuity is treated as a technical requirement rather than an assumption. Access must not depend on one person. The complete source code is stored in Git and is available to TRSI members. Server data is backed up. Public archives can be exported. Important access paths are organised so that somebody else can continue if necessary.
The lesson was simple:
Owning the content is not enough if access to the systems around it can disappear.
Preservation includes credentials, repositories, documentation, domains, backups and succession.
The moment WESTPOINT became more than a BBS
For quite a while, WESTPOINT was still primarily thought of as the archive and BBS.
That changed with the introduction of the Extended Editor.
Once articles could be created comfortably inside WESTPOINT, with titles, teasers, publication states, media libraries, hero images, tags and archive relationships, something became obvious.
WESTPOINT was no longer just a place where content ended up. It had become a place where content could actually be created and maintained.
That was the decisive moment.
If articles could be edited there, if releases, music, graphics and members could already be referenced there, and if WESTPOINT could expose exactly the public subset that a website was allowed to see, there was little reason to build a second content-management system beside it.
The archive could become the backend.
TRSI.org could concentrate on presentation.
Figure 3: The Extended Editor was the turning point. WESTPOINT could now create editorial content rather than merely store archival records.
Articles also need media, captions, credits and hero images.
Figure 4: Article media is managed alongside the article itself. Original files are preserved while browser-friendly presentation variants can be generated separately.
Once this worked comfortably enough, WESTPOINT became the technical foundation underneath the new TRSI.org.
From "Why" to "How"
WESTPOINT had started as a BBS and archive.
With the Extended Editor, it had become something more: the backend behind TRSI.org.
That is where the second part begins.
Part 2 looks at how WESTPOINT and TRSI.org actually work together: the public API, stable identities, original-format playback, C64 and Amiga previews, Radio, Party Postcards, the Public Archive and the technical decisions that keep the whole system portable.
Part 2 will be published soon, be patient.
