Zerta 2026-08-24 High-performance XMPP server written in Go Zerta is a production-grade XMPP server forked from ortuman/jackal. It supports SASL2, Bind2, FAST, MAM, MUC, HTTP File Upload, Push Notifications and clustering; the supported extensions are listed below. Alexander Renz Go Linux 0.7.0 2026-09-22 complete 2.13.2 complete 2.0 complete 1.7 complete 2.5.0 complete 1.35.5 complete 1.2 complete 1.2 complete 1.3.0 complete 1.3.0 complete 1.3 complete 1.0 complete 1.30.0 Core node lifecycle (create, delete, configure), subscribe/unsubscribe, publish, retract, items retrieval, pubsub#owner purge and affiliations management are all implemented. Primary use is PEP (XEP-0163) and MUC/Push backends. complete 1.8.2 complete 2.4 complete 1.1.5 complete 2.1 complete 1.1 complete 1.6 complete 1.6.0 partial 1.3.1 Four of the XEP-0133 admin commands are implemented: get-registered-users-num, get-online-users-num, get-registered-users-list, and delete-user. complete 1.1.1 complete 1.4.0 complete 1.1.1 partial 1.0.1 CAPTCHA data-form challenge (XEP-0158) is used for in-band registration (XEP-0077) only, with an image OCR challenge; disabled by default (ibr.captcha.enabled). complete 1.0.1 Offline storage of type='normal' (and untyped) messages and body-carrying type='chat' messages, stamped with delayed delivery and delivered on available presence; honours XEP-0334 no-store/no-copy/store, advertises msgoffline, and does not store headline, groupchat or error messages (XEP-0160 §3). partial 1.2.2 PEP is served by the embedded PubSub implementation: notifications are fanned out to roster contacts whose subscription is from or both, the last published item is delivered on login and on available presence, and node options (access model, persistence, item count) are set through publish-options. Contacts outside the owner's roster receive PEP events only after an explicit subscription. complete 1.2 complete 1.4.0 complete 1.3 complete 1.6.3 complete 2.0.1 complete 2.0 complete 1.0.0 Advertises operator-configured STUN/TURN services and generates time-limited HMAC credentials from a shared secret. XEP-0215 is discovery-only — the spec does not require the XMPP server to operate its own TURN/STUN server. complete 1.1.1 Inbound and outbound db:result/db:verify flow for s2s, including dialback error packets (db:result/db:verify type='error' carrying stanza error conditions, advertised via <errors/>) and sender multiplexing (several sender domains per stream). complete 1.1.1 PEP nodes support access_model=whitelist, persist_items and max_items=1 via publish-options (XEP-0060 config). complete 1.1 Inlines the IBR CAPTCHA image as a <data/> element and serves cached data back over IQ-get (advertises urn:xmpp:bob; unknown cid yields item-not-found). complete 1.2 complete 0.2 complete 1.0.1 complete 0.12.0 complete 1.2.1 complete 1.1.3 complete 0.2.1 Preparation follows RFC 7622 literally, including allowing '@' in the resourcepart (§3.4). complete 1.0.0 complete 1.0.0 complete 0.8.0 complete 0.4.1 complete 0.7.0 complete 1.2.0 complete 1.1.0 Direct TLS listeners for c2s and s2s (direct_tls) with ALPN negotiation (xmpp-client/xmpp-server); the _xmpps-client endpoint is also advertised via XEP-0156 host-meta. partial 0.14.6 Deliberately partial: channel core exists for the SQL backends only (pgsql, mysql) and the BoltDB backend returns not-implemented for all ten MIX operations; channel history is stored but not wired into the join flow; XEP-0405 (MIX-PAM) is not implemented, so urn:xmpp:mix:pam:2 is not advertised; and MUC (XEP-0045) is the supported group chat path, not MIX. partial 0.4.1 Spam reports are persisted (Postgres/MySQL/BoltDB) and survive restarts; each report fires a SpamReportReceived hook. At 3 distinct reporters the reported JID is automatically added to the antispam blocklist. No report-forwarding/moderation queue yet. complete 0.4.0 complete 1.1.0 Resource binding happens inline inside SASL2 (XEP-0388) and accepts both the final namespace urn:xmpp:bind:2 and the draft urn:xmpp:bind:0 still used by older clients; the client-supplied tag is applied to the resource. Stream Management and Message Carbons can be enabled inline within the bind element. Clients that do not use SASL2 are bound through the classic bind feature, which is outside the scope of Bind2. complete 1.0.4 SASL2 is offered on the client stream with SCRAM-SHA-256 and SCRAM-SHA-512 including their channel-binding variants, inline Bind2 (XEP-0386) with Stream Management and Carbons, FAST (XEP-0484) and SCRAM upgrade tasks (XEP-0480), and the user-agent element. Non-standard X-* mechanisms remain available through SASL1 only and are therefore not usable through SASL2. complete 1.0.1 complete 0.3.0 complete 0.1.1 complete 1.0.0 complete 0.6.0 partial 1.2.0 The PEP bookmarks node urn:xmpp:bookmarks:1 is served and kept in sync with the legacy storage:bookmarks view for conference bookmarks, so legacy and modern clients see the same conference list. URL bookmarks are not converted: XEP-0402 dropped URL storage as out of scope (§1), so the native node holds only <conference> items and legacy XEP-0048 <url> bookmarks are not bridged. complete 1.1.0 complete 1.1.0 complete 1.0.1 complete 0.5.0 complete 0.3.0 complete 0.2.0 Case-insensitive substring match on PostgreSQL and BoltDB; word-based FULLTEXT match on MySQL/MariaDB (minimum token length and stopwords apply). On SQL backends, messages archived before the body column existed are not searchable. complete 0.1.0 complete 1.0.0 complete 0.2.0 Extended MAM filter fields (before-id/after-id/ids), XEP-0431 full-text, and archive prefs IQ (default/always/never with JID rules) are implemented. complete 0.2.1 complete 0.1.2 complete 0.2.1 complete 0.5.0 complete 0.2.0 complete 0.1.0 partial 0.2.0 FAST is offered inline inside SASL2 with the HT-SHA-256-NONE mechanism only (no channel-binding variants such as HT-SHA-256-ENDP/EXPR). The requested mechanism is validated against the advertised set. Issued tokens are stored per device identity in two rotation slots (current and new) with an expiry, and are encrypted at rest only when a key is configured. Supported on PostgreSQL, MySQL and BoltDB; bbolt's single-writer transaction provides the compare-and-swap semantics PromoteFastToken needs. Client-initiated token invalidation (the 'invalidate' attribute on <fast/>) deletes the authenticating device's token slots (XEP-0484 §3.6). complete 1.0.0 complete 0.1.0 complete 0.1.0 complete 1.1.0