How WESTPOINT and TRSI.org turn one archive into a website, media platform and preservation system.
In Part 1, we explained why WESTPOINT exists, why TRSI chose the BBS format, and why preservation became one of the project's central goals.
Now comes the technical part.
How do WESTPOINT and TRSI.org actually work together?
Two systems, one archive
One architectural rule sits at the centre of the whole project:
WESTPOINT is the source of truth. TRSI.org is the public presentation layer.
That separation avoids duplicated information.
If one version of a release exists in an archive, another on a website and perhaps a third one somewhere else, sooner or later they disagree.
Instead, WESTPOINT holds the canonical data. TRSI.org asks for the public representation and renders it.
The website handles presentation, URLs, caching, SEO and navigation. It does not try to become a second archive.
Preservation means more than keeping ZIP files
A traditional scene archive can be simple.
You have a file, a title, perhaps a group and a date. For us, that quickly stopped being enough.
A production can have screenshots, multiple assets, party information, competition placement, external references and credits. Music has artists and formats. Graphics have artists, platforms and rendering requirements. Members have handles, aliases, status and relationships to decades of work. Articles and Party Postcards connect back to all of these things.
Once those relationships exist, the archive stops being a pile of files.
It starts becoming a model of the group's history.
WESTPOINT therefore uses stable internal identities.
A member is not merely the string Spotter. A member has an internal identity. Music, graphics, articles and Party Postcards do too.
That allows TRSI.org to show the same relationships from different directions.
A production page can answer: Who worked on this?
A member page can answer: What did this person work on?
Figure 5: Credits are structured relationships rather than decorative text attached to a release.
Figure 6: The same archive relationships can be viewed from the other direction, showing a member's productions, graphics, music and other contributions.
Original formats in a modern browser
Music is where the browser starts fighting back.
If the archive contained only MP3 files, playback would be easy.
It does not.
Scene music means tracker modules, SID music, historical MED variants, AHX and several other formats that browsers do not understand natively.
WESTPOINT therefore uses different playback engines depending on the original format.
The visitor does not have to care.
They press Play.
WESTPOINT identifies the file and selects the appropriate engine.
Figure 7: A ProTracker/SoundTracker MOD is routed through OpenMPT rather than being converted to a normal audio file.
We could convert everything to MP3 and make life easier.
But then the archive would no longer be experiencing the original object.
The MOD should remain a MOD.
The SID should remain a SID.
The same philosophy applies to graphics.
WESTPOINT can decode and present a growing range of legacy formats, including textmode material, ANSI with SAUCE information and several machine-specific raster formats.
The original file remains the archived object. The preview is only the presentation layer.
That closes the circle back to the first WESTPOINT screen from Part 1.
The ANSI artwork is not just a design that looks old. It is the archive doing exactly what it was built to do: reading an old format instead of flattening it into a modern image.
Sometimes a screenshot is not enough
Some releases are meant to run.
Supported C64 PRG and D64 material, also Amiga Releases can therefore be opened directly inside the browser using a locally hosted C64 runtime. So, before you spend too much time wondering how to view these kinds of things:
[F] File Areas -> [1] Amiga -> Select Demo/Intro -> [P] Preview primary
Whenever you see a [P] Preview, no matter where, press P or use the cursor keys to navigate to it. This applies to music, graphics, or demos.
Figure 8+9: A C64 PRG and an Amiga release running interactively inside WESTPOINT. The archived program remains the original file. Emulation is simply another presentation method.
The goal is simple: Preserve the original. Make the original accessible.
Those are related goals, but they are not the same thing.
A radio station made from the archive
WESTPOINT Radio started with a simple idea: Take the music archive and let it play.
Then came Pause, Next, Stop, different scopes, a spectrum display, playback-history logic, audio focus and volume control.
Eventually the Radio became part of TRSI.org.
Figure 10: The Radio uses WESTPOINT's archive and playback engines while TRSI.org provides the public presentation.
The current integration does not require an iframe.
Normally, following a link destroys the current HTML document and therefore the player. Turning the whole site into a large Single Page Application would have solved that, but it would also have introduced complexity we did not want.
Instead, TRSI.org uses lighter progressive navigation.
Once the Radio is running, eligible internal navigation can replace the main page content while the same player instance remains alive.
A visitor can browse Members, Productions, Music, News or Party Postcards and keep listening.
When an individual music track starts, the Radio yields through the shared audio-focus system. When that track finishes, the Radio can resume.
The Ambient Slideshow is treated differently because it has its own integrated Radio experience.
But we can also produce special radio shows to highlight the work of other musicians in the scene, as we did recently with Dalezy.
Dalezy - Westpoint Special Radio
Here, the data is stored in a protected area that is not included in the archive.
If you'd like to present your music in a different way, feel free to contact us. We'd also love to have newbies or people who want to show off what they can do with SIDs, mods, or streamed music. We're offering you a platform.
Ambient: turning the archive into something you can watch
An archive does not always need to be searched. Sometimes it can simply be experienced.
The Ambient Slideshow takes suitable graphics from WESTPOINT and turns them into an evolving gallery, accompanied by music from the archive.
Figure 11: The Ambient view combines the graphics archive and WESTPOINT Radio into a passive gallery experience.
The same archive can therefore be searched item by item or experienced as something closer to a visual installation.
WESTPOINT provides the material.
TRSI.org decides how to experience it.
A public API between archive and website
TRSI.org does not read WESTPOINT's internal filesystem.
It talks to a dedicated public API.
That separation is deliberate.
Internal BBS operations and public website functions are different security surfaces. The public API only exposes material that has passed the relevant publication rules.
Figure 12: The public API provides structured, curated data to TRSI.org without exposing WESTPOINT's internal storage model.
Media delivery follows the same principle.
Public pages do not need to know where a file physically lives. Generated media URLs can be signed and time-limited. Internal paths remain internal.
The website handles human-readable URLs, presentation, search, SEO and caching, but the archive remains the source.
Party Postcards: a small idea that demonstrates the whole system
Some features begin with a technical requirement. Party Postcards did not.
The original idea came from Sachy:
Why not present old and new party photographs as actual postcards?
Everybody liked the idea immediately.
The obvious implementation would have been a photo gallery.
Upload a picture. Write a caption. Done.
But by that point WESTPOINT had already taught us to think differently.
What if the photograph itself became part of the archive?
A Party Postcard therefore contains structured event information, date, location, photographer, source, caption, a longer memory or story, tags and links to TRSI members visible in the photograph.
Figure 13: Party photographs are treated as archive objects with event information, dates, people, provenance and publication controls.
Historical photographs also have a problem that databases tend to dislike.
People do not always remember everything.
Sometimes we know the exact date. Sometimes only the year. Sometimes we know the event but not which day the picture was taken.
The data model therefore allows different levels of date precision instead of inventing certainty that does not exist.
Before a postcard becomes public, its provenance or rights have to be confirmed internally.
Then the public API exposes only the sanitised version.
TRSI.org turns that record back into a postcard.
Figure 14: The public archive becomes a playful postcard wall rather than a conventional database gallery.
Figure 15: The detail view combines the preserved photograph with archive metadata, memories and links to the members shown in it.
Party Postcards demonstrate the complete architecture in one feature.
An idea starts with a visual concept.
WESTPOINT turns it into structured, preservable data.
Publication rules decide what may leave the archive.
The API exposes the public subset.
TRSI.org turns it into an experience.
Stored does not automatically mean published
Preservation also means knowing what not to publish.
Articles using commercial stock photography may have licences, invoices or permissions connected with them.
WESTPOINT can keep those documents with the article, but they are explicitly excluded from the public website, previews, public API and Public Archive.
That reflects a broader rule: Stored does not automatically mean published.
The archive needs to know more than the public needs to see.
The Public Archive
Public history should not depend entirely on the currently running application.
WESTPOINT can therefore create a public archive representation of published material.
This is not simply a ZIP copy of the server directories. It is a deliberate public projection.
Draft material is excluded.
Private rights information is excluded.
Internal recovery data is excluded.
Only information intended for public preservation is exported.
That export can itself be backed up and preserved externally.
The live website is therefore not the only possible way to access the history.
Why there is no traditional database
WESTPOINT does not depend on a conventional SQL database.
Persistent data is mainly stored in structured files and content directories.
That has trade-offs, but it also has advantages for this project.
The archive is transparent and portable. It can be backed up without a separate database dump. A recovery copy remains understandable even outside a running database server.
It also fits the hosting environment extremely well.
WESTPOINT runs on ordinary shared hosting.
There is no permanently running Node.js service, no Docker cluster, no Redis and no database daemon that has to be restored separately.
PHP receives a request, does its work and exits.
Architecture should solve the problem you actually have, not the one a framework assumes you have.
For WESTPOINT, portability, survivability and comprehensibility matter more than architectural fashion.
Building for whoever comes next
Documentation became unusually important for one reason:
What happens if the person who currently understands everything suddenly cannot maintain it anymore?
That is not an abstract question for us.
So stable releases matter.
Predictable directories matter.
Persistent content has to be clearly separated from replaceable code.
Upgrade packages need to state which directories must never be overwritten.
APIs and dependencies need to be documented.
The complete source code is kept in Git and is available to TRSI members.
Another developer should be able to receive WESTPOINT and TRSI.org, read the documentation and understand both what the systems do and why certain decisions were made.
The goal is not merely that someone else could copy the files to another server.
The goal is that someone else could continue the project.
That may be one of the least visible features we built.
It may also be one of the most important.
The strange point where a website became an archive system
There was no meeting where somebody announced:
"We are now building a digital preservation platform."
It happened gradually.
- A member list needed stable identities.
- Music needed several playback engines.
- Graphics needed decoders.
- C64 productions needed an interactive preview.
- Articles needed a proper editor.
- The Extended Editor showed that WESTPOINT could become a backend.
- The backend needed a public API.
- The API needed controlled media delivery.
- The public archive needed a reliable export.
- Party photographs became structured historical objects.
- The Radio needed to survive navigation.
At some point, calling the result simply a website stopped describing it very well.
TRSI.org is the visible part.
WESTPOINT is the machinery underneath it.
What comes next
There are still ideas. A TRSI Timeline could connect members, productions, parties, articles and historical events.
A memorial area could preserve information and memories about members who are no longer with us.
New archive sources may reveal material we currently do not have. New browser capabilities may allow more original formats to be experienced directly.
But an archive cannot remain a permanent experiment that never reaches a stable state.
So development moves in cycles.
- Build something.
- Test it.
- Correct it.
- Document it.
- Freeze a stable version.
- push it to git
- Then continue.
That discipline is part of preservation too.
Closing the loop
There is something appropriate about all of this ending up behind a BBS. The demoscene has never only been about the final executable.
- There are people behind it.
- Music.
- Graphics.
- Code.
- Parties.
- Arguments.
- Friendships.
- Handles that nobody has used for twenty years.
- Files copied from machine to machine until nobody remembers where the first copy came from.
- Photographs that suddenly become historically interesting simply because enough time has passed.
TRSI has been connected to BBS culture for decades. We ran boards, lived through that era, built BBS software and tools, and used those systems as part of the infrastructure that connected the scene.
WESTPOINT continues that tradition in a different form.
- A real ANSI screen can sit next to a modern public API.
- A ProTracker module can remain a module and still play in the browser.
- A C64 program can remain a PRG and still run interactively.
- A thirty-year-old handle can become a stable identity connecting releases, photographs and memories.
- TRSI.org presents that material in a modern browser.
- WESTPOINT keeps the relationships underneath it.
And perhaps that is the most important part of the whole project: The goal was never merely to put old things online.
The goal is to keep them connected, understandable and alive.
So that one day, when all of us really are Sleeping Gods, the story does not disappear with us!
astaroth/trsi
------------------------------------------------------------------------
If you'd like to learn more about the technical background or discuss it, please let us know. We'd be happy to discuss it with you in sessions or even give you a peek under the hood.
