Standard Grant: Nydia Passkey Holder – Chapter 3 (Revised)

Grants Rejected
1

Project Name: Nydia Passkey Holder – Chapter 3: Where Nydia Unlocks the Power of Touch
Project Lead: Oleh N.

Project Description

Nydia’s evolution unfolds in three acts:

2024 — Nydia launched as a decentralized passkey authenticator.

Chrome and Firefox gained seamless passkey storage and sync backed by the Sia network, removing vendor-ecosystem lock-in between browsers and their cloud services and shifting credentials from corporate servers to user-owned infrastructure.

2025 — If the first act was an escape, the second is a gathering of allies. Safari arrives, and passkeys flow across Chrome, Firefox, and Safari — powered by Sia.

Nydia also implemented support for the EdDSA (Ed25519) signature algorithm for passkeys, going further than what is currently available in most browser-extension authenticators. While most remain limited to ECDSA (ES256) and RSA (RS256), Ed25519 offers superior performance, smaller key sizes, and enhanced security.

Another critically important feature has been implemented: the onboarding process generates a unique 12-word BIP39 recovery phrase to encrypt passkeys before storing them on the Sia network.

This combination of decentralized storage and cutting-edge cryptography makes Nydia not just another authenticator, but a glimpse into the future of authentication.

2026 — Android has joined the group chat.

With this research and development initiative, Nydia brings passkey ownership to Android with a credential provider backed by the Sia network.

The Android Credential Provider Service lets third-party authenticators plug directly into Android’s native sign-in UI and present passkeys alongside platform options with no app switching. For the first time on Android, users can choose their passkey storage provider while keeping a fully integrated, one-tap experience. With Nydia, user-owned credentials feel as natural as the defaults, pairing control with ease of use.

Two key features distinguish Nydia’s Android release: borderless, cross-device QR sign-in and verifiable, tamper-evident registration provenance.

For universal accessibility, Nydia implements QR-based cross-device passkey sign-in, allowing users to sign in on a desktop or laptop by scanning a QR code with their Android phone. This FIDO2/WebAuthn-aligned passwordless flow generates the passkey assertion on the phone, while the desktop browser completes authentication — without storing or transferring keys to the client device, enabling secure use on shared computers, public workstations, and borrowed devices.

For registration provenance, Nydia implements Self Attestation — an attestation type that uses the packed attestation statement format, where each passkey proves the authenticity of the registration data and key possession by producing an attestation signature over that data with the private key generated during the registration ceremony. This creates a tamper-evident cryptographic binding between the registration parameters and the resulting credential, ensuring the server can verify, using the corresponding public key, that this credential originates from the user’s authenticator. This enhances auditability of registration, from challenge through credential creation. For Nydia, self attestation delivers verifiable passkey registration while preserving Nydia’s commitment to user privacy — each credential carries a self-signature as its own proof of authenticity.

Who benefits from your project?

Users: Android users gain full control over their passkey storage — choosing where credentials are stored and by whom. Beyond personal devices, QR-based cross-device authentication extends Nydia’s reach to anyone who needs secure access on untrusted hardware — whether signing in at a library computer, a colleague’s workstation, or a hotel business center. Passkeys remain accessible everywhere, without ever leaving the phone.

Developers: Nydia provides open-source building blocks for creating authentication applications:

  1. Android Credential Provider Service scaffold — an implementation of Android’s Credential Provider API that serves as the integration layer between Android and third-party credential providers.

  2. Nydia-Core — a FIDO2/CTAP2 authenticator library with support for Ed25519, ES256, RS256, and self attestation.

Together, these components turn a single application into a reusable toolkit.

How does the project serve the Foundation’s mission of user-owned data?

With Android support, Nydia brings passkey ownership to mobile devices.
Your keys. Your network. No vendor lock-in.

Who is the target user for your project?

Anyone who uses passkeys and wants portable credential recovery under their own control and secure QR-based authentication on untrusted hardware, without being locked into a single device, platform, or vendor.

Project Goals & Milestones

Note: For planning purposes, the timeline is based on a June 1, 2026 start date.

Milestone #1 (Due by 25 June 2026)

Create CredentialProviderService skeleton for Android 14.

  • Make provider visible in Android system credential picker.
  • Handle Credential Manager requests for createCredential and getCredential.
  • Parse and display PublicKeyCredentialCreationOptions in the UI.
  • Parse and display PublicKeyCredentialRequestOptions in the UI.
  • Publish project on GitHub with clear build instructions.
  • Create a demo video demonstrating provider in action.

Milestone #2 (Due by 25 July 2026)

Implement passkey creation across WebAuthn playgrounds and pilot apps with support for Ed25519, ES256, and RS256 signature algorithms.

  • Implement passkey creation with support for Ed25519, ES256, and RS256.
  • Implement a CBOR encoder for attestation objects and COSE keys.
  • Implement authenticator data flags per the WebAuthn specification.
  • Return authenticator attachment as part of the PublicKeyCredential.
  • Support the credProps registration extension and return rk in client extension results.
  • Implement transport hints for credentials.
  • Implement self attestation support for passkey registration.
  • Create a demo video demonstrating successful passkey registration.

Milestone #3 (Due by 25 August 2026)

Implement passkey authentication (assertion).

  • Generate valid assertion signatures that pass relying party verification.
  • Implement allowCredentials filtering in the assertion flow.
  • Support usernameless assertion with client-side discoverable credentials.
  • Create a demo video demonstrating successful authentication flow.

Milestone #4 (Due by 25 September 2026)

Integrate the Sia Storage SDK.

  • Upload and delete passkeys per credential.
  • Reconcile local and remote passkey state via bidirectional sync.

Milestone #5 (Due by 25 October 2026)

Design UI.

  • Create UI displaying all saved passkeys.
  • Add per-credential passkey backup UI.
  • Track and display per-credential passkey sync status in the UI.
  • Add UI for bidirectional sync of passkeys.
  • Add a settings screen.
  • Add in-app notifications.
  • Add passkey deletion.
  • Implement dark theme support.

Milestone #6 (Due by 25 November 2026)

Implement passkey encryption.

  • Implement an onboarding walkthrough with seed phrase generation.
  • Implement a login wizard with seed phrase recovery.
  • Implement biometric authentication.
  • Implement fallback to PIN/pattern when biometric authentication is unavailable.

Milestone #7 (Due by 25 December 2026)

Implement QR-based cross-device authentication and ensure compatibility across Android 14–17 platform versions.

  • Implement QR-based cross-device passkey sign-in.
  • Comprehensive testing across Android 14–17 to ensure compatibility.
    • The first months will focus on Android 14 in daily development, but scheduled regression cycles will also run on 15–17 to watch for API changes, added features, or behavioral changes. If those newer releases surface platform-specific quirks, I’ll budget time within this milestone to address them so that Nydia remains feature-aligned across Android 14–17 without assuming breakage in advance.
  • Test websites and applications including QR sign-in scenarios, using the FIDO Alliance Passkeys Directory as reference.

High-level architecture overview and security best practices

Components:

  • Kotlin application layer: Android UI, Credential Provider service integration, passkey request flows, and backup/restore orchestration.
  • Core layer: credential creation, assertion signing, COSE key encoding, and WebAuthn response serialization.
  • Vault layer: a two-tier key model — BIP39 seed phrase for deterministic master-key recovery, device-local Android Keystore for biometric day-to-day unlock — with private passkey material encrypted in Room.
  • Sia integration: the app uses the Sia Storage SDK to upload encrypted backups, manage object metadata, and restore backed-up passkeys.

Security practices:

  • Passkeys are encrypted locally before being stored or backed up.
  • The master key that protects passkeys is deterministically derived from the user’s BIP39 recovery phrase; recovery on a new device requires the same seed phrase.
  • Android Keystore backs biometric unlock for day-to-day access.
  • Sensitive key material is cleared from memory after use where possible.
  • Backups contain encrypted credentials and non-secret recovery parameters only; Sia hosts and indexers never receive plaintext passkey material.
  • The third-party dependency surface approaches zero.

Potential Risks

While Android 14+ allows third-party passkey managers to provide passkeys, certain OEM devices may lack support for this feature. This may result in limited availability of Nydia on some devices.

Supporting native Android applications via the Credential Manager API may require additional discovery, testing, and adaptation to app-specific behaviors (e.g., apps that integrate WebAuthn in nonstandard ways). If full implementation proves infeasible during the grant period, initial support will focus on browser-based use cases, with native app flows deferred to post-grant development.

Budget Justification

The project requests $56,000 to cover the developer fee over a 7-month research and development period. This budget reflects the substantial engineering complexity required to architect and launch a robust credential provider service for the Android ecosystem with comprehensive passkey support.

Beyond the Grant

One day, Nydia will be on the store shelves — and in users’ pockets.

Working on the previous grant taught me that, for a project of this complexity, committing to public release dates is a promise better not made lightly.
I prefer to frame this work as a research and development initiative — roughly 30% of the time is implementation, while the other 70% is spent studying, prototyping, and comparing approaches before choosing one. I’m drawn to frontier technologies, but as often happens with R&D, the road ahead isn’t always clear, and I’d rather be honest about that up front than overpromise a ship date.

But one thing doesn’t depend on timing: Nydia will always stay Sia-first.
The project is part of a long-term commitment to the Sia ecosystem — advancing decentralized, self-sovereign authentication built on the safest user-owned cloud storage.

Sia isn’t a phase Nydia will eventually outgrow.
Sia is the thread woven through every chapter, past and future :thread::sparkles:

Are you a resident of any jurisdiction on that list? Will your payment bank account be located in any jurisdiction on that list?

No to both questions.

Will all of your project’s code be open-source?

Yes.

Where will the code be accessible for review?

Do you agree to submit monthly progress reports?

Yes.

Contact info

Email: [email protected]
Discord: new0ne

2

Hi @new0ne - thank you for your proposal. To differentiate it from the version you submitted in September I added ‘Revised’ to the title.

Additionally:

  • The Foundation will be closed from December 24 - January 4 inclusive and the Grants Program will be pausing its operations during this time and no reviews will be conducted. This means progress or final reports are not expected and will default to the following month’s reporting and review period, so please revise in your above milestone schedule.

  • As mentioned in the feedback to your last proposal, the Committee can revisit this project after indexd has launched. I see you’ve tried to include it in this revised proposal, but it’s difficult to account for the impact and time needed with something one hasn’t seen yet. Therefore, this proposal will not be presented to the Committee until after indexd is publicly available.

For clarity, I will put this proposal in the ‘Inactive’ section of the Forum and feel free to edit it as needed in the meantime.

3

Thank you, Rebecca – understood. I’m happy to wait until indexd and the SDK are publicly available.

Once that happens, I’ll update the milestones and shift the dates so that the schedule lines up with the actual release window, taking into account the Foundation’s holiday closure.

Looking forward to revisiting this with the Committee once indexd is out.

1 Like
4

Hello @mecsbecs,

Now that the Sia Storage SDK is publicly available, I’ve updated the proposal to reflect the current Sia Storage SDK direction and added more detail around the architecture, security model, and post-grant plans.

When you have a moment, I’d appreciate another look from you and the Committee.

5

Hello @new0ne,

Thank you for reaching out again regarding this proposal. I see you’ve reviewed the new funding directives, but perhaps missed this section in the post:

Unfortunately, this means this proposal will remain ‘Inactive’.

We hope to see another grants proposal from you soon.

6

Hello @mecsbecs,

I’ve seen this section, but I don’t think Nydia falls under the “password managers” category.

Nydia is a passkey authenticator, not a password manager. The proposal does not include password storage, password autofill, or password vault functionality. In fact, throughout the last two years of development, I have never publicly described Nydia as a password manager or planned password-related features.

The grant is focused on passkeys: Android Credential Provider integration, WebAuthn/FIDO2 credential creation and assertion flows, encrypted passkey backup and recovery using the Sia Storage SDK, and QR-based cross-device authentication.

From my perspective, Nydia is closer to two areas listed under “What the Committee wants to fund / Project ideas”:

  • sharing files via platforms without vendor lock-in
  • small useful replacements for everyday tools utilizing SDKs

That is exactly the direction of this proposal: making passkeys portable and user-controlled, without locking them into a single device, platform, or vendor.

I’d appreciate the Committee reviewing it under that distinction :slightly_smiling_face:

7

Hi @new0ne - thank you for this explanation and framing. This will be presented to the Committee next week.

1 Like
8

Hello @new0ne,

The Committee was unfortunately unable to get to your proposal during today’s meeting. Your proposal has now been slotted for review during the next meeting on May 12th.

Thank you for your patience.

9

Thanks for your proposal to The Sia Foundation Grants Program.

After review, the Committee has decided to reject your proposal citing the following reasons:

  • The Committee finds that the browser extensions from the previously completed grants have not been published for Chrome, Firefox, or Safari use; and the extensions do not appear to be actively maintained, or broadly adopted demonstrating a lack of community interest in this project.

  • There are doubts as to the continued practicality of having a passkey manager separate from a password manager from an end consumer standpoint. The distinction between these two tools is not clear to less-technical users generally, so the Committee does not see value for the broader Sia ecosystem in another grant for this project.

We’ll be moving this to the Rejected section of the Forum. Thanks again for your proposal.

10

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.

  1. 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.

  2. 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.