Talkyard mixes a forum, a chat and embedded comments in one AGPL codebase

Four content types in one application, ranked by votes

Talkyard's pitch is a hybrid. The repository description calls it a community discussion platform that brings together the main features from StackOverflow, Slack, Discourse, Reddit and Disqus blog comments, and the README headline shortens that to forum software with chat and anonymous comments.

The feature list in the README is the real specification. Good comments rise to the top, and the stated goal is to find the interesting stuff, also in big discussions, which is a ranking feature rather than a chronological feed. You can upvote ideas and sort by votes. There are question and answers topics where you discuss and then select an answer. There are chat channels, and the README describes those as pretty basic features, which is an unusually candid way to signal that chat is the weakest part. And there are blog comments, described as listening to your readers.

Two details stand out as more than feature list entries. The first is tags with values, where you create your own tags and give them values, then list and sort by value; the example given is a `priority` tag queried as `tags:priority:desc>2 is:open`. That is a typed metadata system rather than flat labels, and it is the kind of thing that makes a forum usable for real work queues.

The second is anonymous comments, offered for cases like students posting embarrassing questions or for anonymous feedback. That is a moderation and identity decision, not a cosmetic one, and it is worth deciding early whether you want it enabled.

Self hosting is a second repository, not this one

The README is explicit about where production installation lives, and it is not here.

The `docker-compose.yml` in this repository says so in its own header comment: it is for development and testing, and for production installations use another repository, `talkyard-prod-one`. That repository is also present here as a Git submodule under `modules/ed-prod-one-test/`, which is what the `.gitmodules` file is for.

The compose file itself shows what the stack is. It defines volumes for web generated files, core dumps, public files, private files, Redis data, Postgres data, and two ElasticSearch volumes for data and logs. It wires secrets from files under `tests/secrets/`, including a Postgres password and a backup password. So the runtime dependency set is Postgres, Redis and ElasticSearch, not just a database.

The network design is the part worth copying. Four networks are declared: a frontend public network connecting Nginx to the internet, an internal frontend network so Nginx can reach the app server, a backend network for the app server and databases, and an egress proxy network. The comments explain the intent: if someone breaks into Nginx they still cannot reach Postgres or ElasticSearch directly, and the internal networks cannot reach the internet, while the egress proxy and subnet exist to prevent SSRF. The same comment is careful to say the setup reduces but does not eliminate the risk, since an attacker on Nginx could inspect traffic and steal an active session.

Every Docker object is prefixed with `tyd1_`, taken from the Compose project name in `.env`.

For evaluation without installing anything, the README points at a public demo at insightful.demo.talkyard.io and a discussion forum at forum.talkyard.io.

Scala services, a React client pinned to 2018 era versions

The server side is Scala. The repository root has `build.sbt` and `lock.sbt` for the build, `project/` for the sbt project definition, and a `modules/` directory holding the code, including `modules/ed-core/src` for the core application and `modules/ty-dao-rdb/src` for the relational data access layer. There is also an `appsv/` directory, a `relchans/` directory for the pubsub and chat channels, and `conf/` for configuration.

The client side tells a different story about age. `package.json` is for a package called `talkyard-client` at version 0.0.1, and its dependencies pin React at `^16.13.1` with `@types/react` at `=16.8.2`, `react-bootstrap` at `^0.32.3` and `react-router-dom` at `^5.2.0`. `create-react-class` is in the list, which belongs to React 16. The engine requirement is `node >= 12.0.0`. Asset builds go through gulp, and `gulpfile.js` is at the root.

That dependency set dates the front end to a specific era, and for a self hosted product it has a cost: you are building against a React major that the rest of the ecosystem has moved past, and any security patch you apply is a patch against those pinned versions.

Two details in the repository are worth noting. The `scripts` block in `package.json` contains one entry that is a message rather than a command: "No! Please don't write scripts in json. Instead: s/tyd.ts." The client build is driven from a TypeScript script instead. And the top level `Makefile` is where the development commands actually live, wrapped in `sudo docker compose`, with a long comment about a failure where a make target named `s/d-gulp` could not be found unless the command was chained with something else.

Where the README tells you to look instead

Several pointers in the README are worth taking at face value, because they tell you where the project is candid about its own gaps.

The documentation link goes to docs.talkyard.io and is annotated as incomplete, in the same sentence as the development link to `docs/developing-talkyard.md`. The comparison link goes to business.talkyard.io/compare/ rather than a table in the README, which is where the project puts its feature comparisons with StackOverflow for Teams, Discourse, Slack, Facebook Groups and Disqus.

The README also carries commented out drafts. There is an HTML comment holding an old one line GitHub description, several candidate marketing taglines, and a project size note giving 140000 lines of code and comments plus about 60000 lines of test code, with server side complexity 5538 and client side 8478, measured in May 2021 with the `boyter/scc` tool. That number is four years old and belongs to a different branch, so treat it as evidence that the project has long considered itself comprehensible by one person, not as a current figure.

The named use cases in the same comments are: internal team knowledge that people want to find months and years later, customer support, and schools and students. The suggested pattern is to keep Slack or Mattermost for day to day teamwork and use Talkyard for the discussions worth keeping in a readable format, which is a defensible split for anyone evaluating it.

AGPL, version naming that does not sort, and an AGPL client package

The licence is AGPL-3.0, recorded in `LICENSE.txt` and stated as AGPL-3.0-or-later in the client `package.json`. That matters more here than for a typical library, because Talkyard is server software you run yourself and often expose on the internet. Anyone offering it over a network is within the scope the AGPL was written for, so if you host a modified version as a service, read the licence text and check it with your own counsel. Embedding Talkyard's comments widget in a commercial product is a different question from hosting it, and the README does not resolve it.

The release naming is unusual. Tags look like `tyse-v1.2026.003-f220a7d9f-regular`, with a `tyse` prefix, a calendar version, a commit hash and a `regular` or `dev` channel suffix. Three appear in the visible window: v1.2026.003 regular on 2026-05-26, v1.2026.002 dev on 2026-05-13, and v0.2025.015 regular on 2026-05-10. A `dev` tag and a `regular` tag coexist, and the calendar numbering means lexical sort and chronological sort agree here but will not tell you which line is the stable one to deploy.

The repository is not archived, and the last push was on 2026-07-13, about three months before this writing. The rest of the root shows the shape of the working tree: `to-talkyard/`, the conversion tooling from the earlier EffectiveDiscussions name; `translations/`; `vendors/`; `d/`; `wip/`; `old/`; `nix/`, `flake.nix` and `shell.nix` for Nix based environments; `volumes/`; `decisions.adoc` for architecture decision records; and `CONTRIBUTING.adoc`.

Before committing, the practical checks are the demo site, the developing guide, and the AGPL terms. The comparison page and the README are marketing; the compose file, the network design and the license are the facts.

Editorial conclusion

Adopt Talkyard if you want one self hosted application to hold question and answer topics, ranked idea discussions, chat and comments embedded in a blog, and you can operate Postgres, Redis, ElasticSearch and an Nginx front end. Do not adopt it if you need a mature single purpose forum or a proven chat client, since the README describes the chat as pretty basic features and marks the documentation as incomplete. Verify first against a live demo at insightful.demo.talkyard.io, read docs/developing-talkyard.md, and check the AGPL-3.0 terms with your own counsel before you embed it in a product.

Frequently asked questions

Official sources

1. debiki/talkyard on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases