ADAMANT Messenger: a decentralized messenger that is also a wallet

One codebase, four targets, and a passphrase that cannot be recovered

ADAMANT Messenger is an open-source decentralized messenger and non-custodial wallet built on the ADAMANT blockchain, and this repository contains the main client for web, Tor, Android through Capacitor, and desktop through Electron.

That packaging matrix is the first thing to understand, because it dictates everything about the build. The four targets share a single TypeScript codebase under src/ and differ by the tooling wrapped around it. The project ships a progressive web app for the public web, a Tor build for users who need stronger network anonymity, an Electron desktop app for macOS, Windows and Linux, and a Capacitor Android app. The homepage is adm.im.

The account model is what makes it unusual. Accounts do not require phone numbers or emails, private keys stay on the user side, and the client can work with distributed nodes instead of a single provider. The listed reasons for ADAMANT are no phone numbers, no emails, no contact-book scraping by default, and end-to-end encrypted messaging using Diffie-Hellman Curve25519, Salsa20, Poly1305, SHA-256 and Ed25519.

The warning at the top of the README deserves to be read as the most important line in the document. Your ADAMANT passphrase cannot be recovered by developers, support, or infrastructure operators. Store it offline and treat it like a wallet seed phrase. That is a direct consequence of the non-custodial design, and it is also the difference between this and every other messenger account that a support desk can reset.

The npm scripts show the whole build matrix in one place

The package.json scripts are the clearest map of the project, and they are worth reading as documentation of the four target modes.

The base command is npm run dev, which runs vite against vite-pwa.config.ts. The PWA config is the default, and there are separate variants for other environments: dev:tor for the Tor build, dev:testnet for the testnet, and dev:localnet which additionally binds to 0.0.0.0 for use inside a container or a local network. The serve scripts are the preview equivalents, with serve, serve:https and serve:testnet.

  "scripts": {
    "serve": "vite preview --config vite-pwa.config.ts",
    "serve:https": "vite preview --https --config vite-pwa.config.ts",
    "serve:testnet": "vite preview --config vite-pwa.config.ts --mode testnet",

Every build goes through vue-tsc before vite build, so the type check is part of the build rather than a separate lint step you might forget. The build:tor and build:testnet variants differ from the default build only by mode, which is what makes the environment switch cheap.

The tooling requirements are strict and stated in the same file. The package manager is [email protected], and the engines field requires node >=24.15.0 and npm >=12. The repository also carries a.nvmrc and a.sdkmanrc for the same reason.

Note the framework choice. The type check is vue-tsc and the entry points are Vue-flavoured Vite configs, with vite-base.config.ts, vite-android.config.ts and vite-pwa.config.ts sharing a vite-config/ directory.

The wallet layer is generated from an OpenAPI specification

Inside a messenger, the crypto wallet is the part that usually rots, because every token list and every chain changes shape faster than the app can be updated by hand. This repository handles that with code generation.

There is an adamant-wallets directory at the root holding a specification, and the scripts drive a generator over it. The wallets:data:generate script runs a Node script called scripts/wallets.mjs, the types generator runs swagger-typescript-api against./adamant-wallets/specification/openapi.json to produce TypeScript types, and there is a check mode, wallets:data:check, which runs the same script with a --check flag.

That check mode is the interesting part. A generator that can verify the checked-in output is different from a generator you have to trust, and the presence of both suggests the wallet data is treated as something that must be reproducible rather than as a manual file.

The top-level script that chains them, wallets:generate, runs the data generation and then the types generation in sequence. The generated types are written into./src/types/wallets/index.ts, and the pipeline formats the result with prettier afterwards so the output matches the repository's style rules and produces no diff noise.

The openapitools.json file at the root points at the same OpenAPI-driven approach for the API surface. So the wallet and the node API contract are both described as machine-readable specifications in the repository, which is the pattern you would want to copy if you are building a client against an API that changes.

Self-hosting is a supported path, and the public deployments are listed in the README

The self-hosting story is unusually well documented for a project like this, and the reason is stated plainly. If you are unable to access adm.im, for example because of censorship, you can run a self-hosted instance of the messenger, and doing so increases the reliability and decentralization of the ecosystem and helps other users reach the messenger in countries with strong internet limitations.

The README then lists every community deployment it knows about, which is a useful map of the network. The mainnet app is served from GitHub Pages at adamant-im.github.io, built from master only because of GitHub Pages limitations, and from Vercel at msg2.adamant.im, and from server-side builds at msg.adamant.im and adm.im. The dev branch has its own server-side build at msgtest.adamant.im and its own Vercel deployment at dev.adamant.im. There are two Tor auto-builds, one from master and one from dev, given as onion addresses. There is a Massa DeWeb build deployed manually with the Massa DeWeb workflow. The testnet app is built in Surge at msg-adamant-testnet.surge.sh and dev-adamant-testnet.surge.sh, each mirrored at an HTTP-only address.

The build-from-source route is documented too, and it ends with a warning that any user can configure GitHub Actions auto-build for their own master deployment. The steps are to fork the repository, go to Settings, open the Pages tab, and set the source as GitHub Actions, then run the GitHub Pages workflow from the Actions tab.

For a project whose value proposition is that a single provider cannot censor it, having the README enumerate its own mirrors is the point rather than a leak.

What else is in the box: wallets, exchanges, IPFS and an AI chat

The feature list goes past messaging in ways that matter for anyone evaluating the client.

There are built-in wallets for ADM, BTC, ETH, DOGE, DASH, USDT, USDC and ERC20 tokens, and in-chat transfers, exchanger flows, and Adelina AI chat integration. Attachments and media use IPFS-based file sharing, and encrypted chats come with blockchain-backed message ordering and authenticity, which is a different guarantee from a server ordering messages by timestamp.

The network layer is where the decentralization claim gets tested. Custom node configuration with health checks and failover is a listed feature, and the multi-node architecture with failover, self-hostability and Tor-friendly deployment options is one of the reasons to use ADAMANT in the first place. The client-side list of nodes is what determines which servers see your traffic, so a self-hosted deployment that points at its own node is a distinctly different privacy posture from the default.

The README also points at the official resources. The website is adamant.im, there is a documentation site at docs.adamant.im, a whitepaper PDF, GitHub Releases, a downloadable media pack, and a project profile document. The repository itself is GPL-3.0-only according to the package metadata, and the licence file sits at the root next to CONTRIBUTING.md, AGENTS.md and DEPENDENCY_SECURITY.md.

The engineering surface: Electron, Capacitor, Cypress, Playwright and a lot of config

The top-level file list explains what a project that targets four platforms has to carry, and it is a long list of build and test configuration.

For the desktop side there is electron-vite.config.ts and two electron-builder files, electron-builder.yml and electron-builder.arm64.yml, plus electron-builder.env.example. For mobile there is capacitor.config.ts, capacitor.env.example and a separate capacitor/ directory, with a vite-android.config.ts. The build output goes to output/, and deploy/ holds deployment helpers alongside a deploy.sh at the root.

The testing picture is broad. There is cypress.json and a Playwright configuration, plus vitest.config.ts and a tests/ directory. The app is a Vue project with a full linting and formatting stack: eslint.config.ts, .prettierrc.json, commitlint.config.ts, a .husky/ directory for git hooks, and .editorconfig.

A few smaller files are worth noticing because they show where the project is going. There is an api/ directory, an openapitools.json, a .browserslistrc, a .env file checked in alongside capacitor.env.example and electron-builder.env.example, and a .gitmodules, which means part of the project is pulled in as a submodule.

The AGENTS.md file at the root is a recent addition of a kind that shows up in active repositories, and DEPENDENCY_SECURITY.md records the project's stance on dependency updates.

Maintenance, licence and the practical limits of the model

The maintenance facts are healthy. The last push to the repository was on 2026-10-19, the default branch is dev, and the release list shows v4.12.0 published on 2026-08-11, v4.11.1 on 2026-03-22 and v4.11.0 on 2026-03-19. The project is not archived, and the commits activity badge points at the gh-pages branch, which hosts the commit data behind the badge.

The licence is GPL-3.0-only, and the package is marked private, so it is not published to npm for general consumption. It is a repository you clone and build, and the README says the project always encourages people to build it from source by following the development setup in CONTRIBUTING.md.

There are real limits to what this design buys you, and they are worth naming. Decentralization here means your client can talk to a set of nodes you choose, and it does not mean the network is a single global authority. The blockchain provides message ordering and authenticity, not anonymity by itself. The Tor build exists because the web build is not anonymous enough for some users. And the passphrase model, which is the strongest privacy property in the system, is also the weakest operational one, because there is no recovery path at all.

None of that makes the project wrong for its users. It makes it a specific tool for people who have already decided that non-custodial keys and a censorship-resistant account model are worth the operational cost of holding a seed phrase and running or choosing nodes themselves.

Editorial conclusion

Adopt this repository if you are building a privacy-oriented progressive web app and want a working reference for multi-target builds, PWA configuration, Electron packaging and a generated wallet layer, or if you want to run your own instance of the messenger because the public one is blocked where you are. Do not adopt it as a starting point for a small team project, since the surface area spans four target platforms, a blockchain node, a token specification generator and a security model you cannot weaken. Before you deploy anything, read the passphrase warning and treat the seed phrase accordingly, and check that the node list you configure is one you trust, since the client and the network are the same code.

Frequently asked questions

Official sources

1. Adamant-im/adamant-im on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases