Run a podcast from your community, with a feed that Apple Podcasts, Spotify, Overcast and the rest will accept.

The feed is the point

A podcast is not a page with a play button on it — it is an RSS feed, and directories are unforgiving about the details. This gets them right: the iTunes namespace, owner verification, categories and artwork as attributes rather than text, episode and season numbers, episodic versus serial ordering, and enclosure lengths in real bytes so players can draw a scrub bar and seek properly.

Episode identifiers are permanent and opaque. That sounds like a detail until you rename an episode with a feed that derives them from the title, and every subscriber's app re-downloads your entire back catalogue and sends them a notification for each one.

Publish when you mean to

Give an episode a future date and it stays out of the feed until then. Nothing reaches a subscriber early, because “early” means already downloaded. Drafts are invisible, and so are their pages — not merely unlinked.

Every episode can have its own topic

This is the thing a podcast host cannot do for you. Choose a forum and publishing an episode opens a topic for it, so the conversation happens with your members instead of in someone else's comment section. Optional, per show, and off unless you ask.

On your site as well as in apps

A page per show and per episode, with the browser's own audio player — which means keyboard control, playback speed, media keys and screen-reader support you would otherwise have to build and maintain. The feed is advertised in the page head, so a podcast app pointed at your show page finds it by itself.

Details that save a support ticket

• Artwork is checked against Apple's size limits when you upload it, not months later when your show is rejected.
• Durations can be typed as 1:02:03, 62:03 or a number of seconds. Whichever your editor gave you is fine.
• The audio's real byte size and MIME type are read from the file rather than guessed.
• Deleting a show deletes its audio, so you are not paying to store episodes nothing references.

What you need

Somewhere to put the audio — your own uploads directory, or any file storage Invision Community is already configured to use, including S3-compatible object storage. No third-party podcast host, no monthly hosting fee, and the feed address is yours.

View File

Your community should not find out you were streaming afterwards. OnAir watches your channels and tells them the moment you go live.

Three ways to stream

• Twitch — live status, the current title, and the viewer count.
• YouTube — live status and title.
• Your own server — point it at a MediaMTX instance on your VPS or dedicated box. No platform account, no third party, and nobody else's advertising in front of your members.

Add as many channels as you like, in any mix. They can belong to you, to your staff, or to members you want to feature.

Announced where people will see it

Going live can post a topic in a forum you choose, with the player embedded in it, so the conversation happens on your site rather than somewhere else. Followers are notified the way they already expect to be.

A page, and a block

A page listing whatever is on air right now with the stream playing inline, and the channels that are not. Plus a sidebar block for anywhere on your site.

The block shows nothing at all when nobody is streaming, rather than sitting there permanently announcing that nobody is streaming.

Works with Live Topics, if you have it

If you also run Live Topics, going on air can open one automatically so people have somewhere to talk while they watch, and close it when the stream ends.

Built to be left alone

• A platform having a bad minute is treated as unknown, never as offline — so a blip cannot end a broadcast that is still running and announce it all over again.
• YouTube is checked less often than the others on purpose. Its API charges heavily for the question, and polling it like the rest would exhaust a day's allowance before lunch and then report everything as offline.
• Nothing OnAir does can hold up a page load, even on a community with no cron job set up.

What you need

For Twitch, a free developer application. For YouTube, an API key. For your own server, a MediaMTX install and its address — the setup guide covers it. Use one, two, or all three.

View File

Connect your community to your Discord server, and keep the two in step without anybody doing it by hand.

Roles that follow your groups

Map an Invision Community group to a Discord role and members get it automatically — when they connect their account, when you promote them, and on a regular sweep that catches anything missed while Discord was unreachable. Secondary groups count too.

It only ever touches roles you mapped. Colour roles, bot roles and anything a moderator handed out inside Discord are left exactly alone.

The reverse matters as much: ban somebody, flag them as a spammer or delete them, and the roles come off straight away. For a lot of communities the Discord server is the thing actually being revoked.

Names that match

Each member's Discord nickname is set to their display name here, so people are recognisable in both places and nobody can quietly impersonate a regular.

Announcements, from anywhere in the suite

Send new content to a Discord channel — forum topics, replies, gallery images, calendar events, downloads, blog entries, products, and every Pages database you have, including their comments and reviews. Around 25 content types on a normal install, and it finds new ones by itself rather than working from a list that goes stale.

Filter by category, by author, or by a minimum post count so brand-new accounts cannot broadcast to your server. Rich embeds, or plain messages if you prefer Discord's own link previews.

Content held for moderation is never announced — it goes out if and when it is approved, and not before.

Moderator reports in Discord

When a member reports something, your moderators can hear about it in a channel of their own, in a colour that stands out from ordinary announcements. Reports never travel through the normal rules, so they cannot end up somewhere public by accident.

Invites you control

Create invite links in the AdminCP, restrict them to chosen groups, and hand them out instead of an ordinary Discord invite. Optionally make people ask first: a request goes to your staff, who approve it once or for good, and the member is added to the server immediately.

Sign in with Discord

Switched on for you when setup finishes. Members connect once and everything else follows from that.

A widget for your sidebar

Discord's live widget in either theme, or any of its four banner badges, optionally with a join button pointing at one of your own invites.

Moving from another Discord app?

The expensive part of switching is not settings — those take minutes. It is the members who already connected their Discord account, because most will never do it a second time, and a community that loses those links loses the role syncing it was paying for.

So this reads your database, finds another integration's connected accounts by the shape of the data rather than by guessing at table names, shows you exactly how many it found, and imports them only when you say so. It works whichever application you are leaving.

Set up in two steps

Paste three values from your Discord application, then pick your server from a list. Nothing asks you to switch on Developer Mode or copy an eighteen-digit ID by hand.

The bot asks for permission to manage roles and nicknames, create invites and post messages. It never asks to be an administrator of your server.

When something goes wrong

Every call and every sync is logged with its reason, so “it stopped working” is a question you can actually answer. Secrets are never written to it.

View File

Invision Community already lets a member pick their language. What it cannot do is give you one to pick. A finished language pack is 22,363 strings, which is a translator's contract rather than a download so most communities run in English, and everyone who does not read English comfortably reads a little less, posts a little less, and eventually stops.

This translates both halves of that problem: the software itself, and what your members write in it.

The interface

Add a language in the AdminCP, press start, and the application works through all 22,363 strings with a language model. There is no pack to buy, no translator to commission and nothing to import. When it finishes, your members pick that language from the footer and the entire site is in it menus, buttons, error messages, notification text, everything.

You can stop and restart it at any point, and a half-finished language is a working site. Invision falls back to English for anything not yet translated, so there is never a broken state — just a site that is progressively more translated as the job runs.

It runs in the background through your existing task system. Nothing is translated twice, and adding a second or third language costs the same again not a multiple of a translator's fee.

Right-to-left languages

Arabic, Hebrew, Persian and Urdu are marked right-to-left and Invision mirrors its own layout for them. This sets that flag as part of creating the language, so an RTL community reads correctly rather than as left-to-right text in a left-to-right shell.

The posts

A translated interface does not help with a thread written in a language a member cannot read. Every post gets a translate control: one click and it is replaced, in place, in their own language, with a link back to the original.

Translations are stored the first time somebody asks, so the hundredth reader of that thread costs nothing. Editing a post invalidates its translation automatically, so nobody reads a translation of text that has changed.

It never damages what it translates

This is the part worth reading carefully, and it applies to both halves.

Interface strings are not prose. They carry substitution points like {1} and %s, HTML, and Invision's own plural syntax. A language model asked to translate them will occasionally return something that reads beautifully and is broken — a dropped placeholder throws an error on the page, and a flattened plural prints raw markup to your members.

So every translated string is checked before it is stored, and anything that fails the check stays in English. A missing translation is a missing translation; a broken placeholder is a support ticket. Plural forms are handled properly too — if the target language needs three or four forms where English has two, that is accepted rather than rejected.

Posts get the same treatment from the other direction: the model is never shown your markup at all. The post is taken apart, only the readable text is sent, and the translation is put back in the same places — so mentions keep linking to people, quotes keep their attribution and their link back, and code samples are never "corrected".

What it costs to run

You supply an API key for OpenAI or Anthropic, and you are billed by them for what you use. Translating a full interface is a few dollars of usage, once, per language. Posts are billed per post the first time each one is requested, with a length ceiling you control so a single enormous post cannot become a single enormous charge.

If you already run AI Assistant, this borrows its key and model so you keep one key and one bill.

What you need

• Invision Community 5.0+, self-hosted

• An API key for OpenAI or Anthropic — or AI Assistant already installed

• A second language added in the AdminCP. This creates it; it does not need to contain anything.

Being straight about the limits. Machine translation is very good now and it is still not a human translator. For reading a forum comfortably in your own language it is more than enough. For anything legal, contractual or safety-critical, commission a person. And a translated interface is only as good as the model you point it at a small fast model is fine for most languages and noticeably weaker for a few.

View File

Chat

A chat launcher on every page of your community. Members message each other privately, join public rooms, or start invite-only rooms of their own — without leaving the page they were reading.

It runs on your own server, over your own WebSocket. There is no third-party chat service in the loop, no per-message pricing, and no monthly bill that grows with your community.

What members get

• A launcher that is always there. Bottom corner of every page, with an unread count. Open it and their conversations and rooms are right there.
• Private messages. One to one, with history. Start one from the list of who is online.
• Public rooms. You create these in the AdminCP and choose which groups may enter.
• Private rooms. Invite-only, owned by whoever made them. Give a group permission to create their own, or keep it to staff.
• Typing indicators, so a conversation has a rhythm rather than a series of surprises.
• Images and files. Pictures appear inline; documents arrive as a labelled link.
• It works on a phone. The floating window becomes a full-screen panel rather than a postage stamp.

What you get

• Per-group permissions. Who can use chat at all, and who can create rooms. Off for every group until you say otherwise.
• Moderation. A "Can moderate chat" permission that reaches every room, including private ones. Delete anything, mute anyone.
• Room owners manage their own. Invite, remove and mute inside a room they created — and nothing outside it.
• Attachments live where your files live. S3, R2, Backblaze, FTP, or local disk. Whatever you have already configured.
• Core's ignore list is honoured, in both directions.
• Members browsing anonymously are never listed. They asked not to be seen.

Private by construction

Every channel a browser is allowed to listen on is decided by your server and cryptographically signed. The WebSocket gateway verifies that signature and knows nothing about rooms or permissions — so there is only ever one copy of the rules.

That applies to public rooms as much as private ones. It would be simpler to let the gateway wave through anything that looks like a room, but the same shortcut would wave through a private room to anybody who guessed a number. It does not.

Requirements

• Invision Community 5
• Realtime, installed and connected, with its gateway deployed

Audio and video

Voice and video calling is a separate add-on, sold on its own or bundled with this. Chat ships the extension points it needs, so installing the add-on makes a call button appear — and not installing it leaves no trace of a missing feature.

View File

Realtime Gateway

Free. The small WebSocket server that Realtime, Live Notifications and Chat all push through. If you own any of those, this is the piece that runs alongside your community and delivers to browsers.

It has always shipped inside the Realtime download. It now has a listing of its own, because a shared dependency deserves its own version number.

Why it is separate

Three applications depend on this one file, and it changes when any of them gains a new kind of channel. Buried inside another product's download, its version was whatever you happened to download last — and the only notice you got was a paragraph in somebody else's changelog.

That matters more than it sounds, because of how the gateway fails. An older gateway does not reject a channel it does not recognise. It drops it in silence: no error, no log line, nothing in the browser console. The socket stays open and looks perfectly healthy, and the feature simply never does anything.

With its own listing you can see at a glance whether yours is current, and you get told when it is not.

What it is

• About 250 lines of Node.js. No database, no state on disk, nothing to back up.
• Subscribes to your Valkey/Redis, fans messages out to the browsers that are entitled to them.
• Verifies every connection against an HMAC signature your community generates. It knows nothing about your permissions — your server decides who may hear what, and the gateway only checks the signature.
• Ships with a Dockerfile, a package.json and an .env.example. Docker or plain Node, whichever you prefer.
• If it goes down your community carries on normally; realtime features simply stop updating until it is back.

You need this if you run

• Realtime — live topics, presence, typing indicators
• Live Notifications — notifications the moment they are sent
• Chat — private messages and rooms

You do not need it for anything else, and it does nothing on its own.

Already have it?

The copy attached to the Realtime listing is the same file. Take whichever is newer — they are built together and released together. Going forward this listing is the one to watch.

View File

Live Notifications

Invision Community only checks for notifications when a member opens the notification menu. Anything that happens while they are reading a page — a reply to their topic, a mention, a quote — sits there unseen until they navigate or reload.

Live Notifications shows it at the time. A small toast slides in at the corner of the page, the bell count updates to match, and the member carries on reading.

What it does

• Notifications appear as they happen. No reload, no navigation, no waiting for the member to go looking.
• The bell stays honest. The counter in the header is updated from the same figure, so the badge and the menu can never disagree.
• It reads like a notification, not an advert. A photo, one line of text, and a dismiss button. It fades after a few seconds, and hovering it stops the clock so nobody loses a message they were mid-way through reading.
• Click to go straight there. The toast is a link to whatever caused it.
• Optional chime. Off by default. When switched on it is a short two-note tone generated in the browser — nothing to download, and nothing to host.

Instant with Realtime, still useful without it

Installed alongside Realtime, notifications arrive over the existing WebSocket the moment they are sent — typically inside a few seconds, with no polling at all.

Without Realtime the application still works. It falls back to a light periodic check on an interval you set, so members see notifications while they read rather than only when they go looking. The AdminCP tells you plainly which of the two is happening, rather than leaving you to guess.

Built to stay out of the way

• Nothing is loaded for guests. A signed-out visitor gets no extra script at all.
• A background tab is never polled. Members with twelve tabs open do not generate twelve times the traffic.
• Members on a live connection are never polled at all.
• Reduced-motion preferences are honoured, and the toast is announced politely to screen readers rather than interrupting mid-sentence.
• Light and dark are both handled.

Private by construction

The live message that reaches a browser contains nothing — no title, no author, no link. It says only "look again". The notification itself is then fetched through Invision's own permission-checked endpoint, so a member can never be pushed something they are not allowed to read, even if a channel were somehow joined by the wrong person.

Each member listens on their own channel, and the permission to join it is cryptographically signed by your server for that one member. There is no shared feed to eavesdrop on.

Requirements

• Invision Community 5
• Optional: Realtime (with its gateway deployed) for instant delivery. Without it, the fallback check is used instead.

View File

Passkeys — sign in with a face, a fingerprint or a security key

A passkey replaces the password entirely. Your members tap their phone, look at their laptop, or touch a security key, and they are in. Nothing to remember, nothing to type, nothing to leak.

This is a real login method, not a second factor. Invision Community has no WebAuthn support of any kind — this registers through core's own login-handler system, so the passkey button sits alongside your existing sign-in options and behaves like one of them.

Why passkeys and not another password policy

• They cannot be phished. A passkey is bound to your domain by the browser. A convincing copy of your login page on another domain simply will not work — the credential refuses to sign for it.

• They cannot be reused. Every site gets a different key, so a breach somewhere else cannot reach your community.

• There is nothing on your server worth stealing. You store a public key. It verifies signatures and can create none.

• Nothing to reset. No "forgot password" flow, no reset emails, no support tickets about them.

What members see

Works with what people already have

Face ID and Touch ID, Windows Hello, Android biometrics, iCloud Keychain, Google Password Manager, 1Password, Bitwarden, and hardware keys such as YubiKey. Nothing to install — every current browser has this built in.

Built carefully, because this is authentication

Every check the WebAuthn specification asks for is performed, and the reason each one exists is that skipping it breaks the model. The challenge is single-use, purpose-bound and expiring, so a captured ceremony cannot be replayed. The origin is compared exactly — not "starts with" — so a lookalike domain cannot relay it. Registrations cannot be replayed as logins. A signature is verified over exactly the bytes the authenticator signed.

• Cloned-device detection. WebAuthn gives one signal that a credential may have been copied: a signature counter that goes backwards. If that happens the passkey is disabled and the member is told why. Authenticators that don't count at all report zero forever — that is normal, and is never mistaken for an attack.

• No third-party code. No composer packages, no bundled cryptography library, nothing fetched at runtime. Verification uses PHP's own OpenSSL functions.

• Hidden when it cannot work. Browsers refuse passkeys outside a secure context, so on a site without HTTPS the button does not appear rather than failing when pressed.

• No core files are edited. Upgrading Invision Community will not break it.

What you control

• How many passkeys each member may register

• Whether to require user verification — a fingerprint, face or PIN, rather than mere presence

• Whether a backwards counter disables the credential

• The name members see on their device when it asks them to confirm

Requirements

• Invision Community 5.0 or newer (self-hosted)

• HTTPS. Browsers will not create or use a passkey without it.

• PHP with OpenSSL — standard on every install

View File

Auto Tagging — tags every topic by what it is about

Tagging only works if people do it, and people do not do it. Your tag list gets built with care, gets used properly for a fortnight, and then quietly stops being used at all. Everything posted after that is untagged, so tag pages go stale, filtering misses things, and the vocabulary you designed is doing nothing.

This reads each new topic and applies the tags that actually fit it.

It matches meaning, not words

A topic titled "my card keeps getting declined and I was charged twice" gets tagged billing — a word that appears nowhere in it. Invision's own tag box offers autocomplete over text the author has already typed, which cannot do this. Matching here is done on meaning, so a topic reaches the right tag even when it shares no vocabulary with it at all.

It uses your tags. Only your tags.

Nothing is invented and nothing new appears in your tag list. The app reads the tags you have already defined and chooses between them, so the vocabulary stays exactly as you designed it. Disable a tag and it stops being applied.

It also learns what each tag means in your community, not in general. A tag is understood partly from the topics that already carry it, so build on a woodworking forum and build on a gaming forum end up meaning quite different things — as they should.

It will not touch work someone did by hand

This is the part worth reading carefully. Adding a tag in Invision Community is not actually an operation the platform offers — saving tags replaces every tag on the item. A tagging tool that gets that wrong will silently delete tags your moderators set, and nobody will connect the loss to the app that caused it.

Auto Tagging always writes the complete set: existing tags, the new ones, and the item's prefix. By default it leaves anything already tagged completely alone.

Honest about confidence

Every match carries a score, and there is a threshold below which nothing is applied. The defaults are set to tag less rather than tag wrongly — a wrong tag is worse than a missing one, because someone has to find it and undo it.

There is a Preview screen that scores real topics from your own community and shows you the numbers, so you can pick a threshold from evidence rather than from a guess. It tags nothing while you do it.

Fits around the site rather than into it

• Posting never waits. Tagging happens in the background after the topic is saved. Nobody sits watching a spinner while an API is called.

• Backfill on demand. Tag the topics you already have, batched so a large community does not arrive as one enormous bill.

• Scope it. Restrict it to certain forums, and list any tags it must never apply — solved and staff pick mean something procedural that only a person should decide.

• Respects your limits. It will not push an item past your site-wide maximum tags per item.

• One key, one bill. If you run Related Topics or AI Assistant, it can borrow their embeddings key instead of asking for another.

• No core files are edited. Upgrading Invision Community will not break it.

What it costs to run

Auto Tagging needs an embeddings API key — Voyage AI or OpenAI. This is not a subscription to me; you hold the account and pay the provider directly.

Embeddings are among the cheapest things either provider sells. Your tag list is processed once and then only when it changes, and each new topic is a single small request. For an ordinary community this runs to a trivial amount per month, and there is no charge at all while nothing is being posted.

Requirements

• Invision Community 5.0 or newer (self-hosted)

• Forums

• Tags enabled, with at least a few tags defined

• An embeddings API key from Voyage AI or OpenAI — or Related Topics / AI Assistant already installed, in which case it can share theirs

View File

SEO Toolkit — find what's costing you traffic, then fix it

This does not claim Invision Community has no SEO. It has friendly URLs, sitemaps, canonical tags and JSON-LD, and they work. What it has no answer for is "is any of it actually set up correctly on my site, and what is search doing with it?" That is the gap.

The audit

One button. It reads your community and tells you what is wrong, worst first, with a link to each offender.

Two findings that quietly cost the most. Friendly URLs being off means every page is served at a query string. And with them on but not forced, every page is reachable at two addresses — which search engines read as duplicate content. Invision's own note on that setting says so. Neither shows up anywhere in the AdminCP until something has gone wrong.

Findings are fingerprinted, so re-running updates what is still true rather than piling up duplicates — and anything you have dismissed stays dismissed instead of reappearing every week. Anything you fixed disappears on the next run.

Search Console and GA4, in the AdminCP

Clicks, impressions, click-through rate and average position. What people actually searched for. Which pages got the clicks. Sessions, users and landing pages from GA4 alongside them.

• A service account, not OAuth. Paste one JSON key. No consent screen, no redirect URL to register, no refresh token to keep alive.

• The last three days are deliberately excluded. Search Console lags, and including today makes every report look like a traffic collapse.

• Answers are cached for the day, because the data only changes daily and the calls are metered.

Redirects that core cannot do

Core follows items that were merged into other items. It has nothing for "we restructured the forums and forty URLs moved" — which is exactly when a site loses its rankings.

• 301, 302, 307 or 308, with a hit counter so you can see what is still being used

• Prefix rules that carry the rest of the path across, so /old/a/b lands on /new/a/b rather than dumping everything on one page

• Loops are refused, not stored. A redirect loop is invisible until a crawler walks into one, and then the page is simply gone from the index

The tags core leaves out

• Twitter card tags. Invision emits Open Graph tags from eight applications and no twitter: tags whatsoever. These are derived from the Open Graph tags already on the page, so the two can never disagree.

• A fallback share image, used only when a page has none of its own.

• Per-forum overrides. Core's meta tag feature is a flat list keyed by exact URL, so keeping one forum out of search means knowing every address inside it. Here you pick the forum, tick noindex, and choose whether it applies to sub-forums.

Built to be safe on a live site

• The audit never crawls you over HTTP. Everything is answered from the database. A crawler on a large forum is slow and hammers the server it is meant to be helping.

• Outbound links are the one exception, and they are fetched slowly, in small batches, on a daily schedule — never in a burst that looks like an attack on the sites you link to.

• HEAD first, falling back to GET, because plenty of servers refuse HEAD while serving pages perfectly well. A refusal is not evidence a link is dead.

• Requests are pinned to http and https, and private address space is skipped, so a background job cannot be steered somewhere it should not go.

• No core files are edited. Upgrading Invision Community will not break it.

Requirements

• Invision Community 5.0 or newer (self-hosted), with the Forums application

• Optional: a Google service account, for Search Console and GA4 reporting

View File

Font Awesome — use the icons you already pay for

Invision Community ships Font Awesome 6 Free and gives you no way to change it. If you have a Font Awesome Pro subscription, none of it works here. If you want an icon added since 2024, it isn't there.

This is a small, free application that fixes both.

It costs nothing. There is no licence key and nothing to renew. If you use Kit mode you are using the Font Awesome subscription you already have — this simply lets Invision Community see it.

Two modes

Both load from Font Awesome's own CDN, not a third-party mirror.

Kit setup is one field

Paste your Kit ID and save. It accepts whatever you have to hand — the bare ID, the kit URL, or the entire <script> tag copied from your Font Awesome dashboard. There is a Test the connection button that tells you what actually loaded before you go looking at your site.

Nothing breaks

This is the part worth understanding, because it is why the application is safe to install on a live community.

Invision Community loads its own Font Awesome from a core template that offers no way to remove it. Rather than edit that file — which an upgrade would overwrite — this loads afterwards and takes precedence.

That has a real benefit beyond upgrade safety. Font Awesome 7 dropped exactly one icon that existed in 6 (fa-vector-square). Because Invision's copy is still underneath, that icon keeps working. An application that replaced Font Awesome outright would have broken it silently on every site using it.

The cost is about 70KB of stylesheet that goes unused. That is the trade, stated plainly.

What you control

• Which mode — Free 7 or your Kit

• Which release of Font Awesome 7

• Whether the AdminCP uses it too, or stays exactly as Invision ships it

• Turn it off at any time and you are back to stock, immediately

Requirements

• Invision Community 5.0 or newer (self-hosted)

• For Kit mode: a Font Awesome account with a published kit. Free plans have kits too.

• Outbound HTTPS from visitors' browsers to Font Awesome's CDN

No core files are edited, no database tables are created, and nothing is stored except your settings.

View File

Disposable Email Blocker — stop throwaway signups

Ten-minute mailboxes are how a banned member comes back, how one person becomes fifty accounts, and how a spam run gets its foothold. Invision Community has no idea those domains are different from anybody else's.

This knows about eight thousand of them, keeps the list current by itself, and decides what happens the moment such an account is created.

What it does

• Recognises throwaway domains. A maintained public blocklist, fetched at install and refreshed daily, so a service that launched last week is caught this week.
• You choose the response. Hold the account for approval, ban it outright, or record it and do nothing — useful for watching what arrives before you act on it.
• Your list beats the public one. Add domains it misses, and mark domains it is wrong about as always allowed. A refresh never touches either.
• Blocking a domain blocks its subdomains. One entry for example.com covers mail.example.com without listing every variation by hand.
• Shows you what it caught. A panel of counts and the recent catches, so you can tell whether the rule is right rather than trusting that it is.

Holding for approval is the default, on purpose

Not everybody using a forwarding address is a spammer. Plenty of careful people sign up to a new forum with a throwaway address precisely because they do not know you yet, and some of them become your best members.

So the default is to hold the account for a human, not to ban it. You get to look. Ban is there when you want it, and there is a third setting that changes nothing at all and simply keeps a record — the honest way to find out what your signups actually look like before you start turning people away.

It acts when the account is created, not at the signup form

Worth being straight about, because it is visible to you: Invision Community 5 provides no way for an application to refuse a registration while the form is being filled in. The account is created, and this acts on it immediately afterwards.

That is not a workaround — it is the better place to stand. It means the check also covers registrations that never touch the form: social and OAuth logins, and anything created through the REST API. A guard bolted onto the signup form would miss all of them, which is exactly where a determined spammer goes next.

Built not to get in the way

• A fault never blocks a real signup. If the database is unhappy, the check is skipped rather than failing closed. A spam tool must never be the reason somebody cannot join your community.
• A bad download cannot empty your blocklist. If the source returns a suspiciously small list, it is treated as a failed fetch and the existing list is kept.
• Existing members are never touched. It only ever looks at an account as it is created.
• The log records the domain, never the address. You do not need a file of other people's email addresses to decide whether a rule is working.

Requirements

• Invision Community 5.0 or newer, self-hosted
• Outbound access to fetch the blocklist — or add domains by hand and turn the refresh off, which works perfectly well on a closed network

Built to be safe

It adds two small tables, hooks no templates, and never edits a core file. Everything it does happens on the member-created event, wrapped so that no fault of its own can surface to the person registering.

Version 1.0.0 · Invision Community 5 · self-hosted

View File

LaTeX Maths — proper equations in any post

Members write LaTeX. Your community renders it. An integral looks like an integral, a matrix looks like a matrix, and a fraction stops being (a+b)/(c+d) typed in despair.

Invision Community offers LaTeX support on its Cloud plans. On a self-hosted Classic licence it is not available at any price. This is that feature, for the licence you already own.

What it does

• Renders maths anywhere content is shown. Forums, Pages, Blog, Clubs, comments — one pass covers them all, because it works on the rendered page rather than hooking each application in turn.
• Display and inline. $$ … $$ gives a centred equation on its own line; \( … \) sets maths inside a sentence, so a variable can sit in the middle of a paragraph without breaking the line.
• An editor button. Members who do not know the syntax press it, get the delimiters, and type between them.
• Nothing to sign up for. No API key, no service, no per-equation cost. The renderer ships inside the application and runs in the reader's browser.

It renders when the page is shown, not when the post is saved

This is the decision the whole application turns on, and it is worth understanding before you buy.

Your posts keep the notation exactly as it was typed. Nothing is rewritten in your database, so a member editing a two-year-old post edits what they wrote rather than a wall of generated markup — and if you ever switch the application off, or remove it, every post simply shows its notation again. There is no migration, and nothing to unpick.

The things that usually go wrong, and do not here

• Money stays money. Treating a single $ … $ as maths is off by default, because "it cost $5 and then $10 more" is a sentence, not an equation. Turn it on if yours is a maths or science community where that trade makes sense; \( … \) does the same job with no ambiguity.
• Code stays code. Anything inside a code block is left alone, so a member explaining LaTeX is not silently rendered by the thing they are explaining.
• A typo does not take the page down. Malformed notation shows in red, in place. Every other equation on the page still renders.
• A pasted thesis cannot hang a browser. There is a ceiling on how many equations one post will typeset. Past it, the notation is left as text rather than rendered.

Requirements

• Invision Community 5.0 or newer, self-hosted
• Nothing else. No account, no key, no external service, and no outbound connection — the maths renderer is bundled and served from your own site, so it works on a closed network and under a strict content security policy

Built to be safe

Rendering is done by KaTeX, the typesetting library used by Khan Academy, and it runs with the LaTeX commands that can reach outside a post — \href and friends — switched off, so a member's equation cannot become a link out of your community.

It is upgrade-safe: it adds no database tables, hooks no templates, and never edits a core file.

Version 1.0.0 · Invision Community 5 · self-hosted

View File

Member Map — see where your community actually is

Most communities have no idea where their members are. You can guess from the timezone spread in your statistics, but you cannot see it, and neither can anyone else. A map turns a list of usernames into a group of people in places, and it is one of the few features that members genuinely enjoy adding themselves to.

Nobody appears without choosing to

There is no import, no bulk geocoding of profile fields, and no automatic placement of anyone. A member types a town on the map page and presses a button. That is the only way a pin ever appears. They can take themselves off again at any time, and doing so deletes the row rather than hiding it.

It stores a town, never an address

You can make it vaguer still. One decimal place is roughly ten kilometres, which suits a community that would rather show countries than cities.

No mapping account, no card on file

The map uses OpenStreetMap, and place names are looked up with OpenStreetMap's own geocoder. Neither needs an account, an API key, or a billing relationship, so this app costs nothing to run and there is no quota to blow through on a busy day.

Every lookup is cached, so a hundred members in Berlin cost one lookup between them. If you would rather use your own tile server or a commercial provider, both the tile URL and the geocoder URL are settings.

Guests do not see it by default

Your members agreed to be visible to a community, which is not the same as being visible to the internet. Guest access is off until you turn it on.

What you get

• A map page listing everyone who has opted in, each pin linking to their profile
• A single field for members to add or change where they are
• Adjustable precision, so you decide how vague a pin is
• Your choice of tile server and geocoder
• A count of who is on the map, and a one-click purge in the AdminCP

View File

A two-way bridge between a forum and a Telegram group. Posts go out; replies come back and become real forum posts, written by the member who wrote them.

Why two-way

Sending forum posts to a Telegram channel is something you can already do with any webhook tool, including one you may already own. The half nobody offers is the return path: a message typed in the Telegram group becoming a post in the forum, attributed to the member who typed it, so the conversation is in one place instead of two.

How members are identified

A member links their own account from their forum settings. They are shown a one-time code, and they send that code to the bot in a direct message — never in the group, because a code pasted into a group is a code everybody in it can use.

Until somebody links, their messages are ignored rather than guessed at. If you would rather nothing was lost, you can nominate an account for unlinked messages instead — but the strict setting always wins, so turning it on cannot be undone by a stray configuration elsewhere.

What it will not do

• It will not post its own messages back to the forum, or forum posts that arrived from Telegram back to Telegram. The loop is closed in both directions.
• It will not accept a call to its endpoint that cannot prove it came from Telegram, and it fails closed rather than open if the secret is missing.
• It will not post the same message twice when Telegram retries a delivery.

Requirements

• Invision Community 5
• A Telegram bot token from @BotFather — free
• Your community reachable over HTTPS, so Telegram can deliver to it

View File

Federation

Somebody on Mastodon searches for @support@yoursite.com, presses follow, and from then on every new topic in that forum arrives in their timeline. They reply from where they already are. Nobody signs up for anything.

Federation makes your forums followable from the fediverse over ActivityPub — from your own domain, with no bridge and no third-party service in the middle.

How it works

No server configuration. Most ActivityPub implementations hand you an nginx rewrite rule and wish you luck. This one is an application: install the tar, pick your forums, done. It serves its own WebFinger, NodeInfo and actor documents through Invision Community's own routing.

Built to be safe with a stranger's instructions

An inbox is the only endpoint on a forum that acts on requests from people you have never heard of, so the checking matters more than the feature list.

• Every incoming request is verified with HTTP Signatures — and not only that the signature passes, but what it covers. A signature that omits the request target can otherwise be replayed against a different endpoint, turning a harmless activity into a destructive one.

• The body digest is checked against the body. A valid signature over a swapped payload is refused.

• Replays are rejected, so a repeated delivery cannot become a duplicate post.

• A delete for one of your posts from a remote server is refused outright. Only the original author's server may withdraw their own content.

• Stale requests are refused, with enough tolerance for a server whose clock has drifted.

Delivery that tells you the truth

Publishing is one-way and permanent. Anything federated leaves your server and is stored on other people's. It cannot be recalled — a delete is a request that well-behaved servers honour, not a guarantee. Choose the forums deliberately, and do not federate anything you would not put on a public timeline. Federation ships switched off with no forums selected, and stays that way until you choose.

Check it actually works

The AdminCP fetches your own discovery endpoints from the outside and tells you what came back. If a firewall, a CDN rule or an nginx block on dot-directories is swallowing them, you are invisible to the fediverse and there is no other symptom — you simply never appear in anyone's search. This turns that into a line of text you can read.

Requirements

• Invision Community 5.0 or newer (self-hosted)

• A public hostname over HTTPS, and PHP with OpenSSL

• The task scheduler running, since delivery is queued

• No account with me, no external service, no per-post fee

Set your community's URL before you federate. Every address this creates is built from it, and other servers remember them. Changing the board URL afterwards orphans every actor, follower and published post on every server that has seen them.

View File

Writing Assistant

Plenty of people have something worth saying and stall before they say it. The support question that arrives as "it's broken, help". The reply that reads angrier than it was meant to. The topic somebody starts three times and abandons.

Writing Assistant puts a button in the post editor, next to bold and italic. It fixes what is already written, and it drafts from a sentence when there is nothing written at all.

Seven ways to improve what is there

And two for the blank page

The member writes a sentence about what they want to say, and gets a draft to edit. Ask a better question is the same idea pointed at your support forum: it turns a vague complaint into something your community can actually answer.

It marks what it does not know instead of inventing it. Every assistant of this kind fills gaps with plausible specifics — a version number, a price, an error message nobody ever supplied. On a forum that means members posting confident details that are false, and your staff correcting them. This one writes [your IPS version], [paste the error here], [what you have already tried], and tells the member the draft has gaps to fill. A draft with three placeholders is useful. A draft with three fabrications is a trap.

It cannot damage a post

• Quoted text, code blocks and mentions are removed before the request and put back afterwards. The model never sees them, so it cannot alter them. If one does go missing, the member is warned before they can replace anything.

• Nothing is applied without the member pressing Replace. They see the result first, can compare it against the original, and can retry.

• Every change goes through the editor's normal undo.

You decide what it costs

Spend is an estimate, not a bill. It is calculated from published token prices for models it recognises. A self-hosted model shows as zero, which is accurate — but so does an unrecognised commercial one, and for that the cap cannot protect you. Set a budget limit with your provider as well.

The instructions are yours to change

A support forum and a fiction workshop want opposite things from "improve writing". Every instruction is editable in the AdminCP, including the shipped ones, and your edits survive upgrades. You can add your own actions too, with their own icon and group restrictions.

Shared safety rules — never invent facts, return only the text, preserve quotes and code — are applied automatically and cannot be removed by editing an action.

Reporting that tells you something

Calls and spend, broken down by action and by member. The number worth watching is how often members keep the result rather than cancelling. Call counts only prove the button is being pressed; a low kept-percentage on one action means its instruction needs retuning, and you can go and retune it.

Your key, your data

• Works with Anthropic, or anything speaking the OpenAI chat-completions shape — including self-hosted gateways such as Ollama, vLLM, LiteLLM and OpenRouter. Set the base URL and nothing leaves your network.

• Members' drafts are not stored. The log records which action ran, when, by whom, and the token counts — not the text. There is a setting to keep it temporarily while you tune a prompt; it is off by default.

• Already running AI Assistant or Guardian? It will reuse that key rather than making you paste a second copy.

Requirements

• Invision Community 5.0 or newer (self-hosted)

• An API key from your chosen provider, or a self-hosted endpoint

• Outbound HTTPS from your server

• No account with me, no service of mine in the middle, no per-request fee. You pay your provider directly for what your members use.

View File