Squalk Launches Old-School Forum Engine on Nostr

An open forum platform called “Squalk” that rebuilds classic forums on Nostr has been released. It adopts a structure in which users hold key pairs and posts are kept as signed events on multiple relays. According to a report by daniele on Lobsters about github.com, the motivation for development lies in a return to classic forums.

I miss classic forums: slow, asynchronous threads that stay readable and searchable for years, instead of knowledge dissolving into chat scrollback.

In contrast to a present where knowledge is buried in real-time chat flows, the aim is to keep asynchronous threaded discussions readable and writable for the long term. The forum itself has no dedicated store and operates as a presentation layer for data held by relays. The material was published on 2026-09-21 and is drawing attention among engineers.

Recreating Classic Forums on Nostr

Squalk is a forum platform built on Nostr. It implements NIP-29 and NIP-7D, handling group management and threaded discussions with open protocols. The unit corresponding to a room is a group as defined by NIP-29, and threaded discussions are expressed as NIP-7D events.

Identity management is based on key pairs. Posts are signed with private keys and distributed to relays as events. Users are not tied to a specific operator’s store and can move data between compatible relays.

The developer cites Pyramid as the recommended setup. Pyramid combines a personal relay supporting NIP-29 with a Blossom server for storing images and other files. Squalk itself handles display and interaction, while storage and distribution are delegated to external compatible infrastructure, a separation that defines its design.

The trend of individuals operating their own infrastructure overlaps with the self-reliant setup described in Vulkan Video Encoding Revived on Intel Alchemist GPUs. A growing group of engineers is choosing operations that do not depend on specific providers.

A Forum That Owns Nothing: Design Philosophy

Squalk’s design can be summarized as “a forum is a view of data.” Operators do not hold post bodies in their own stores. It reads signed events held by relays and formats them as rooms and threaded discussions.

This separation improves portability. Even if relays are changed or multiplied, post attribution is preserved as long as the key pairs and signatures remain the same. Even if operators change or the infrastructure stops, the data itself can still be referenced through other routes.

Availability, however, depends on external infrastructure. If maintenance of a personal relay or operation of a Blossom server stalls, gaps appear in the display. Decentralization should be understood not as the disappearance of management, but as a mechanism that returns where management resides to operators.

As a case where infrastructure independence was debated through a large cross-language port, there is Bun Ports 530,000 Lines from Zig to Rust with Claude Fable 5. The idea of building a whole from combinations of open components is shared with this forum design.

Configuration for Both Single and Multi-Board

Operation

Squalk has two modes of operation: simple and full. Simple is the mode for publishing a single board. Full is the mode for handling multiple boards in the same installation.

Administrators can migrate from simple to full during operation. It is possible to start with a small group and expand step by step by adding rooms as needed. Each room has a chat panel in the right sidebar, allowing short exchanges and long discussions to be used separately.

This two-layer structure is close to the classic combination of a forum and a chat panel. Discussions worth keeping on record accumulate in threaded discussions. Coordination and casual talk are handled in the right sidebar, preserving the readability of the main content.

As portable and desktop environments diversify, viewing device options are also expanding, as seen in Juno Tab 4 Unveils Two Linux Tablets with Core i3 and Core Ultra. A forum dedicated to the presentation layer is well suited for device-independent access.

Configuration Handled Entirely with

Environment Variables

All Squalk settings are done with environment variables starting with PUBLIC_. Users fill in a copied template with values read on the browser side. Thanks to SvelteKit’s mechanism, the file loaded switches between development and build time.

The required field is PUBLIC_RELAY_URL. It specifies the WebSocket address of a relay supporting NIP-29. In simple mode, PUBLIC_GROUP_ID is also required, indicating the group identifier for the single board.

The optional PUBLIC_MODE field is available. The default is simple, and specifying full enables multi-room operation. PUBLIC_TITLE is the display name in the top bar, and falls back to the group name when left blank.

PUBLIC_JOINCODE is a flag for showing an invite-code field when a join request is rejected. It is intended for use with relays that restrict entry by code. PUBLIC_LABELS are categories assigned at posting time, listing bug, feature, question and others separated by commas.

For appearance, PUBLIC_ACCENT_COLOR and PUBLIC_SECONDARY_COLOR are available. They override the primary and secondary colors, with hover shades derived automatically. Because a leading # is interpreted as a comment, values must be enclosed in quotes.

Supporting Features for Search and Rendering

Display of the search box is controlled by PUBLIC_SEARCH. Enabling it requires a relay supporting NIP-50 search. It is a feature directly tied to the classic forum goal of reusing long-term accumulations.

Storage of images and other files is controlled by PUBLIC_BLOSSOM_URL. It specifies the address of a Blossom server, and storage is disabled when unset. By separating the storage locations for post bodies and attachments, it avoids concentrating load on relays.

For rendering, PUBLIC_SSR and related variables are provided. Enabling PUBLIC_SSR renders pages on the server side, yielding crawlable documents and accurate 404 responses. The build output becomes a Node-targeted artifact rather than a static bundle.

PUBLIC_SSR_WARM is a flag that requests server-side fetching and caching on each client-side navigation. The aim is to serve later reloads, shared links and crawler responses warm. It comes at the cost of one extra server-side query.

PUBLIC_SSR_CACHE_FRESH is the number of seconds a server-side snapshot is returned as-is, with a default of 300. PUBLIC_SSR_CACHE_STALE is the period during which an immediate response can be served while updating the snapshot in the background, with a default of 21600. The design passes the same values to edge caching mechanisms.

Differences from Centralized Forums and

Remaining Challenges

Centralized forums handle user registration, post storage and display as one unit. The operator’s store becomes the sole canonical copy, and migration and preservation depend on features provided by the operator. Squalk breaks apart registration, storage and display, replacing them with key pairs, signatures and compatible relays.

This decomposition improves censorship resistance and portability. Even if a particular presentation layer stops, the data can be reconstructed in another layer as long as it remains on relays. As long as users keep their key pairs, moving to another operation is easy.

Challenges lie in spam countermeasures and operational load. With open identity management, enforcement of bans and restrictions must be left to group management and relay-side rules. How finely NIP-29 group moderation features can handle adjustments requires verification in real operation.

Because data resides in distributed locations, designing against loss is also left to operators. Backups and replication of personal relays and redundancy of Blossom servers become essential. Greater freedom and greater operational responsibility are two sides of the same coin.

Editorial Opinion

In the short term, individuals equipped with NIP-29-compatible relays and Blossom are expected to proceed with trial installations. Moves by small groups of engineers to verify ease of setup will come first. We assess that accumulating operation reports will drive refinement of installation procedures.

In the longer term, accumulations of signed events will become a searchable knowledge base. The fact that portable records do not leave a group’s memory dependent on a specific operator carries weight. We assess that portability of writings will extend the life of the venue.

The remaining issue is where judicial enforcement and spam countermeasures reside. It is unverified how far key-pair-based identity management can handle trolls. What adjustments are needed to balance openness and order will require verification through operation.

References

• “Squalk: an old-school forum engine built on Nostr (NIP-29 groups, NIP-7D threads)”, by github.com by daniele — Lobsters, 2026-09-21T14:44:12.000Z (ARR)
• Source URL: https://github.com/dtonon/squalk