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.
Invites only mean something if your Discord server has no ordinary invite links of its own. The setup guide covers this — it is the one step people miss.
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.

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

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.

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.