- Published on
The Libraries Behind Open Communication
Most users experience nostr through apps for social media, live streaming, and secure messaging, among other uses. Underneath each one sits a stack of code that handles the nostr protocol itself, generating keys, signing events, connecting to relays, parsing event kinds, and delivering a consistent experience across a network of independently run relays.
The protocol remains simple by design, and much of the work for building on nostr lives one layer up in developer libraries that package the recurring parts of app development. These libraries let new projects spend less time rebuilding the same infrastructure and more time shaping the experience they want to offer.
As nostr matures, the surface area each library has to cover continues to expand. New NIPs introduce features like voice messages, picture-first posts, bookmarks, polls, calendar events, ecash wallets, private messages, and group chat over Messaging Layer Security. Better defaults, such as the outbox model, change how clients choose relays. Private messaging has also moved toward newer encryption formats, and libraries are where those updates reach the apps built on top of them. When a library keeps current with the protocol or makes advancements, the apps using it have a clear path to do the same.
Through The Nostr Fund, OpenSats has supported maintainers working on developer libraries in the languages nostr builders already use. This report highlights work spanning TypeScript, Rust, Apple platforms, Android and Kotlin Multiplatform, Flutter, Dart, PHP, and Ruby. Together, these projects form part of the shared toolkit layer that nostr apps, services, and integrations build on.
The nostr library initiatives highlighted in this impact report are:
- Applesauce
- NDK (incl. NDKSwift & Dart NDK)
- rust-nostr
- nostr-php
- nostr-ruby
- Quartz
Each section looks at how these libraries evolved over the past year and how donor funding supported work that compounds across the broader nostr ecosystem.
Applesauce
Applesauce is a TypeScript framework that gives developers building nostr apps a ready-made set of building blocks. A new nostr client project has to solve the same recurring challenges before it's able to do anything meaningful: reading events from relays, managing connections, signing messages, and storing data locally. Applesauce packages common solutions to those needs, giving developers a more direct path from protocol plumbing to user-facing products. With OpenSats' support, which followed earlier funding for hzrd149's broader nostr work, development over the past year focused on making nostr data easier to work with, expanding storage and signing options, improving relay behavior, and covering more of the protocol features developers expect.
One practical improvement came from a new event casting system, which was formalized and expanded in the v6 release. Events arriving from relays are generic data blobs that each app has to interpret before it can display them or act on them. The casting system turns those generic events into clearly labeled, ready-to-use objects for the things developers actually want to handle, such as a note, profile, zap, or comment, and makes it easier for user interfaces to read relationships between events with less custom code. The same release also reworked how events are created and modified. Earlier versions required apps to set up a central EventFactory object to manage all the different events, while v6 added dedicated event factories for common event types, including notes, profiles, zaps, reactions, and comments.
Around the same time, hzrd149 published a separate set of tools for AI coding agents, including an MCP server that lets coding assistants run live semantic search over Applesauce documentation and code examples, and an installable agent skill that gives compatible agents Applesauce-specific context and workflow guidance. When a developer asks an AI assistant for help building with Applesauce, the assistant can pull from real documentation and examples, with the source code available for anyone who wants to run their own copy of the MCP server locally. The documentation at Applesauce's website was also reorganized by topic, and new example apps were added as features shipped, giving both human developers and coding agents clearer working examples to build on. The same release cycle also added a simpler way for apps to subscribe to live updates and introduced caching for private messages, so apps that handle encrypted nostr DMs can avoid asking the user to decrypt the same message repeatedly.
The relay layer received deeper structural work, which matters because relay choice is part of how nostr preserves user control. A new outbox model lets a client read the relay preferences each followed user has published and connect to the right places, aligning Applesauce with the broader push toward user-selected relays. A separate change added dynamic relay groups, so an app can switch between different sets of relays without rebuilding its connection layer. The applesauce-relay@1.0.0 release added support for Negentropy, a sync method that lets an app catch up on events it missed without downloading everything from scratch, with multi-relay sync expanded in later releases. Alongside this, the applesauce-actions package gives developers pre-built actions for common operations such as updating relay lists, follow sets, and mute lists.
Every time a new feature is added or something is reworked, I try to add an example app to the documentation site demonstrating how to use the new feature. I've found these examples really help coding agents on other projects understand how to implement common things on nostr since it provides them a shortcut. Without these example apps, agents need to read the documents, find the relevant code, and reason through how a login page should be built. But with the examples, the agents can copy the already working login view and then modify it as they see fit.
–hzrd149, Applesauce creator and maintainer
Storage and protocol coverage expanded as well. New async storage interfaces and multiple SQLite backends give developers more flexibility in how their apps save data locally. An Android native signer and account opened the framework to mobile developers building Android apps. On the protocol side, Applesauce added support across encrypted direct messages, long-form articles, nostr groups and chat, calendar events, live streams, polls, and the Cashu ecash family of specs covering nostr-native wallets, nutzaps, and mint discovery. That ecash work brings payments and wallet functionality into the same framework that already handles social events, giving developers a more consistent path for clients that combine social features and payments.
Applesauce closes the period with a v6 release line that brought these capabilities together across the package. OpenSats' support helped improve a library that other nostr builders can use directly, and those improvements can carry into the clients (Dear Nostr, noStrudel, Nostube), tools (Relatr), and experiments built on top of it.
NDK
NDK, the Nostr Development Kit, is a high-level software development toolkit for the nostr ecosystem. Before a user ever sees a post, a nostr app has to connect to relays, sign and verify messages, parse events, store data so the UX is fast, and keep up with the protocol specs nostr is built on. NDK handles much of that work so app developers can focus on the product experience. This section covers a year of work across three related implementations of the same design: the original TypeScript NDK, the Apple-platform NDKSwift, and Dart NDK for Flutter and Dart developers.
NDK was originally created by pablof7z for web and JavaScript-based apps, and its design has since been carried onto other platforms. Pablo brought the same patterns into NDKSwift for Apple-platform apps written in Swift. He has also been building NMP, a separate Rust framework that takes a different approach to the same cross-platform problem, putting the relay connections, signing, and message handling in one Rust core while each platform's app handles only the interface. A separate team of grantees led by frnandu, Leo, and Nogringo built Dart NDK to give Flutter developers a comparable toolkit. With OpenSats' support for Pablo's NDK and NDKSwift work, and a separate grant for Dart NDK, the past year produced major version work on the TypeScript side, an architectural rewrite on the Swift side, and growing adoption in Flutter and Dart.
On the TypeScript side, NDK reached its v3.0 release in November 2025, a major architecture update touching subscriptions, relay connections, cache layers, performance, and a developer-facing API. One distinctive addition is a set of AI Guardrails. As more developers use AI coding assistants to build nostr apps, those assistants can produce code that looks plausible while using NDK in unsafe or inefficient ways, such as blocking on relay responses, generating malformed events, or skipping the performance features NDK already provides. The guardrails are runtime checks that catch those patterns when they happen, and the error messages explain what went wrong and how to fix it. Whether code was written by a human or generated by an LLM, issues are detected earlier, and a clearer path to correction is provided.
Around the v3.0 work, performance improvements added a fast path for events the toolkit has already seen, so it avoids redoing expensive parsing the second time around. Further fixes improved remote-signer behavior, including a bug in the nostrconnect flow that could confuse a remote signer's pubkey with the actual user's. Pablo also published companion packages for higher-level encrypted direct messaging, Negentropy-based sync, web-of-trust filtering and sorting, and lightweight multi-account session management, with the latter three appearing as part of the broader v3.0 package work. On the framework-adapter side, the Svelte integration was rebuilt for Svelte 5 as a registry of components that developers copy into their own codebases, letting each piece, such as mentions, link previews, media handlers, and content rendering, be customized locally. NDK Kotlin is also in early development, positioning the NDK family to eventually cover Android the same way it now covers the web and Apple platforms.
For Apple-platform developers, NDKSwift went through a parallel transformation. The package was split into separate modules so an app that only needs part of the toolkit can depend on a smaller surface area, and the codebase was migrated to Swift 6 with the safety conformance required by its stricter concurrency model. A new connection-reliability subsystem gave Apple-platform apps clearer handling for dropped connections, network changes, health checks, and lifecycle management. A companion Relay Intelligence Layer helps apps make better decisions about which relays to use for outbox-style publishing. The protocol stack on NDKSwift now covers Cashu wallets and nutzaps, gift-wrapped messages, encrypted direct messages, Nostr Wallet Connect, Lightning zaps, the outbox model, and Negentropy sync. Together, those pieces give Apple developers a maintained path through several of the hardest parts of building a full nostr client.
NDKSwift also gained a dedicated SwiftUI module, NDKSwiftUI, packaged with ready-to-use building blocks for profile pictures, rich text, Markdown rendering, and image caching. Alongside the library, Pablo built Chirp, a reference iOS nostr client that lives in the NDKSwift repository. Chirp is source-available as a reference app, and its purpose is to show developers how a real SwiftUI nostr client built on NDKSwift looks end-to-end. One of its pieces is an embeddable kind registry, which lets an app render different kinds of nostr content, including notes, long-form articles, and highlights, with the right component for each kind. A rewrite of the Olas iOS client on top of NDKSwift is also in progress, demonstrating how a production app can be built using the modular pieces NDKSwift provides.
For Flutter and Dart developers, Dart NDK, built by frnandu, Leo, and Nogringo, had a significant year of its own. Its design gives developers high-level use cases for common nostr tasks, such as lists and metadata, while still allowing lower-level relay queries when an app needs them. Inbox and outbox gossip are built into that flow by default, helping applications make better relay choices without requiring every Flutter developer to understand the details of relay selection. Checking whether a nostr message is authentic is also one of the most CPU-heavy things a nostr app does, and the team made that work faster and less disruptive for mobile apps. A Rust-backed verifier handles verification in native code, while a separate change moves signature checks off the screen-rendering thread so a Flutter app can keep scrolling smoothly while it catches up on a backlog of events. Additional work extended that same off-thread treatment to other heavy operations, and a web-targeted verifier covers environments where native code is unavailable. The project also added remote-signer support over NIP-46, gift-wrap encryption, and a search use case.
Structurally, Dart NDK provides a separate Flutter package so non-Flutter Dart projects can depend on the core software development kit without taking on visual components. Its separated architecture also lets developers swap out major components, including storage, signing, and verification. The library now ships with multiple database options, multiple signers and verifiers, and support for remote signers, giving app builders more room to choose the tradeoffs that fit their environment. It also gained a persistent cache layer and shipped a new command-line tool for querying nostr relays directly and providing easy access for agents.
Wallet development created a unified interface for Cashu, Nostr Wallet Connect, and LNURL, building on the earlier work that combined wallets into one interface. Common wallet actions, such as transactions, sending, and receiving, can use one API, while specialized wallet operations remain available where needed. A Cashu wallet, for example, may need to restore parameters such as mints, currencies, or nostr-based recovery data that do not belong in a generic wallet interface. Keeping those details in specialized APIs lets the common wallet flow stay simple while preserving the deeper controls each wallet type needs. Reusable Flutter widgets for wallet connection and interaction were added alongside the underlying library.
Dart NDK also added support for Trusted Assertions, which lets applications use a configured trust provider for statistics and trust values, then cache and store those values for offline use. Blossom support follows Dart NDK's broader same high-level/direct-access pattern. Most applications can use the high-level files use case, which checks downloads and upload files, while automatically handling Blossom URLs. Applications that need more control over blob operations can use the dedicated Blossom interface directly. Together with offline storage, these additions move Dart NDK closer to a complete toolkit for Flutter apps built on nostr.
The goal of [Dart] NDK is to make it easy for developers familiar with Firebase or Supabase to switch to nostr—no NIP knowledge required.
–Leo, Dart NDK maintainer
Dart NDK is available on pub.dev and in active use across a growing set of downstream apps, including Camelus, YANA, Zapstore, Freeflow, Hostr, Zapstream, Bitblik, Donow, and Submarine. In early 2026, Nogringo, himself an OpenSats grantee for a different nostr project, joined as a regular core contributor, putting three active maintainers behind the library with weekly coordination calls. The team also published an experimental post-quantum signature demo to encourage ecosystem discussion about what nostr might need if quantum-resistant cryptography becomes a practical concern.
Together, OpenSats' support for NDK, NDKSwift, and Dart NDK helped extend a common development approach across web, Apple, and Flutter/Dart apps, giving more nostr builders maintained tools in the environments they already use.
rust-nostr
rust-nostr is a Rust implementation of the nostr protocol, with higher-level tooling for building apps on top of it. The project includes a software development kit that handles signing events and managing relay connections, a client for Nostr Wallet Connect so apps can request Lightning payments through a user's wallet, a custom relay framework, multiple signer integrations, and bindings for Python, Kotlin, Swift, JavaScript, Flutter, React Native, and .NET.
That reach makes rust-nostr a shared foundation for a growing number of apps and tools across the ecosystem, including the Damus Notedeck desktop client, Primal's Blossom media server, the White Noise secure messaging app built on Messaging Layer Security, the Mostro peer-to-peer bitcoin exchange that runs over Lightning and nostr, ngit for code collaboration over nostr, and the Nostr VPN mesh networking project. With OpenSats' support through both the original project grant and an LTS grant, Yuki Kishimoto has spent the past year keeping the library up-to-date with the nostr protocol, strengthening the parts downstream apps depend on most, and widening the set of platforms and languages the project can serve.
On the protocol side, released versions across the year added typed support for polls, voice messages, chats, threads, bookmarks, hold invoices in Nostr Wallet Connect, and the Cashu wallet kinds that let nostr clients hold ecash directly. Additional work targeted for upcoming releases adds highlights and further refinements to the right-to-vanish flow that lets users ask the network to forget them.
Beyond the protocol, the relay framework and relay pool went through substantial reworking. nostr-relay-builder was developed into a tool an operator can use to spin up a custom relay with control over what it accepts and serves. Yuki added authenticated handling of direct messages and gift-wrapped events, protected events so authors can mark a post as accepted only when published by them, and multi-filter request handling so a single subscription can ask for several kinds of content at once. The policy system itself was reorganized so that read and write rules are clearly separated, making it cleaner to decide what a relay stores and what it returns. The relay pool added a Monitor for connection status and stats in real time, the ability to put idle relays to sleep so apps use less power and bandwidth in the background, and a more reliable event stream for subscriptions that span many relays.
One major focus this past year was gossip, the part of a nostr client that figures out which relays a user actually publishes to, so the client can read from the right places. Gossip used to be an experimental option inside the software development kit, and during the past year, it became its own subsystem with a dedicated nostr-gossip crate that defines how gossip storage works, an in-memory backend, and a separate SQLite-backed storage crate so apps can remember what they have learned about who publishes where between sessions. The toolkit side gained efficiency improvements that fetch user lists only when needed, filtering for which relays are considered during selection, better concurrency through per-key locks, and a background refresher that keeps gossip data up-to-date automatically. The effect for downstream apps is practical: a client built on rust-nostr can follow a user's published relay choices with less custom relay-selection code.
Relay selection is one of the key parts of Nostr decentralization. Without practical gossip support, we tend to converge around a small set of large relays. By making gossip easier to use at the SDK level, rust-nostr helps applications find where users actually publish and read, making relay usage more distributed.
–Yuki Kishimoto, rust-nostr creator and maintainer
The past year also saw the library reach more developers, platforms, and programming languages through work on signing and the wrappers that bridge Rust to other environments. The code that lets a web app sign nostr events through a browser extension was moved into its own dedicated library, separating web signing from the mobile and desktop versions. A new browser signer proxy, extended and refined in follow-up work, enables a native desktop application to use that same signer through a local bridge, so users can keep one trusted key across web and native apps. On the bindings side, the .NET wrapper received support for Android and iOS runtimes, Kotlin Multiplatform bindings allow apps written for Android, iOS, and desktop to share the same nostr code, and the Python packages expanded to cover more chip architectures. Yuki also built android-signer, a set of libraries that let apps written in languages other than Java and Kotlin connect to Android-based nostr signers, opening on-device signing on Android to apps written in Rust, Flutter, and React Native.
After a year of work, rust-nostr moved closer to its beta milestone, with v0.44.0 tagged in November 2025 and further work on the master branch for upcoming releases. OpenSats' support helped Yuki keep rust-nostr current with the protocol while making it more useful across languages and platforms. That work matters because downstream teams can adopt better relay handling, signing, wallet, and protocol support without rebuilding those pieces themselves.
nostr-php
nostr-php is a PHP helper library for nostr, giving developers a toolkit for adding nostr features to PHP-based websites and services. PHP still powers a large share of the public web, so a maintained PHP library keeps nostr accessible to developers already working in that environment. With OpenSats' support, Sebastix has spent the past year adding protocol coverage with significant contributions from an active community of developers building on the library.
Encrypted messaging was the clearest area of progress this year. Earlier in the reporting period, PHP applications lacked support for private nostr messages using the protocol's current standards. That gap was filled across a series of releases that added encrypted direct messages and modern versioned encryption, the underlying primitive other private-messaging specs built on, with follow-up encryption fixes validated against real test vectors so the implementation behaves as other clients expect. The library also got support for resolving human-readable nostr identifiers, the name@domain.tld format that lets a user be addressed without a long public key, and a full implementation of private direct messages, including chat messages, file messages, and the related gift-wrapped envelopes that hide the sender and message contents from relays while improving metadata privacy.
Most of this encryption-stack work was contributed by Djuri Baars, a developer who has become a frequent contributor to nostr-php itself and who has separately built a complete Nostr Wallet Connect implementation for PHP on top of the library. That contribution path shows the value of funding shared infrastructure: one maintained library gives other developers a place to contribute, extend, and build related tools.
The library also gained proof-of-work support. PHP applications can now attach proof-of-work to a nostr event or verify it on incoming events, something relays and clients can use to filter spam. This work shipped in version 1.9.0, following the encrypted messaging stack that arrived in earlier releases.
Relay handling improved across the v1.9 release line. PHP applications can now read a user's published list of preferred read and write relays directly from nostr, which lets a client follow each user's relay choices instead of relying on a fixed list. A new persistent connection class keeps a relay's WebSocket connection open across multiple operations rather than reconnecting for each one, and extra profile metadata fields let user profiles carry richer information. Ergonomics and reliability work continued with stronger relay-set behavior and configurable request timeouts, which shipped in the latest GitHub release at the time of writing, version 1.9.4, in February 2026.
'PHP is dead' is an often heard statement about the programming language. Reality is that the majority of the web is still running on this technology. With the development of this library, I'm able to bring PHP back in sight among other nostr developer.
–Sebastix, nostr-php maintainer
The companion documentation site at nostr-php.dev grew alongside the library to give adopting developers a clearer reference, with new and updated pages covering private direct messages, tag management, getting-started instructions for trying the library in a browser, profile bootstrapping, and an in-progress NIP-19 guide. The documentation is also deployed on nostr as an nsite, where gateways serve the site from its nostr public key, including mirrors at nsite.lol and nostro.re, among other mirrors. A PHP library teaching its own users how to build on a censorship-resistant protocol by hosting its documentation on that protocol reflects the same principle that the library serves. As of May 2026, the library had been installed more than 28,000 times through Packagist, PHP's primary package registry.
PHP developers now have a library they can use to build a wider range of nostr features, with the encrypted messaging stack closing the most apparent gap. The roadmap continues to track several features PHP developers will likely need next, including Nostr Wallet Connect for Lightning payments through nostr, already partially addressed by Djuri's separate library, remote signing so a PHP application can sign events on behalf of a user without holding the user's private key, and event counts and search capability for richer queries. Handling asynchronous and concurrent requests, a long-standing difficulty in PHP's request-response model, has already received dedicated research and a documented working approach during the past year.
nostr-ruby
nostr-ruby is a Ruby library for nostr, distributed as the nostr_ruby gem. It gives Ruby developers the building blocks for working with the protocol: generating and managing keys, signing and validating events, encoding and decoding the bech32 identifier formats nostr uses, and connecting to relays. Ruby is widely used for web applications, internal tools, and scripting, especially in the Rails community, so a maintained Ruby library keeps the door open for developers who want to add nostr functionality to a service, automation, or backend system.
With OpenSats' support, the library creator and maintainer daniele has been working on nostr_ruby over a multi-year arc, with the v0.3.1 release representing the current state of the library. A large portion of recent development work has been focused on rebuilding the client and relay interface layer with relay subscription and query support. The v0.3 architecture gave Ruby applications a cleaner way to connect to relays, send events, subscribe to filters, and process incoming responses, which is the foundation that everything else in a nostr client builds on.
The past year's work also focused on keeping the gem compatible with the surrounding Ruby ecosystem as it moved forward. Version 0.3.1 shipped in November 2025 as a maintenance release, relaxing gem dependency constraints so the gem composes cleanly with newer versions of the libraries it depends on. The release also produced a smaller gem package that ships only the files developers need, removed an unused require that no longer served the gem, and added a justfile for build and release tasks. Libraries that other developers rely on need to keep working as the dependency landscape shifts around them, and v0.3.1 helped keep the v0.3 line usable and maintainable in modern Ruby projects.
The roadmap continues to track the library's most significant open gap: it still uses NIP-04 for encrypted direct messages, the older encryption format the broader ecosystem is phasing out in favor of NIP-44 versioned encryption and the NIP-17 private direct message format that builds on it. daniele has flagged NIP-44 as planned future work, which would bring Ruby applications onto the encrypted messaging stack that the rest of the ecosystem is converging on.
Through OpenSats' support, daniele kept nostr_ruby maintained through the past year, improving compatibility, tightening the package, and keeping the gem usable as Ruby's dependency landscape moved forward. With that foundation in place, nostr remains accessible to Ruby developers who want to build applications, tooling, or integrations in the language.
Quartz
Quartz is a cross-platform Kotlin library that gives developers a ready-to-use set of nostr building blocks, including primitives for handling events, signer integrations, NIP support, event builders, and storage infrastructure. It began as an internal module of Amethyst, a popular Android nostr client built by Vitor Pamplona, before being pulled out into its own publicly available software development kit. Quartz gives Kotlin developers a shared place for protocol work that many apps would otherwise need to implement separately. With OpenSats' support of Vitor's work, alongside a separate grant supporting KotlinGeekDev's dedicated iOS effort, the year's work focused on completing the Kotlin Multiplatform migration, restructuring the library around the outbox model, extending protocol coverage, and laying the foundation for MLS-based group messaging.
An important structural shift was Quartz's completed migration to Kotlin Multiplatform and its independent publication to Maven Central. The library is now available under com.vitorpamplona.quartz with platform-specific variants for Android, JVM, iOS ARM64, iOS Simulator, and Linux x64. The v1.04.0 release recorded the KMP migration as finished, Maven publishing added, and the OpenTimestamps Java code converted to pure Kotlin in the same window. Subsequent work continued to expand platform support, with linuxX64 support added in March 2026. The practical effect is that Quartz is now a reusable toolkit that other projects can depend on directly.
The iOS side of that migration came largely from a dedicated grant supporting KotlinGeekDev, whose KMP completeness work, merged in early March 2026, filled in the cryptographic, data-handling, and utility layers iOS needed. Secp256k1 came online with help from the underlying secp256k1-kmp library, which was already multiplatform-capable. The hardest piece was libsodium, a software library for encryption, decryption, signatures, password hashing, and more. The alternative paths were either too convoluted or required resources KotlinGeekDev didn't have, so he compiled the original C libsodium source, extracted the iOS library files, and wrote bindings to the C headers by hand. A follow-up cleanup removed the Swift bridge that earlier iterations had relied on. Vitor later replaced that approach with a fully custom Kotlin implementation of the same cryptographic primitives, removing the dependency on the C library entirely. The repository's iOS Feature Parity Table, which tracks how iOS support compares to Android features, now shows iOS at full parity for cryptography, data handling, file storage, and most utilities. Together, this work made it more realistic to build iOS nostr apps with Quartz.
Something I can point to is getting Libsodium to work on iOS for Quartz […]. It was remarkable for me because I used libsodium source code to make it work, because the other solutions were either too convoluted, or required resources I didn't have.
–KotlinGeekDev, Quartz/Amethyst contributor
Beyond the iOS work, the v1.00.0 release completed the migration to the outbox model and reorganized Quartz around per-NIP modules. Quartz moved from a single fixed relay pool to a dynamic relay pool where each NIP specifies its intended relays and can grow or shrink as users scroll. Each NIP now lives in its own dedicated folder with its own relay clients, event builders, filter builders, caching systems, and helper functions, while still sharing Amethyst's main relay and cache engine when appropriate. The arrangement gives each protocol spec room to evolve independently and lets new NIPs integrate as distinct modules.
Protocol coverage expanded substantially during the year. The v1.07.0 release added support across marketplace events, relay-based groups, labeling, Cashu wallet kinds, such as nutzaps, vanish requests, relay discovery, P2P order events, Negentropy sync, trusted assertions, relay management, mint discoverability, app handlers, DVM events, and other protocol areas. Newer additions visible in Amethyst's supported features list, all built on Quartz, include voice messages, web bookmarks, and code snippets. Underneath this sits a high-performance local database engine designed to keep Amethyst responsive while using a small memory footprint. The combination of broad NIP coverage and an efficient local store is what makes the modular per-NIP architecture practical at the scale active clients generate. That architecture now supports projects beyond Amethyst itself, such as the Amber nostr signer, the Citrine local relay, and the Robosats peer-to-peer exchange, all building on Quartz for their protocol work.
Foundational work was also added for Marmot, a group-messaging system that runs the IETF's Messaging Layer Security standard over nostr. The initial implementation included interop test vectors from the spec, so Quartz's Marmot can be checked against other MLS implementations. This foundation shipped in the v1.08.0 release. Three further pieces were then merged: higher-level Marmot integration, UI and group-chat surfaces, and thread-safety fixes.
The library that started inside Amethyst now stands on its own, with two developers and two grants behind it. Vitor continues to drive the core through his long-term grant, and KotlinGeekDev's dedicated iOS work brought the platform side to parity. That foundation is already being built on by the newly funded Amethyst Desktop effort, which uses Quartz alongside the iOS work to bring Amethyst to larger screens. What began as an internal module is now shared Kotlin infrastructure that other nostr apps depend on.
The libraries covered in this report show nostr developer tooling reaching further into the languages and platforms developers already work in. TypeScript, Rust, Apple platforms, Android and Kotlin Multiplatform, Flutter and Dart, PHP, and Ruby each gained a year of progress, and several themes ran across the group.
The outbox model became a first-class concern in many of these libraries, giving apps better ways to find users where they actually publish. Encryption support moved toward the newer versioned format and the gift-wrapped private message format that builds on it. Support for the ecash family of specs landed in several libraries, making it easier for clients to combine social features and payments through one consistent stack.
Library work is rarely the most visible part of an ecosystem, but its leverage is apparent. When a maintainer adds a capability to a shared library, every app that depends on that library gets a clearer path to the same capability. OpenSats' grants gave these maintainers time to focus on improvements that compound across the rest of the network, and the projects highlighted here are part of the broader set of grants we have funded for nostr development since 2023.
If you believe in building and maintaining censorship-resistant communication infrastructure, consider supporting The Nostr Fund. Every donation helps independent developers build open-source software that keeps users in control.
If you are a developer working on a nostr project that strengthens this ecosystem, we encourage you to apply for funding.