Dear Rebecca,
Thank you, and the Committee, for taking the time to consider my grant proposal and for sharing the Committee’s reasoning.
I would like to respectfully clarify a few points, because I believe the rejection rationale does not fully reflect the current state of the project or the context behind some of my decisions.
The statement that the extensions do not appear to be actively maintained does not match the project’s public development history.
The previous grant was completed on August 2, 2025. Over the following nine months, I continued maintaining and improving Nydia on my own time. In 2026 alone, my GitHub profile shows more than 400 contributions, including more than 300 commits and nearly 130 merged pull requests across the Chrome, Firefox, and Safari extension repositories. This work covered compatibility fixes, internal architecture, security hardening, storage redesign, WebAuthn and CBOR correctness, and popup isolation.
For example, I completed the work that moved Nydia from alpha to beta. I traced and fixed the root cause of the passkey-creation failures that had been blocking several websites, and Nydia now passes Google’s validation — a check I had long used as my benchmark for broad relying-party compatibility, since Google is among the strictest. After reaching this milestone, I opened the beta publicly and committed to a concrete, verifiable testing program: confirming passkey registration and sign-in on Chrome, Firefox, and Safari across services listed on passkeys.directory, a community-driven index of websites and apps that support passkeys for sign-in. The goal is to map how Nydia behaves against real relying parties and to catch broken or unsupported flows early, before Nydia reaches a wider audience through browser extension stores.
Since then, Nydia has also adopted a new storage format that changes how passkey data is encrypted, stored, and retrieved. Passkey data is now split into two encrypted layers: one for metadata, one for the private key itself, each protected by its own derived key. Only the matching passkey’s secret layer is decrypted when needed. All storage access now goes through background message passing, keeping sensitive operations outside the page context and reducing unnecessary exposure of private key material.
The popup was also reworked at the communication layer. Each WebAuthn credential prompt now runs inside an isolated iframe rather than directly in the page DOM, and each credential operation gets its own MessageChannel between the popup and the content script. Messages are scoped to the active session, which makes popup handling more deterministic and prevents stale or unrelated UI events from affecting the current credential operation.
Taken together, the beta milestone, the public testing program, and the storage and security rework demonstrate sustained, active maintenance and represent a step forward in the project’s readiness for public use. The limited public promotion reflects caution, not inactivity: major security and storage changes are still being tested, and for a project that handles passkeys, premature publication is not a harmless milestone — it creates real user expectations and real security obligations.
This was a deliberate decision about timing, made after careful consideration.
After the completion of my previous grant, Chapter 2, immediate publication of the extensions would have been premature while the Sia ecosystem was still in a transitional state. At the time, indexd was not yet publicly available, and it was important to evaluate how Nydia could integrate with it before putting the extension in front of users through public browser stores.
Publishing a renterd-based version into the stores came down to one technical question: whether users who uploaded their passkeys through renterd would later have a reliable path to access them through indexd. If that path was not possible, listing Nydia for Chrome, Firefox, and Safari simply to create a public store presence would have meant asking users to trust their passkeys to that path before it was proven — not a risk I was willing to place on users.
Since public-store publication has not yet happened by design, broad adoption is limited at this stage. The Committee is right to weigh adoption, maintenance, and community interest; what I dispute is only the inference — that the absence of store listings is evidence the project is inactive or uncommitted. It is not. That absence is the direct result of the timing decision set out above, not a sign of neglect. The publicly visible work points the same way: a public open-beta announcement on the Sia forum, real-world testing against passkeys.directory, and the security and architectural readiness described above.
It’s a fair concern, and it rests on an assumption: that anyone who wants to manage passkeys must also be willing to save their passwords. But that assumption doesn’t hold for everyone. Some users do not want to save passwords in any manager at all. They may prefer to type them manually, keep them offline, or avoid placing passwords and passkeys under the control of the same product. Still, they may want to use passkeys — and they should have a way to do so without adopting a password manager. That matters because passkeys are about relying on passwords less, not managing them better. A passkey is not a safer way to store a password, but a way to stop needing one. For those users, a dedicated passkey manager is not redundant. It solves a different problem.
I would like the evaluation to include developers as well, not only end users. The Android app is the public-facing product, but the longer-term value lies in Nydia-Core: an open-source Go library that gives other projects a ready, reusable foundation for the authenticator side of passkeys — creating credentials and signing assertions, with Ed25519, self-attestation, and Sia-backed storage — so they can build on it instead of reimplementing that layer themselves.
With that in mind, I would like to surface a few aspects of Nydia that may not have been fully visible in the initial review and may be relevant to the Committee’s view of the project’s value.
-
Nydia is one of the first passkey managers to support Ed25519 passkeys.
Based on my recent hands-on testing, major password and passkey managers — including Google Password Manager, Apple Passwords, Proton Pass, 1Password, and Bitwarden — do not currently support creating Ed25519 passkeys. For a project built around decentralized storage, Ed25519 is particularly relevant: its smaller key size directly reduces the amount of data stored on Sia per credential, aligning the cryptographic choice with the storage model itself. -
Nydia’s manifest declares no extension permissions, optional permissions, or host permissions. For a browser extension that handles passkeys, this is a meaningful security and architectural advantage: it keeps Nydia’s privileged browser-permission surface minimal. Compared with major password-manager extensions such as Proton Pass, 1Password, and Bitwarden, Nydia has a much smaller permission footprint. Nydia also has no third-party runtime dependencies.
The extension is also approximately 170 KB in size, while many well-known password managers are tens of megabytes. This reflects a very different design philosophy: minimal attack surface, minimal dependency footprint, and no unnecessary privileges.
This also matters from an ecosystem perspective. Today, users are often forced into one of two models: their passkeys are locked into vendor ecosystems, such as Google Password Manager or Apple Passwords, or they are stored on private company servers. Nydia explores a different model: open-source, user-owned, encrypted, decentralized passkey storage built around Sia.
I understand that many non-technical users may struggle to articulate the difference between a passkey manager and a password manager. But I don’t think that observation supports the conclusion drawn from it — that the project therefore holds no value for the Sia ecosystem.
The distinction is less about product labels and more about control: where credentials are stored, who controls them, and whether that storage can be user-owned and backed by Sia. Nydia’s alternatives are not just password managers as a product category — they are the Apple and Google ecosystems and centralized credential providers. Even when users get more flexibility from third-party managers, their passkeys are still stored through infrastructure they do not control.
That distinction matters. Nydia is not valuable because every less-technical user can explain the difference between a passkey and a password. It is valuable because it gives passkeys a user-owned, decentralized storage path instead of leaving control over that part of digital identity inside Big Tech ecosystems or private centralized infrastructure. That is the same principle Sia itself is built on: owning your data matters whether or not every user can put the mechanics into words.
And that is also how the project creates ecosystem value. Every passkey stored through Nydia is encrypted credential data written to Sia. Every application built on Nydia-Core can become another entry point into the Sia ecosystem. Less-technical users’ current understanding matters, but it should not be the only lens for judging long-term ecosystem value — especially in an area where standards, terminology, and adoption patterns are still evolving.
That is why the storage question becomes more important as passkey adoption itself changes. The WebAuthn Level 3 specification points toward a model where passkeys are not merely an optional setting that users enable later in account settings, but something that can be introduced at the right moment during the account creation flow. The same mechanism can also help upgrade existing password-based accounts during a later sign-in.
That mechanism is called Conditional Create.
In practice, Conditional Create changes when a passkey is created: not as a separate step the user has to opt into, but inside a flow they are already in.
Right now, most sites still live in this model:
create an account with email and password → then, maybe, enable a passkey.
Because of this, passkeys are often perceived as an optional add-on: if the user wants one, they can turn it on; if not, they can ignore it. The password remains the primary key to the account.
Conditional Create changes that dynamic. After a user creates or signs into a password-based account, the relying party can request passkey creation using conditional mediation. If the browser, operating system, and credential provider have the necessary context and user consent, the passkey can be created at the right moment, without a prominent modal registration prompt or a separate trip to account settings.
So the adoption path starts to look different:
create or sign into a password-based account → the passkey is created inside the existing flow → future sign-ins become passkey-first.
In effect, Conditional Create reduces the friction of passkey adoption — and accelerates it — by helping users transition from passwords to a more secure, phishing-resistant authentication method.
That is where this becomes important for Sia: if passkeys become easier to create, the number of credentials will grow with them, increasing the amount of authentication data that needs to be stored somewhere. Today, that “somewhere” is mostly Apple, Google, and a handful of private credential-provider companies — concentrating a critical part of digital identity in centralized infrastructure that Sia exists to counter.
A valid password is the one prerequisite for conditional creation — so the password’s last useful job is to authorize the creation of the passkey that will eventually replace it.
The question, then, is no longer only how to make passwords more convenient and secure through password managers, 2FA, and similar tools. The more important question becomes how to move both new and existing password-based accounts toward a passkey-first model as seamlessly as possible.
In that model, the password starts to become vestigial. It is no longer a long-term key to the account; it becomes more like a one-time bootstrap token — something needed only to get the user far enough to create a passkey.
Passwords will not disappear overnight, but Conditional Create changes the role they are meant to play: from primary authentication factor to temporary step toward a passwordless-by-default internet.
Finding a Path Forward
I do not see anything in the Committee’s feedback that represents an unfixable blocker. The concerns raised — publication status, maintenance signals, user adoption, and ecosystem value — are concrete points that can be discussed, clarified, and addressed.
I want to be clear that I am approaching this in a solution-oriented way. I am not asking the Committee to overlook its concerns; I am asking for a clear path to address them.
Public release in the Chrome, Firefox, and Safari stores has been the intended outcome from the beginning. The practical question is not whether the extensions should be published, but in what state they should be published. If indexd is the preferred direction for the Sia ecosystem, my concern is that publishing a renterd-based version now could create unnecessary migration friction for users. I would propose including indexd integration for the browser extensions as part of the public-release work in a revised proposal, since that would strengthen the final product and align it more closely with the ecosystem’s direction.
Beyond the immediate publication question, the trajectory I described — passkey adoption accelerating as Conditional Create removes the friction of creating them — only sharpens a gap that already exists: users have no good way to truly own or recover their passkeys.
This matters not only as a product question, but as an ecosystem question.
User-owned data is at the core of what Sia stands for, and authentication is fast becoming part of that same picture. Passkeys are becoming a critical part of online identity, yet this space is still largely controlled by Apple, Google, Microsoft, and private credential-provider companies. That makes it a natural place for Nydia to apply Sia’s values around user ownership and decentralized storage — to one of the most critical areas of the modern web.
Thank you for your consideration,
Oleh.