v0.1.9

Changed

• Visual Studio solution versioned with the repository (Kubuno.Forum.slnx, generated by vskubuno, the naming of
  every Kubuno repository): the server is the project Kubuno.Forum.Server, the frontend Kubuno.Forum.Web, in
  the solution folders Server, Libraries and Frontend, with the shared launch profile "Forum (Kubuno Core + browser)".
  The crate and npm names do not change.

• The forum now runs on PostgreSQL, MySQL/MariaDB or SQLite. The engine is an
  administrator choice read at run time ([database] engine), and a single
  binary connects to whichever is named — no rebuild. The module was moved off
  its PostgreSQL-only stack onto the shared kubuno-db foundation: one enum pool
  in place of PgPool, engine-agnostic bind parameters, and the fragments the
  three engines spell differently (ON CONFLICT/ON DUPLICATE KEY, RETURNING,
  = ANY, casts, upserts) produced by the dialect layer. Every insert now mints
  its primary key in the process (no RETURNING, which MySQL lacks), reads
  integer results at a portable width, and keeps all SQL schema-qualified with
  strictly increasing, never-reused placeholders.

• Full-text search rebuilt to work on every engine. Post bodies and topic
  titles are reduced to Snowball French stems and deaccented at write time
  (stored in posts.body_norm / topics.title_norm), and a query is put through
  the same reduction and matched with a portable LIKE, ranked title over body —
  replacing the PostgreSQL-only tsvector / websearch_to_tsquery /
  ts_rank_cd / ts_headline pipeline. Search results keep their highlighted
  snippet. Typo tolerance that relied on pg_trgm is dropped; inflected and
  accented queries still match.

Security

• Attachments and images from Drive in posts no longer rely on the access-token cookie the web client
  used to keep readable by page scripts; they use short-lived signed tickets. Attachment links now
  download the file. Requires a Kubuno core that issues signed tickets (POST /api/v1/auth/tickets) and @kubuno/sdk with the signed-URL helpers.

• Security fixes from the shared database layer (kubuno-db 0.9.0). The
  database password can no longer appear in a log through the debug output of
  the database settings.

• Duplicate-report protection preserved on every engine. The "one open
  report per member per post" guard, previously a PostgreSQL partial unique
  index (which MySQL cannot express), is now enforced in the service before the
  insert, so re-reporting a post you have already flagged is still refused until
  the first report is handled.

• Database driver updated past an unfixable advisory. The previous line
  pulled in an RSA implementation vulnerable to a timing side-channel
  (RUSTSEC-2023-0071) for which no fix will ever exist. The new line does not
  depend on it at all, and it refuses any SQL string built at run time unless it
  has been vouched for. Most queries are compile-time constants; the few
  assembled at run time (dynamic list filters, the per-engine dialect fragments)
  go through the shared kubuno-db builder, which vouches for the text and
  guarantees placeholders are used once each in ascending order.

• Input validation library updated. The version in use carried
  RUSTSEC-2024-0421 through its domain-name parser, which accepted Punycode
  labels that decode to plain ASCII — a mismatch an attacker can use to make two
  different names look like one.

Fixed

• Oracle MySQL installs use the migrations written for them. The module now runs its mysql-oracle migration set when the database is Oracle MySQL, instead of the generic MySQL set.

• The forum installs on Oracle MySQL 8. Its schema migration gave a
  TEXT column a literal default, which MariaDB accepts but MySQL 8 refuses
  (error 1101), so the module could not start on MySQL. On Oracle MySQL a variant
  of that migration (migrations/mysql-oracle/) now declares the same default as
  an expression; MariaDB keeps running the original file. Both are recorded under
  the original checksum, so a database that already applied it is unaffected.

• Database migrations keep the same checksum on every OS. The repository now
  pins line endings to LF (.gitattributes), so a checkout on Windows no longer
  turns SQL migrations, scripts, manifests or sources into CRLF. A database
  migrated by a Linux build is therefore no longer refused by a Windows or macOS
  build of the same version because its migration checksums differ.

v0.1.8

Security

• HTTP/2 layer updated to a patched release. h2 moves from 0.4.15 to
  0.4.19, closing a denial of service through unbounded empty DATA frames
  (RUSTSEC-2026-0258).
• Error library updated to a patched release. anyhow moves from 1.0.102
  to 1.0.104, closing an unsoundness in Error::downcast_mut()
  (RUSTSEC-2026-0190).
• TLS library updated to a patched release. The pinned rustls carried
  RUSTSEC-2026-0285 (medium). Every outbound HTTPS connection goes through it.

v0.1.7

Added

• Watching a topic or forum now actually notifies you. Subscribing already
  worked, but the subscriptions did nothing; a reply to a watched topic, or a new
  topic in a watched forum, now sends the watcher a notification — while never
  notifying anyone who cannot see the forum.
• Moderation keeps the people involved informed. Reporting a post now alerts
  the forum's moderators; resolving a report tells the reporter; approving or
  rejecting a held message, and warning or banning a member, now notify the
  member concerned (a warning carries its reason; a ban does not disclose the
  moderators' private note).
• @mention autocomplete in the reply box. Typing "@" opens a keyboard-
  navigable search of members; the people you pick are notified of your reply
  (subject, as always, to being able to see the forum).
• Notifications from a busy topic are grouped. Several replies (or reactions)
  to the same topic now fold into a single "X and 4 others replied" entry instead
  of a separate notification each, and native (mobile) pushes now carry a title
  and a short description instead of arriving blank.
• Missed notifications are caught up on your next visit. The forum's own bell
  is gone — everything goes through the core's shared header bell — but until now
  a notification created while you were offline only reached you through the
  real-time bridge, so it was silently lost if you weren't connected at the time.
  Opening the forum now announces any notification you haven't read yet into the
  shared bell, using the same identity the real-time bridge uses so nothing is
  ever announced twice.
• Syntax highlighting for code blocks. Fenced code blocks (rust, js …)
  are now colourised by language; inline code and everything else renders exactly
  as before.
• Predefined report reasons. Reporting a post now offers a set of reasons an
  administrator curates (Spam, Inappropriate, Off-topic, Harassment…) as one-tap
  chips, plus an optional comment, instead of only a free-text box.
• Quoting a post attributes its author. The quote action now prefixes the
  quoted text with "@name wrote:" instead of a bare quote.
• Shareable permalinks for messages. Each message has its own link (a "Copy
  link" action in its menu); opening one scrolls to the message and briefly
  highlights it.
• A trash for topics. A deleted topic now lands in a moderation "Trash" tab
  where a moderator can restore it; an administrator can also delete it for good.
• Write/Preview in the composer. The message editor now has a preview tab
  that renders your Markdown exactly as it will appear.
• Post edit history. A message's author and the moderators can now open its
  edit history to read every previous version (new forum.post_revisions).
• Advanced search filters. Search gains an advanced panel — by author, by
  forum, title/body scope, sort and time period — always kept in sync with the
  plain search bar.
• Prune inactive topics. A forum admin can move to the trash every topic in a
  forum with no activity for N days (with a preview count first); pinned, solved
  and poll topics are spared.
• Bulk topic moderation. A moderator can select several topics from a forum
  and lock, unlock or delete them in one action; rights are re-checked per topic.
• "Who's online" and a leaderboard. New community pages — a detailed presence
  list and a top-contributors ranking — linked from the sidebar; a presence
  location never reveals a topic in a forum you cannot see.
• Word censor. An administrator can maintain a list of censored words that are
  substituted in displayed messages; the replacement is applied on the server, so
  it cannot be bypassed from the browser.
• Per-group forum permissions. In a forum's permissions window, an
  administrator can now grant view/post/reply/attach access to specific instance
  groups — opening an otherwise-restricted forum to just those groups. Group
  grants are purely additive on top of the role-based rules: they can only widen
  access, never remove it.
• IP and email bans. In addition to banning an account, a moderator can now
  ban an IP address or an email address (exact match) from the Bans tab. Bans are
  enforced on every authenticated request — a banned visitor is locked out, not
  just prevented from posting — and an administrator is never locked out by one.
• Moderation team page. A new "Moderation team" page (/forum/team) lists the
  moderators of each forum you can see, grouped by forum.
• Topic view polish. Hover a post's reactions to see who reacted (resolved on
  demand), jump straight to the first unread post, hop to any forum from a
  jumpbox in the header, and print a clean copy of the thread.
• Editable FAQ. An administrator curates a list of question/answer pairs
  (Markdown answers) from the console; every member reads them on a dedicated
  /forum/faq page.
• Personal RSS/Atom feeds. Mint a private feed link from the new "RSS feeds"
  page (/forum/feeds) and follow recent topics in any feed reader; a feed shows
  exactly what you can see, and revoking a link disables it at once.
• Custom profile fields. An administrator can define profile fields (short
  text, long text, yes/no, link, date, or drop-down); every member fills in their
  own answers, shown on their profile page.
• Ignore list ("foes"). Ignore a member from the topic view or their profile
  menu; their posts then fold under a dismissible banner you can expand at will,
  and a new "Ignored members" page (/forum/ignored) lets you review and lift
  each one. The list is yours alone and never affects what others see.
• Private messages. Start a one-to-one or small-group conversation (up to ten
  recipients), reply, mark a thread as read, remove it from your own inbox, and
  block a member from messaging you. An inbox lives at /forum/pm with a
  conversation view, a compose window, and an unread badge in the sidebar. The
  threads are backed by dedicated tables, kept entirely separate from the boards
  and never indexed by search. A new private message notifies the other
  participants through the shared notification bell — never the message content,
  only who wrote to you.

Security

• RSS/Atom feeds never leak restricted content. A feed is reachable only
  through an unguessable, revocable token in its URL — there is no anonymous,
  token-less feed — and it lists only the topics its owner may see, evaluated as
  an ordinary member (never with administrator visibility). Titles and names are
  XML-escaped.
• Custom profile field values can't smuggle markup or scripts. URLs are
  restricted to http(s) and validated on the server; every field value is
  rendered as plain, escaped text — never Markdown or HTML.
• Search no longer reveals restricted forums. A search could return the
  title and an excerpt of any post, including from forums a member is not
  allowed to read. Results are now limited to the forums the searcher may see,
  the same rule the topic lists already follow, and never include messages that
  were removed or are still awaiting approval.
• Removed and pending messages are no longer readable by direct link. A
  message hidden by a moderator, or one still waiting for approval, could be
  opened through a link to its id even though it was gone from the topic. It is
  now visible only to its author and to moderators, and such a message can no
  longer be edited back into place.
• Voting in a poll now obeys the topic's rules. A poll vote did not check
  anything: anyone could vote in a poll belonging to a restricted, locked or
  unapproved topic. A vote now requires the same access as posting in that
  topic.
• Restricted forums and their categories are hidden from the lists. The
  forum and category listings returned every forum regardless of its view
  permission; a category made only of restricted forums is likewise no longer
  listed to members who cannot see its contents.
• Sturdier against abusive requests. Request bodies are now capped in size,
  and the lists a single request can carry — mentions, tags, poll options and
  votes — are bounded, so one call can no longer be turned into thousands of
  database writes. Poll options are validated (2–20 per poll, length-limited)
  instead of surfacing a raw database error.
• Tighter checks on subscribing and on the moderator roster. Watching a
  topic or forum, marking it read, and reading a forum's moderator list now all
  require permission to see that forum.
• Moderators only see their own forums' reports and history. The report
  queue and the moderation log returned every forum's entries to any moderator;
  they are now limited to the forums a moderator actually manages (plus, for the
  log, that moderator's own actions), while administrators still see everything.
• Moving, splitting and merging topics now check the other forum too. These
  actions only verified the forum a topic came from, letting a moderator push a
  topic into — or pull one out of — a forum they do not manage. Both sides are
  now checked, and the destination forum must actually exist.
• A fuller moderation audit trail. Locking, unlocking, moving, splitting,
  merging and deleting a topic, marking a solution and resolving a report are now
  all recorded in the moderation log, which previously only captured warnings,
  bans and post approvals.
• A post can no longer be reported twice. Reporting the same message again
  while a report is still open is now a no-op instead of piling duplicate
  entries onto the moderators' queue. (The guard was keyed on a report status
  the database never actually used, so it had been inert; it now matches the
  real open state.)
• Mentions cannot reveal a hidden topic. Mentioning someone in a restricted
  forum no longer notifies — or discloses the topic's existence to — a mem...

v0.1.6

Changed

• Theme tokens: two colours for navigation labels (--color-text-nav,
  --color-text-nav-active). Every module carries the same token sheet, so the
  values must match across them — whichever bundle loads last would otherwise
  win. No visible change inside this module.

Changed

• Default application background token aligned with the core (--body-bg #f8fafd). Only
  visible when the module runs standalone: inside the shell the active theme sets it.

v0.1.5

kubuno-forum v0.1.5