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

Tag Colours — your tags, finally telling them apart
Invision Community already has tags. What it does not have is any way to make them look like anything. Every tag on your site is the same shape and the same grey, so a topic tagged Solved is visually identical to one tagged Urgent, and members read every label one at a time.
Tag Colours fixes that in about a minute.
Solved Bug Report Feature Request Announcement Off Topic
It builds on the tags you already have
This is not a replacement tag system. There is nothing to migrate, no second set of labels to maintain, and no new way for your members to tag things. It reads the tags already on your community and lets you pick a colour for each one.
Because it works with the built-in system, the colours turn up everywhere tags already appear — topic view, topic lists, search results, tag pages, and the Blogs, Calendar and Pages applications too.
Setting it up
The admin screen lists every tag actually in use on your community, most-used first, with a note of how many items carry it. Click a tag, pick a colour, done.
Or click Colour them for me and every uncoloured tag is given a distinct colour from a readable palette — a sensible starting point you can then adjust. It never overwrites a colour you chose yourself, and it will not hand two tags the same colour.
Three styles
Solid — the tag is filled with your colour
Soft — a tinted background with coloured text, for a lighter touch
Outline — a coloured border and text on a transparent background
Pick one and it applies to every coloured tag, so your tags stay consistent with each other whatever your theme looks like.
Readable by default
Choose a tag colour and the text colour is worked out for you, using the same contrast maths the accessibility guidelines use — dark text on light colours, light text on dark ones. You never end up with a yellow tag nobody can read. If you want to override it on a particular tag, you can.
Built to stay out of the way
No core files are edited and no templates are overridden, so upgrading Invision Community will not break it and will not undo your work.
One small stylesheet is added to the page, cached permanently by the browser and only re-fetched when you actually change a colour. There is no JavaScript and no per-page work.
Turning it off restores your theme's own tag styling immediately — and keeps your colour choices, so turning it back on picks up where you left off.
Uninstalling leaves no trace. Your tags are Invision Community's tags; only the colours belong to this application.
Requirements
Invision Community 5.0 or newer (self-hosted)
Nothing else — no external service, no API key, no background jobs

Topic Summary — 108 minutes of thread, in 8
Every busy community has them: the 200-post thread nobody new will ever read. Topic Summary offers a short version built from the posts that actually mattered, so a newcomer can catch up in minutes instead of bouncing off a wall of replies.
Your topics are never altered. Nothing is deleted, nothing is hidden — it is simply an alternative way to read.
What your members see
On any topic long enough to warrant it, a quiet banner appears above the posts:
"This topic contains 154 posts and takes about 108 minutes to read. A summary of the most significant posts takes about 8 minutes."
One click and they get those posts, in the order they were written, with the opening post and the accepted answer clearly marked, and honest "19 posts skipped" markers between them so the conversation still makes sense. Every post links back to its place in the full topic.
How the significant posts are chosen
Significance blends two kinds of signal, which matters more than it sounds:
Engagement — reactions, quotes, "helpful" marks, featured posts, and the accepted answer
Structure — the opening post, how substantial a post is relative to the rest of that topic, and the topic starter returning with an update
Short "thanks" and "+1" replies are pushed down. The opening post and a marked answer are always included.
Blending both is deliberate. A younger community with few reactions would get nothing useful from an engagement-only score — the structural half means the summary is worth reading from day one.
Honest by design
No banner unless it helps. If the summary would not actually save reading time, nothing is shown.
Nothing is hidden from anyone. The summary only ever shows posts from a topic the member can already read, and always offers the full topic.
Skipped posts are admitted. Gaps are labelled rather than glossed over, so nobody is misled about what they have and have not seen.
What you control
How many posts a topic needs before a summary is offered
How many posts a summary contains
The reading speed used for the estimates
Turn the whole thing off at any time — your topics are untouched
The settings screen also shows how many of your topics are currently long enough to qualify, so you can pitch the threshold sensibly.
Requirements
Invision Community 5.0 or newer (self-hosted), with the Forums application
Nothing else — no external service, no API key, no background jobs to configure
Summaries are worked out on demand and nothing is stored, so there is no index to build and nothing to keep in sync.
It is upgrade-safe — it reads Invision Community's own data and never edits a single core file.

Community Stats — one block that fits wherever you put it
Invision's built-in stats block shows three things: total members, most ever online, and the newest member. No posts, no topics, no sense of whether any of it is growing.
This shows what a visitor actually wants to know, with the trend behind it — and it reflows to whatever space you give it.
The same block, both orientations
It measures its own container, not the browser window. Drop it in a 260px sidebar and it renders as a neat stacked list. Drop it across a content column and the same block becomes a row of tiles. Nothing to configure and no second block to maintain — a normal responsive block cannot do this, because a viewport media query cannot tell a narrow sidebar from a wide page.
If you would rather decide yourself, you can force it to always stack or always tile.
Who's online, with faces
A row of avatars linking to profiles, with an overflow count when there are more than will fit.
Anonymous browsing is respected, properly. A member who has chosen to browse anonymously is never shown and never counted — and neither are guests or search engine spiders. The number beside the avatars is derived from the same list that draws them, so the count and the faces can never disagree with each other.
Figures that mean something
Counts
Members, topics, posts, online now, newest member
And, if you run them
Files, images, blog entries, events
Trend
A rise or fall over a period you choose
Sparkline
A 30-day line beside each figure
Only the figures your community can actually produce are offered — install Gallery and an image count appears in the list by itself. Nothing runs a query for something you are not showing.
Trends work on the first day
Members, topics and posts can be rebuilt from their own timestamps, so one click gives you a month of history immediately rather than asking you to wait a month for the block to look finished. Everything else starts recording from now.
And until there is real history, no trend is shown at all. A "+0" on a fresh install would be a lie dressed up as data.
Built to sit on a busy page
Cached. Counting every row on a large community is not free, so figures are shared between visitors for an interval you set.
No JavaScript. The sparklines are drawn inline as SVG — no charting library is loaded, on any page the block appears on.
Big numbers stay readable. 12,300 becomes 12.3k rather than breaking the layout of a sidebar.
Follows your theme, or takes an accent colour of your choosing.
No core files are edited. Upgrading Invision Community will not break it.
Requirements
Invision Community 5.0 or newer (self-hosted)
Forums, Downloads, Gallery, Blog and Calendar are all optional — the block simply offers whatever you have

Related Topics — suggestions that understand what a topic is about
Invision Community can already show related content. It matches on tags. That means it works exactly as well as your members tag things, which on most communities is somewhere between patchily and not at all — and when everything in a forum carries the same three tags, "related" degrades to "everything".
This matches on meaning. It reads each topic, turns it into a vector, and compares topics by what they are actually about. No tags required, and no tagging discipline to enforce.
A real example from testing. A topic about a workflow-automation app for Invision matched a topic about an automation extension for a completely different forum platform, at 79%. Different forum, different category, no tags in common. Nothing tag-based could ever have found that.
Two ways to show it
Automatically
A "Related discussions" list appears below the posts on every topic. No block placement, no template editing.
As a block
A placeable widget for your sidebar, if you would rather choose where it goes. It only appears on topic pages.
Use either, or both.
It tells you when it has nothing to say
This is the part most "related content" features get wrong. If nothing clears your similarity threshold, nothing is shown at all — no empty box, no heading over a blank list, no five tenuous suggestions padding it out. Silence is the honest answer when nothing is related.
You tune it against your own content, not a guess
There is no threshold that is right for every community, and this application does not pretend otherwise. On a focused forum — where most topics are broadly the same kind of thing — even unrelated pairs score in the sixties. On a varied one the gap is much wider.
So the settings screen shows real matches from your own topics with their real scores, including the ones currently falling below your threshold and greyed out. You pick your number by looking at your own content. That takes about a minute and it is the difference between suggestions people click and suggestions they learn to ignore.
Costs, stated plainly
You need an embeddings API key — Voyage AI or any OpenAI-compatible provider.
One API call per topic, once. Editing a topic only re-embeds if the text actually changed, so fixing a typo costs nothing.
Embedding models are inexpensive. A few thousand topics is small money, but it is not zero and you should know that before you install.
Already running my AI Assistant? One switch and this borrows its provider, key and model, so you manage one key and one bill.
Built to stay out of the way
Nothing blocks posting. Indexing happens on the background queue. An outage at the embeddings provider means new topics wait their turn, never that members cannot post.
Permissions are respected. A topic a member cannot open is never suggested to them.
Changing the model is safe. Different models produce different vector sizes; mismatched entries are skipped rather than compared, so you get fewer results instead of confident nonsense. Rebuild and they come back.
No core files are edited. Upgrading Invision Community will not break it.
What you control
How many suggestions, and the minimum similarity
Whether suggestions can cross between forums, or stay within one
Which forums are indexed at all
Automatic placement on or off
Requirements
Invision Community 5.0 or newer (self-hosted), with the Forums application
An embeddings API key from Voyage AI or an OpenAI-compatible provider

Quests — give your members something to chase
New members join, look around, and drift away because nothing tells them what to do next. Quests gives them a clear path: a set of goals, visible progress, and a reward when they finish.
Set up a quest once and it works retroactively — members who have been around for years see their real progress the moment you publish it.
How it works
Create a quest, then add the steps a member has to complete. A Getting Started quest might be: make 5 posts and upload a profile photo. A Community Regular quest might be: 100 posts, 5 topics started, 30 days as a member, and 10 reactions received.
Members see a board showing every quest, a progress bar, and a tick-list of the steps with their own numbers beside each one. There is nothing to claim and no button to press — progress updates as they take part, and rewards arrive on their own.
Eight goals to build from
Posts made
Topics started
Reactions received
Reactions given
Days as a member
Achievement points earned
Followers gained
Profile photo uploaded
Every one of these is read from activity your community already records. Nothing new is tracked, nothing needs backfilling, and switching the app on costs you no data.
Rewards that actually count
Finishing a quest awards your community's own achievement points and, if you like, an existing badge. Quest rewards flow straight into ranks, profiles and leaderboards — they are not a separate scoreboard sitting off to one side.
Each quest pays out exactly once. The completion is recorded before the reward is issued, so a member can never be paid twice.
What you control
Title, description and icon for each quest
Any number of steps, in the order you choose
How many achievement points completing it is worth
Which badge to award, if any
Whether the board is visible to signed-out visitors
Enable or disable a quest without deleting it
The admin screen shows how many members have finished each quest, so you can see which goals are landing and which are pitched too high.
Requirements
Invision Community 5.0 or newer (self-hosted), with the Forums application
Nothing else — no external service, no API key, no extra infrastructure
Built to stay out of the way
Progress is recalculated when a member posts, when they open the board, and by a nightly background task that catches time-based goals like "member for 30 days". Quest bookkeeping is wrapped so it can never interfere with someone posting.
It is upgrade-safe — it reads Invision Community's own data and never edits a single core file.

Pulse — traffic analytics that never leave your database
Invision Community tells you a great deal about your content. Registrations, posts, reactions, badges, points, solved rate — there are forty statistics screens in the AdminCP and they are genuinely good.
None of them tell you about your traffic. Not pageviews. Not visitors. Not where anybody came from. Guests, who are most of the people reading your community, appear nowhere at all — they exist only in the sessions table, which is wiped continuously.
The official answer is Google Analytics
Invision Community ships an integration whose entire job is injecting Google's tracking script into your pages. That is the supported route, and for a lot of communities it is not a route at all: a cookie banner, a data-protection question you would rather not answer, and your members' browsing habits handed to an advertising company.
Pulse is the third option. Every figure below is measured on your own server, stored in your own database, and shown in your own AdminCP. Nothing is sent anywhere.
What it measures
Headline
Pageviews · visitors · sessions · bounce rate · average visit length
Where they went
Top pages, with the whole path — not just content items
Where they came from
Referring sites, with your own domain excluded
Who
Members against guests, and desktop against mobile and tablet
Countries
A world map you can hover, country by country
Every headline figure carries a trend line, and the whole dashboard can be read over seven, thirty or ninety days.
No JavaScript. No cookies. No IP addresses.
This matters enough to be specific about, because "privacy-friendly" is easy to claim.
No script is loaded. Not one byte of JavaScript, not even for the charts — the graphs and the world map are inline SVG. Nothing is fetched from anywhere.
No cookie is set, so Pulse adds nothing to a consent banner.
No IP address is ever written to the database. One is read to compute a hash and immediately discarded. There is no column to store it in.
The visitor identifier is salted with a secret that changes every day. It cannot be reversed, and it cannot be matched from one day to the next — so it counts visitors without following anybody.
A pageview records whether somebody was signed in, never which account. There is no member column.
Raw events last hours, not for ever. They are rolled into daily totals and deleted. After that a day exists only as a handful of numbers.
The settings screen lists all of this in the interface, with live counts, so you can answer a data-protection question by pointing at it.
It cannot slow your forum down
The recording happens after the page has already been delivered. Invision Community closes the connection to the browser before running its shutdown work, and Pulse writes its single row at that point. The visitor has their page before the database is touched. There is no query on the way in, no join, and nothing that can fail in a way that affects the page.
Honest about the limits
Some things cannot be measured without JavaScript, and it is better to say so than to invent them:
A one-page visit has no measurable length. There is no exit signal, so bounces contribute nothing to the average visit time rather than a made-up figure. The average is over visits that can actually be measured.
Visitors are counted per day and added up. Somebody who comes on Monday and Tuesday counts twice over a week. Counting them once would mean keeping the raw records for the whole period, which is exactly what this app is designed not to do.
Countries need a header from in front of your site. If you run Cloudflare or a load balancer that provides one, the map fills in. If nothing supplies it, the map is hidden rather than shown empty. Pulse does no geolocation lookups of its own — that would mean either an external request or shipping a database of IP ranges.
Also
Crawlers are separated out, using Invision Community's own spider detection. Search engines can be most of your raw traffic and none of your audience.
You can exclude your own staff, so your browsing does not become the story.
Retention is yours to set — hours of raw events, days of history.
No core files are edited. Upgrading Invision Community will not break it.
Requirements
Invision Community 5.0 or newer (self-hosted)
A running task scheduler — the hourly rollup is what produces every figure
Nothing else. No API key, no account, no external service.

Everything you need to run a podcast from your community and get it onto Apple Podcasts and Spotify — the Podcast app and Podcast Studio, together, for less than buying them apart.
Buy the bundle and save against the two on their own. One purchase, both apps, one renewal. Podcast — host the show
A feed Apple Podcasts, Spotify, Overcast and the rest will accept — the iTunes namespace, owner verification, categories and artwork done to spec. Permanent, opaque episode IDs, so renaming an episode never makes every subscriber re-download your back catalogue. Schedule episodes, keep drafts invisible, and give each episode its own forum topic so the conversation happens with your members. A page and the browser's own audio player per show and per episode. No third-party host, no monthly fee — the feed address is yours. Podcast Studio — publish and distribute it
A guided walk-through to get each show onto Apple Podcasts and Spotify, tracking where every show stands on each. Instant publishing over WebSub: the moment you publish, directories that honour it — Apple among them — fetch the new episode in minutes instead of hours. A pre-flight check that tells you exactly what would get a show rejected before you submit it. It can read the ownership verification code out of your mailbox for you — optional, read-only, encrypted. What you need
Invision Community 5. Install Podcast first, then Podcast Studio. Everything else is built in — no external service to sign up for.

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

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.
Nothing is ever read from a member's browser. No location prompt, no IP lookup, no GPS. Somebody types "Berlin" because they want you to know they are in Berlin. It stores a town, never an address
This is the part that matters, and it is a design decision rather than a setting you have to get right. Coordinates are rounded before they are written, and the precise ones are never stored at all. At the default precision a pin describes roughly a kilometre — enough to show someone is in Lisbon, not enough to show which street. A database that never held the exact point cannot leak it, and a member who removes themselves leaves nothing behind. 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 Two honest limits. OpenStreetMap's tiles and geocoder are run by a volunteer project and their usage policy expects modest traffic — fine for a forum map, and the settings let a large community point at its own tile server instead. And the map draws in the browser using Leaflet, so a member browsing with JavaScript disabled sees the page but not the map.

Guardian — moderation that keeps your team away from the worst of it
Invision Community gives you the tools to remove bad content once somebody finds it. Guardian finds it first, ranks it by how bad it is, and puts it in one queue your moderators can actually work through.
And for the category of material nobody should have to look at, it does something different: it never shows it to them at all.
What it checks
Post text — spam, scams and phishing, harassment, hate, threats, and breaches of your rules. Paste your rules in and they are used when judging a post, so "against the rules" means yours rather than a generic idea of them.
Attached images — adult content, graphic violence, hate symbols, and images posted purely to advertise.
Known illegal material — attachments are matched against a vetted hash service you have arranged access to.
Everything is scored from 0 to 100. You choose the score at which something enters the queue, and the score at which it is hidden before a human sees it.
One queue, worst first
Flagged content arrives in a single triage screen ordered by severity, with the reason each check gave, the labels it applied, and the post excerpt. Two buttons: Looks fine puts it straight back, Keep hidden leaves it down. Cleared and removed items keep their own tabs so you have a record.
Guardian never deletes anything. Content is hidden using Invision Community's own moderation tools, so a wrong call is always reversible — and genuinely illegal material is preserved rather than destroyed, which matters if you later have to account for it.
The part that is handled differently
When an attachment matches a known-illegal hash set, Guardian does not treat it as a moderation decision, because it isn't one.
The post is hidden immediately and the file is preserved.
The queue entry shows no image, no post text, and no link to the content. There is no "view" button. Nobody on your team has to look at it in order to deal with it.
The identifying details — account, email, IP at the time of posting, timestamps, file hashes — are captured at the moment of detection, because by the time a report is filed the account may be gone and the IP record rotated away.
Clearing it is not offered. A moderator clicking "looks fine to me" is not the right way to overturn a hash match.
Reporting, wherever you are
Reporting duties are national, and the mechanisms differ. Guardian supports both shapes.
Destination
Region
How
NCMEC CyberTipline
United States
Filed directly from your server
Internet Watch Foundation
United Kingdom
Hotline form + reference recorded
Cybertip.ca
Canada
Hotline form + reference recorded
eSafety Commissioner
Australia
Hotline form + reference recorded
INHOPE network
International
Routes you to your national hotline
Your own endpoint
Any
Evidence package posted as JSON
Where an API exists, the file goes straight from your server to the destination — never downloaded, never emailed, never handed to a staff member to upload by hand. Guardian submits under your credentials; it never reports under its own identity.
Where one doesn't, Guardian links you to the right hotline for your jurisdiction and records the reference number you are given. The evidence is preserved and the audit trail comes out identical either way.
Costs you can actually control
A monthly spend limit. When it is reached the paid checks pause — but hash matching keeps running, because that is the one you least want switched off.
Separate models for text and images. Image checks are the expensive half; point them at a cheaper model without giving up text checking.
Skip established members. Set a post count above which members aren't scanned. New and guest accounts are always checked. This is the single biggest saving on a busy site.
Per-forum scope and trusted groups. Staff are always skipped.
The settings screen shows exactly what is running, how much you have spent this month, and how many images have been examined.
If you already run AI Assistant
Guardian works entirely on its own. But if AI Assistant is installed, one switch lets it use that application's provider, key and spend ledger — so you manage one key and one budget instead of two, and spend from both counts against the same limit. It is a convenience, never a dependency.
Built to stay out of the way
Nothing blocks posting. All checking happens on the background queue. An API outage means posts are unchecked, never that members can't post.
Silence is never read as safe. If a check cannot reach its service or the model refuses to assess something, that is recorded as needing a human — not quietly scored as clean.
No core files are edited. Upgrading Invision Community will not break it.
A full audit trail. Every decision, who made it, and when.
Requirements
Invision Community 5.0 or newer (self-hosted), with the Forums application
An API key from Anthropic or any OpenAI-compatible provider, for the text and image checks
For known-material matching and direct reporting: access to those services in your own name. Providers register with the relevant organisation themselves.

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
Each forum is an address
Choose which forums federate and each becomes a followable account — @support@yoursite.com. Your community also has one of its own.
Topics go out
A new topic is delivered to everyone following that forum. Replies follow as replies, so the thread reads as a thread rather than a pile of unrelated posts.
People come back
Follows, likes and boosts arrive from anywhere that speaks ActivityPub — Mastodon, Lemmy, Misskey, Pixelfed and the rest.
Your domain, your posts
Nothing is relayed through anybody else's server. The addresses are yours and the content is served from your site.
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
Queued, not inline
Nobody waits on a remote server to finish posting. Delivery runs in the background.
Retries that widen
A server being restarted is retried gently; a server that has gone for good is given up on within about a day and marked, rather than retried forever.
One copy per server
Where a remote offers a shared inbox it gets a single delivery for all its followers, instead of one request each.
Failures kept
The queue shows what went where, how many attempts, and the last error — so "why did that server stop receiving posts" has an answer.
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.

Community Experts — free
Invision Community has a Community Experts feature. Members you name as experts get a badge on their posts in the forums they actually know about, and get an email when a question in one of those forums goes unanswered.
It is Cloud only. On a self-hosted community it is switched off, and there is no setting anywhere that turns it on.
This does not imitate that feature. It completes it.
Almost all of Community Experts is already sitting in your installation, doing nothing:
The badge
The graduation-cap badge, its styling, and the follow-this-expert button are all core templates that already ship with your community.
The email
The "questions waiting for you" email — both the HTML and plain-text versions — is a core template.
The unsubscribe link
Core already knows how to handle it and which preference to change.
The data
Core already has the table that records who is an expert in which forum, and the member settings for opting out and being blocked.
What is missing is the switch. Every one of those pieces is behind a check for the Cloud platform, so none of them can ever run. This application supplies what is missing and uses core's own badge, core's own email, core's own unsubscribe handling and core's own table.
The practical result: what your members see is the real feature, not a lookalike. And because the assignments live in core's own table, a community that later moves to Invision Community Cloud finds its experts already in place.
Named per forum, which is the whole point
Somebody who knows billing inside out is not an authority on off-topic. Experts are named per forum and the badge only appears where they actually are one — a badge that follows a member everywhere is worth considerably less than one that does not.
Naming experts automatically, if you want to
Off by default. When enabled, anyone who clears both of these tests in a forum is given the badge there:
Accepted answers in that forum. Replies of theirs that somebody marked as the answer. This is the strongest evidence available, because the person with the problem said so.
Posts in that forum. A second test, so one lucky answer is not enough on its own.
Both are counted inside the forum, deliberately. Promoting on a site-wide reputation score or post count measures how much somebody posts, not what they know — on a community whose busiest forum is off-topic, that names the most prolific chatterer an authority on billing.
The admin screen lists everyone who currently meets the tests whether or not automatic naming is switched on, so you can see exactly who the rule would pick before trusting it with the decision. Nobody is ever removed automatically: taking a badge away stays a decision a person makes.
Emails that produce answers
Once an hour, experts are emailed about questions in their forums that nobody has answered. It skips anything they started, anything they have already replied to, and anything they have already been told about — an expert is never sent the same question twice. One email lists several questions rather than sending several emails.
Members can turn it off from their own notification settings, or from the link in the email itself. Both routes work because both are core's.
Also
An audit trail of who was named or removed, when, and by whom — with automatic changes marked as such and the reason recorded.
Members can opt out of being shown as an expert without losing their assignments.
Administrators can block a member from ever showing as an expert.
Restrict by group, so the badge can only reach the people you intend.
No core files are edited. Upgrading Invision Community will not break it.
Honest about the limits
Forums only. Experts are named against forums, because that is what core's own data does.
Automatic naming needs "solved" enabled in a forum. Without accepted answers there is no evidence to promote on, so nobody is ever named automatically in a forum that does not use it. Naming people by hand works everywhere.
The emails need a working task scheduler. Without one, nothing is sent.
Three language strings belong to core's namespace. They have to, because they are the strings for core's own email, which does not ship with them. If you ever migrate to Invision Community Cloud, uninstall this application first — see the setup guide.
Requirements
Invision Community 5.0 or newer (self-hosted)
The Forums application
A running task scheduler, for the emails and for automatic naming
Free. No key, no account, no external service.

Drip Campaigns — email sequences that run themselves
Somebody registers at three in the morning on a Saturday. A week later they have posted nothing and you have not spoken to them, because nobody was awake to. Multiply that by every member who ever joined and you have the reason most communities lose people in their first fortnight.
A drip campaign is a sequence of emails that starts when a member does something and then unfolds on their clock — a welcome straight away, a nudge two days later, an invitation to introduce themselves after a week. Everyone gets the same thoughtful onboarding regardless of when they arrived.
Invision Community has this. On Cloud. On some plans.
Email Drip Campaigns arrived in Invision Community 5.1 for Cloud customers, on selected packages. Self-hosted communities do not get them at all.
This app brings sequences to self-hosted — and adds the two triggers the Cloud version does not have. Both were the most-requested things in the comments under the announcement, and neither made it in.
The trigger nobody else offers: they stopped showing up
Every other trigger is an event — somebody did a thing, so something happens. Absence raises no event. Nobody fires a notification when a member quietly stops visiting, which is exactly why re-engagement is the hardest email to send and the one worth the most.
This app goes looking instead. Set a number of days, and members who cross that line are enrolled by a scheduled scan. A "we miss you" series that actually reaches the people it is about.
And renewals, which are not first purchases
Invision's Cloud version fires on "purchases a subscription". This one also fires on renewals, on an upcoming expiry — the moment worth acting on while there is still something to save — and on cancellations. Thanking a three-year customer for joining reads badly; these deserve different emails and now they can have them.
Every trigger
Joining
Registers · confirms their email · updates their profile
Taking part
Joins a club · responds to an event · completes a course
Money
Buys · renews · is about to expire · cancels
Absence
Has not visited for a set number of days
Chaining
Another campaign finishes
Event responses can be narrowed to one answer, so you are not telling somebody who declined that you will see them there. Triggers for applications you do not run are never shown, and never listened for.
Audiences built from filters you already have
This app invents no filters of its own. It uses Invision Community's own member filters, which means you can target by group, join date, last visit, content count, reputation, achievements and profile fields — and, if you run Commerce, by purchases, subscriptions, total spend and donations.
Anything a third-party application adds to that list works here too, automatically.
It checks again before every email
This is the part that stops a campaign embarrassing you. Someone qualifies for "we miss you" on Monday, comes back on Tuesday, and on Wednesday the second email arrives telling them how much you miss them. Audiences are re-checked before every send, not just at enrolment, so a member who stops matching stops receiving. It can be switched off; it is on by default for a reason.
Care taken where it matters
Opting out is honoured absolutely. A member who has turned off administrator emails is never enrolled, never sent to, and is removed from a campaign if they opt out mid-sequence.
Unsubscribing uses Invision Community's own mechanism — the same link, the same page, and a key derived from the account so it stops working when the password changes.
Nobody is enrolled twice. A trigger that fires more than once for the same person does nothing the second time.
Disabling an email does not strand anyone. Members waiting on that step move to the next one rather than sitting there for ever.
Posting and paying never wait on email. Enrolment happens in the background; sending happens on a schedule.
No core files are edited. Upgrading Invision Community will not break it.
Check a member
"Why didn't they get it?" has a dozen possible answers. There is a screen that gives you the actual one: whether they can be emailed at all, whether they match each campaign, whether they are enrolled, which step they are on, and when the next email is due.
Requirements
Invision Community 5.0 or newer (self-hosted)
Working outgoing email and a running task scheduler
Commerce, Calendar, Clubs are all optional — their triggers appear only if you run them

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

Most of the people reading your community are not members of it. They arrive from a search result, read the answer they came for, and leave — and nothing about that visit is recorded, so you never find out which of your topics were the ones worth joining for.
Convert does two things: it asks them to join at the moment they are most likely to say yes, and it tells you which pages actually worked.
Ask at the right moment
Invision Community's guest sign-up block is a static panel in the sidebar. It says the same thing to somebody who has just landed as to somebody who has read six topics and is scrolling to the bottom of a seventh.
Convert puts the prompt where the visitor already is, and only when it makes sense:
The reply box
Where a signed-out visitor is told they need an account to reply. They have read to the bottom of a discussion and want to say something — the strongest moment the software has.
Under the discussion
At the end of the posts on a topic.
Every page
The foot of any page, including Downloads, Pages and Gallery.
And only to the right people. Show it after somebody has read two pages, not one. Show it only to visitors who arrived from a search engine. Show it only in the forums where it makes sense. Show it at most twice a visit, so it never becomes wallpaper.
"No thanks" is remembered. When a visitor dismisses a prompt it stays dismissed, for as long as you choose. Nothing is more likely to lose a reader than asking them the same question on every page after they have already said no.
Then find out what actually worked
Every prompt is measured the whole way down: shown, clicked, joined, posted. Not just the click — the click is easy. The number that matters is at the bottom.
What brings people in
The pages people were reading when they decided to join, ranked. Usually a surprise, and usually the most useful screen here — it tells you what your community is actually good at before you write another word of copy.
Where they came from
Search, social, another site, or direct — recorded from the first page of the visit, so it survives them clicking around.
Compare two versions
Give two prompts the same test name and each visitor sees one of them, consistently, for their whole visit. Then read the two rows side by side.
It counts the people who joined without being asked, too. That is the number every prompt is competing against, and leaving it out is how conversion reporting ends up permanently flattering. If forty people joined unprompted last month and three came through a prompt, you have learned something real.
Honest about what it shows
A rate with nothing behind it is shown as blank, not as 0%. "Never shown" and "shown a thousand times and ignored" are opposite findings, and printing zero for both hides the difference exactly when you need it.
Impressions are counted on the server, as the page is built. Counting them with a script means an ad blocker can delete them, which quietly inflates every click rate you look at.
Posting is tracked separately from joining. A prompt that produces accounts which never post has produced nothing, and the report is built so it can say so.
What it collects
Daily totals per prompt — shown, clicked, dismissed. No row is ever written per visitor. The only per-person record is one row for each member who registers, so that the report can say which page brought them in; it is created at registration and belongs to a member you already have.
The only cookie it sets exists to remember that somebody pressed "No thanks". Everything else rides the session Invision Community already keeps.
Requirements
Invision Community 5.0 or newer (self-hosted)
Registration open to guests, which is what there is to convert them to
Nothing else. No account, no key, no external service.

Backup & Restore
Invision Community ships with no backup of any kind. The only thing it does is ask you to tick a box confirming you have made one — immediately before an upgrade, which is the single most dangerous thing the software does.
The usual advice is "just run mysqldump". On a correctly configured server you cannot. Invision Community's own Configuration Error notification tells administrators to disable exec, shell_exec, passthru, popen and proc_open. Take that advice, as you should, and every shell-based backup tool stops working.
This is pure PHP. No shell, no mysqldump, no external binary. It works on shared hosting, in a container, and on a hardened server where nothing can be executed.
It reads every backup back
A backup nobody has ever opened is not a backup — it is a file you are hoping about. After writing an archive this one reads it again, from the beginning, and checks:
the compressed stream decompresses whole, without truncation;
the end-of-file marker is present, which is what proves it was not cut short;
the SHA-256 checksum matches what was written;
every table is present, and every table's row count matches.
Only then is it marked verified. A backup that fails any of those is marked failed and — importantly — never counts towards your retention limit, so a good archive is never deleted to make room for a broken one.
It tells you when a backup is not a snapshot
Where the database is small enough to finish in one request, the dump runs inside a single transaction with a consistent snapshot: every table as it was at the same instant. Where it is too large, the work is queued across requests — which means the first table is read minutes before the last, while people are still posting.
Both kinds are labelled, on every row. A staged backup can contain a reply whose topic is missing. That is a real limitation of any backup taken this way, including mysqldump without --single-transaction, and you are told which kind you have rather than left to assume.
Somewhere other than the server it is protecting
A backup on the same disk as the community does not survive losing that disk. Archives are written above the web root where possible, so they cannot be requested over the internet at all — and can be sent to any storage you have already configured: Amazon S3, Cloudflare R2, Backblaze or FTP.
If the parent directory is not writable and archives have to live under the web root, the application says so plainly on the screen rather than quietly hoping the filename is enough.
Restoring
One table
The case that actually happens: somebody deleted a forum. Restore that one table and nothing else — the rest of the community, including everything posted since, is untouched. The screen shows which tables have lost rows since the backup, so you can see what is missing before you touch anything.
Everything
Runs from a generated standalone script, not from a button. A full restore replaces the very tables the running request depends on — sessions, caches, the job queue — and doing that from inside the suite is how a community ends up unable to start. The script boots nothing, reads your configuration directly and survives its own work.
The restore script is key-protected, refuses to run without an explicit confirmation, and refuses outright if the archive does not match the database it is pointed at — for example if it came from a different install, or before an application was added — unless you override it deliberately.
Details that matter when it counts
Binary data is hex-encoded, so blobs, attachments and anything with a NUL byte come back byte for byte rather than quietly corrupted.
A legitimate zero stays zero in an auto-increment column, instead of being silently reassigned and breaking every row that pointed at it.
Archives are portable. The dump is written as ordinary SQL that restores in any MySQL session, not only inside Invision Community.
The schedule is measured from the last successful backup, not the last attempt — so a job that fails every night cannot keep satisfying the schedule while producing nothing.
It survives its own restore. Restoring replaces this application's own records too; it rebuilds them by reading the archives back off disk, rather than reporting that you have no backups.
Requirements
Invision Community 5.0 or newer (self-hosted)
PHP with zlib, which every install already has
A running task scheduler, for scheduled backups
No shell access. No mysqldump. No external service.

AI Assistant — support that answers while you sleep
Your members ask the same questions at 2am that you answer every morning. AI Assistant replies for you. Mention its account in any topic and it answers in seconds — grounded in your own community's content, in your own words, on your own terms.
It runs on your API key with your provider. No subscription to us, no per-seat pricing, no member data passing through a third party.
What it does
Answers @mentions. A member mentions the bot account in a topic and gets a real reply, posted as a real member — notifications, search indexing and counters all behave exactly as they should.
Learns from your community. Optional knowledge retrieval pulls the most relevant passages from elsewhere on your forum and gives them to the model before it answers, so replies cite what your community already knows instead of guessing.
Captures bugs and suggestions. Every answered post is classified. Bug reports and feature requests land in a triage queue in your AdminCP — and, above a confidence threshold you set, are filed straight to GitHub as issues with the forum permalink attached.
Shows you exactly what it costs. Every call is logged with token counts and real dollar cost, with a monthly budget cap that stops the assistant when it's reached.
You stay in control
Persona and house rules. A free-text field that shapes every answer — who the assistant is, what your community is about, what it must never say, and when to escalate to a human.
Choose your forums. Pick exactly which forums it answers in. Leave it unselected for all of them.
Choose your model. Anthropic (Claude) or any OpenAI-compatible endpoint — OpenAI, OpenRouter, Groq, Azure, or a model you host yourself.
Never guesses out loud. The assistant is instructed to say plainly when it doesn't know, and to ask for the detail it needs rather than inventing a setting or a version number.
Knowledge retrieval, three ways
Off — answers from the current topic alone.
Keyword — searches your community with MySQL full-text. Needs no extra API key and works the moment you switch it on.
Semantic — true meaning-based retrieval using Voyage AI or any OpenAI-compatible embeddings endpoint. Finds the right answer even when the member's words don't match your wording.
Semantic mode degrades gracefully: if the embeddings key is missing or the service is unreachable, it quietly falls back to keyword search rather than answering with nothing. New and edited posts are indexed automatically, and a background job builds the index for your existing content in batches.
Requirements
Invision Community 5.0 or newer (self-hosted), with the Forums application
An API key from Anthropic, OpenAI, or any OpenAI-compatible provider
Optional: a Voyage AI or OpenAI embeddings key for semantic retrieval
Optional: a GitHub token if you want bug reports filed automatically
Built to be safe
Slow model calls run in the background, so a member's post is never held up waiting for an answer, and a failed call never blocks a reply. The assistant will not answer its own posts, will not answer the same post twice, and stops entirely once your monthly budget is reached. It is upgrade-safe — it listens to Invision Community's own content events and never edits a single core file.
Version 1.0.0 · Invision Community 5 · self-hosted

Disclaimer: This does not search the internet to get answers as that would eat up credits. The best thing to do is setup a KB with all information or it will only give answers based on forum posts.

Cohorts & Retention
Invision Community can tell you how many members you have and how many joined last month. It cannot tell you the thing that actually matters: of the people who joined in March, how many were still here in April? In June?
That single question is the difference between a community that is growing and one that is churning while the registration counter goes up.
The grid
Every row is everyone who joined in one month. Reading across shows how many of them came back one month later, two months later, and so on. Reading down a column shows whether the community is getting better or worse at keeping people — which is the number to watch after you change anything about registration, onboarding or moderation.
Twelve months of history, on the day you install it. This reads data Invision Community has been keeping since your community started, so the grid is complete from the first build. Nothing has to accumulate first.
Two definitions of "still here", because they answer different questions
Signed in
The broad measure. Includes people who read without ever posting, who are the majority of any community. Answers: are they still turning up?
Posted something
The hard measure. Any content in any application — a forum reply, a file, a blog comment. Answers: did they become a participant, or just an audience?
Both are worth looking at, and the gap between them is often the most interesting thing on the screen.
It collects nothing
There is no tracker, no new logging and no external service. Everything comes from three things your community already stores: when each member registered, the record of which days they signed in, and the index of who posted what and when. Uninstalling removes only this application's cached grid.
The grid is built in the background, never while you wait. Building it compares every member against their whole history, so it runs as a background job and stores the result. Opening the screen reads a small cached table — it does not recompute anything.
Honest about what it shows
Periods that have not happened yet are left blank, not shown as zero. A cohort that joined last month has no month-6 figure. Printing 0%% there would read as "everybody left" when the truth is "we do not know yet", and that difference matters when you are deciding whether something is wrong.
Month 0 is rarely 100%%. It is the month people joined, so anything missing is people who registered and never came back at all — one of the more useful numbers on the grid, and one most analytics never shows you.
Activity dated before somebody joined is discarded. Imported members, merged accounts and hand-edited join dates all produce it. It is dropped rather than shown in a column nobody can interpret.
Small cohorts are noisy. A cohort of nine people moves 11%% every time one person returns. The grid shows the underlying counts on hover for exactly this reason.
Also
Weekly or monthly cohorts. Weekly is worth using when you are measuring something specific — a launch, a campaign, a change to registration.
Up to 36 periods across, though twelve is usually where the interesting part has already happened.
No core files are edited. Upgrading Invision Community will not break it.
Requirements
Invision Community 5.0 or newer (self-hosted)
A running task scheduler, to build the grid in the background
Nothing else. No account, no key, no external service.

World of Warcraft armory for Flarum 2 — Battle.net login + character data (gear, stats, talents, raids, PvP, professions)
Install
From your Flarum root:
composer require ernestdefoe/armoryThen enable it in Administration → Extensions.
Source
GitHub repository
Packagist
Free and open source under the MIT licence. Requires Flarum 2.

Advanced Cookie Consent for Flarum 2 — GDPR banner + granular categories + script gating (free/MIT)
Install
From your Flarum root:
composer require ernestdefoe/advanced-cookie-consentThen enable it in Administration → Extensions.
Source
GitHub repository
Packagist
Free and open source under the MIT licence. Requires Flarum 2.

An aurora-inspired theme for Flarum featuring animated gradient backdrops, glassmorphic panels, glowing accents, and a dark night-sky palette.
Install
From your Flarum root:
composer require ernestdefoe/auroraThen enable it in Administration → Extensions.
Source
GitHub repository
Packagist
Free and open source under the MIT licence. Requires Flarum 2.

A polished, configurable Flarum 2 theme.
Install
From your Flarum root:
composer require ernestdefoe/mosaicThen enable it in Administration → Extensions.
Source
GitHub repository
Packagist
Free and open source under the MIT licence. Requires Flarum 2.

Mobile tab for Flarum 2.x
Install
From your Flarum root:
composer require ernestdefoe/mobile-tabThen enable it in Administration → Extensions.
Source
GitHub repository
Packagist
Free and open source under the MIT licence. Requires Flarum 2.

Run migrations and publish assets from the Flarum admin dashboard — no terminal needed.
Install
From your Flarum root:
composer require ernestdefoe/maintenanceThen enable it in Administration → Extensions.
Source
GitHub repository
Packagist
Free and open source under the MIT licence. Requires Flarum 2.