# profanity Console XMPP Client for Terminal Messaging > Profanity is an ncurses-based XMPP client written in C for people who want messaging in a terminal, with plugins and several encryption options. It suits users with an existing XMPP account, but its custom license requires review before adoption. **profanity-im/profanity** — Ncurses based XMPP client - Repository: https://github.com/profanity-im/profanity - Website: https://profanity-im.github.io/ - Stars: 1,555 · Forks: 229 - Language: C - License: NOASSERTION - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/profanity-im-profanity ## Why Profanity targets XMPP users in a terminal Profanity addresses a specific gap between graphical XMPP applications and command-line workflows. It is a console client inspired by Irssi, so the interface is built around ncurses rather than a desktop window. This makes it relevant to administrators, developers, remote users, and anyone who already spends much of the day in a terminal. The C implementation also makes the project a native codebase, although its license terms must be considered separately from the benefits of that language choice. The client is tied to XMPP, a decentralized protocol that allows organizations and individuals to run their own servers. That architecture makes Profanity relevant to people who want messaging not to depend exclusively on one centrally operated service. A user still needs an XMPP account or access to an XMPP service, however. Installing the client does not by itself provide an account, a server, contact discovery, or working delivery to other people. Profanity's privacy story centers on protocol support and server choice. The README lists OTR, PGP, OMEMO, and OX as supported encryption mechanisms. These are materially different options, and the README does not document their setup, negotiation behavior, interoperability, or security trade-offs. An evaluator should therefore treat the list as a capability inventory, not as evidence that all four modes work identically across every server and client. ## Profanity's ncurses interface and XMPP feature surface Based on the repository layout, Profanity is implemented in C, with application code under `src/`, tests under `tests/`, documentation under `docs/`, and integration details distributed through build files such as `meson.build` and `meson_options.txt`. The linked user guide is the authoritative source for operational details. The repository also contains API documentation under `apidocs/`, while `profrc.example` and the themes directories indicate that configuration and appearance are treated as first-class parts of the project. The screen itself is ncurses-based, which permits a text interface that can run without a graphical desktop. The README does not enumerate every command, pane, contact model, notification behavior, or configuration key, so those details should be checked in the user guide rather than inferred from the project description. It also does not claim support for unrelated chat networks. Profanity should be evaluated as an XMPP client, not as a protocol-neutral terminal messenger. Extension support is more concrete. The README points to a separate `profanity-plugins` repository, which indicates that functionality can extend beyond the core client. The repository also includes API documentation, theme material, and example configuration, suggesting multiple integration points. However, the README does not document plugin installation, permissions, API stability, or compatibility guarantees. Those are material adoption checks for an engineer who expects to distribute internal plugins or depend on a plugin API across releases. ## Installation and first connection through Profanity's user guide The README does not include platform-specific package commands or a self-contained first-login walkthrough. It directs users to the project's installation page and a separate guide for building from source. No commands are reproduced here because the README excerpt does not contain the exact instructions, dependencies, or flags needed to do so without invention. For a first real use, start with the official install instructions for the target operating system, then consult the user guide for creating or entering an account and establishing the initial connection. The expected prerequisite is an existing XMPP identity, typically represented by a JID, although the exact commands used by the guide are not included in the README. Users should not assume that successful installation means the client can sign in without account details. After connection, the next decision is encryption. The README confirms support for OTR, PGP, OMEMO, and OX, but it does not state which one should be selected for a particular server. The user guide and FAQ therefore need to answer three operational questions before real conversations begin: which modes the chosen server permits, which modes the contacts' clients support, and how Profanity reports an unencrypted or failed encrypted session. The issue tracker is the documented destination if the user guide does not resolve a problem. ## Encryption support requires protocol and counterpart checks The most important technical limitation is not that Profanity lacks advertised encryption mechanisms, but that the README is too thin to compare them or establish safe defaults. It mentions OTR, PGP, OMEMO, and OX in a single list. It provides no matrix of supported server versions, client interoperability, key-management procedures, attachment behavior, group-chat behavior, or fallback rules. It also does not claim that every conversation is encrypted by default. That distinction affects adoption. An organization may require one of the listed mechanisms and reject conversations that use another. A self-hosted deployment may support Profanity's intended workflow while an account on a public service exposes different capabilities. Before allowing Profanity to replace an existing messaging tool, verify encryption configuration on both ends and confirm how the interface displays security state. Treat the README as evidence that these modes exist in the project, not as a complete security procedure. The repository contains a `SECURITY.md` file, which is the logical place to begin for the project's own disclosure and security guidance, followed by the linked user guide for configuration. That is a concrete documentation boundary, not a claim that either file lacks relevant information. ## Profanity versus graphical XMPP clients Profanity's real alternative is a graphical XMPP client that runs in a desktop environment. The practical difference is the interaction model rather than the underlying protocol. Profanity keeps conversations, commands, configuration, and themes inside an ncurses interface, which fits remote shells and terminal-centered work. A graphical client can provide mouse interaction, desktop notifications, and visual contact management, although those specific graphical capabilities are not documented for a named alternative here. For scripted or remote administration, the terminal-oriented design can reduce the number of application contexts involved. For users who need rich media previews, drag-and-drop attachments, or a conventional desktop contact list, the README does not establish Profanity parity with that workflow. It also does not document headless operation or an automation interface. Engineers should select Profanity because its terminal model matches the deployment, not simply because it is lighter or more private. Irssi is the explicit design inspiration in the README, not a protocol equivalent with documented feature parity. Comparisons should therefore focus on interface preference, XMPP requirements, encryption configuration, plugin needs, and the custom license. Naming another XMPP client is useful only if the deployment team can verify the other client's support for the same server and encryption methods. ## License, releases, and the cost of adopting Profanity GitHub classifies Profanity's license as a custom license, so it should not be described as permissively or copyleft licensed without checking `LICENSE.txt`. The repository also contains `COPYING`. This review cannot summarize the permissions, conditions, or distribution obligations because the license text was not included in the repository listing. Organizations embedding, redistributing, or packaging Profanity need a direct review of those files. This is a licensing check, not legal advice. The repository is not archived, and its last push was on 2026-10-16. Release 0.19.0 was published on 2026-10-15, following 0.18.2 on 2026-06-08 and 0.18.1 on 2026-05-15. Those dates indicate recent project activity, but they do not establish API stability or compatibility for plugins. An adopter who builds against `apidocs/` or distributes plugins should review `RELEASE_GUIDE.md`, the `CHANGELOG`, and plugin documentation before each upgrade. Upgrade cost is likely higher for teams that automate configuration or depend on plugins, although the repository does not provide migration measurements. Keep the configuration, themes, plugin selection, and target XMPP server requirements under version control where permitted. Validate those components against the release notes rather than assuming every interface or extension API remains unchanged. ## Conclusion Profanity is a practical choice for terminal users who already use XMPP, value plugins, or need a server-based messaging setup. It is a poor fit for users expecting a graphical application or assuming that every advertised encryption option provides identical coverage. Before adoption, check the LICENSE.txt terms for the intended deployment, confirm that the server and contacts support the required encryption method, and follow the official install guide for the target platform. ## FAQ ### Does Profanity provide an XMPP account and server? No. Profanity is an XMPP client, so users need access to an existing XMPP account or server before they can chat. The README does not document account registration or server provisioning. ### Which encryption options does Profanity support? The README lists OTR, PGP, OMEMO, and OX. It does not compare their configuration requirements, server compatibility, or fallback behavior. ### Can Profanity be extended with plugins? Yes. The README links to a separate `profanity-plugins` repository, and the main repository includes `apidocs/`. The README does not document plugin installation or API compatibility guarantees. ## Sources - [Issues](https://github.com/profanity-im/profanity/issues) - [profanity-im/profanity on GitHub](https://github.com/profanity-im/profanity) - [Project website](https://profanity-im.github.io/) - [README](https://github.com/profanity-im/profanity/blob/master/README.md) - [Releases](https://github.com/profanity-im/profanity/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/profanity-im-profanity