Standard Grant: Nydia Passkey Holder — Chapter 3

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 the first truly 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 accomplished what popular passkey managers haven’t: becoming the first browser-extension authenticator to support the EdDSA (Ed25519) signature algorithm for passkeys. While most browser-extension authenticators remain limited to ECDSA (ES256) and RSA (RS256) algorithms, Nydia embraces the future with Ed25519 — offering superior performance, smaller key sizes, and enhanced security.

Another critically important feature has been implemented: the onboarding process now 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 true 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 — turning the usual “convenience vs. control” trade-off into convenience and control.

Two defining features elevate 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 unveils Self Attestation — an attestation type implemented using 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 of the Nydia browser extensions will be able to synchronize passkeys across devices and browsers, with full portability via the Sia network. So will Android users, who can now finally decide where their passkeys 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.

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

With Android support, Nydia makes passkey ownership truly universal.
Your keys. Your network. No vendor lock-in. Across browsers and Android.

Project Goals & Milestones

Note: For planning purposes, the timeline is based on an October 1, 2025 start date.

Milestone #1 (Due by April 2026)

  • Develop CredentialProviderService for Android 14+
  • Build passkey creation with support for Ed25519, ES256, and RS256
  • Build 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.
  • Enable passkey authentication.
  • Implement transport hints for credentials.
  • Implement self attestation support for passkey registration.
  • Design user interface for passkey management.
  • Add support for biometric and device credential authentication.

Milestone #2 (Due by July 2026)

  • Implement per-credential passkey upload via renterd API
  • Implement QR-based cross-device passkey sign-in.
  • Implement event-driven background upload to renterd on local passkey updates (e.g., signCount increments) to keep local and renterd states consistent.
  • Implement bidirectional passkey sync core via renterd API to reconcile local and remote passkey states.
  • Create renterd settings UI with connection testing and proper settings validation.
  • Implement per-credential passkey backup UI for Sia storage.
  • Implement UI for bidirectional sync of passkeys.
  • Implement in-app bucket creation via renterd API
  • Implement per-credential passkey deletion via renterd API
  • Track and display per-credential passkey sync status in the UI.
  • Implement dark theme support with system preference detection.
  • Add passkey encryption/decryption.
    • Create 12-word BIP39 seed phrase generation and recovery logic.
    • Develop onboarding UI flow featuring welcome screen, seed generation/restore choice, 12-word display grid, seed input validation with BIP39 dictionary check and error messaging.
  • Enable cross-platform use of the same encrypted passkey set between Android and Nydia browser extensions.
  • Determine handling for the scenario where a user enters an incorrect seed phrase and synchronizes passkeys: records are downloaded from the renterd server but remain undecryptable in the database. Research and define optimal approaches for handling this edge case. Define the most appropriate way to present this state to the user in the UI.
  • Comprehensive compatibility testing and version adaptation, starting with the stable Android 14 credential provider foundation established in Milestone #1, then systematically examining API evolution through Android 15–16 to understand implementation improvements, feature expansions, and technical refinements introduced in subsequent platform releases.
  • At the same time, though the primary scope of this grant is the Android implementation of Nydia, development of the browser extensions remains ongoing. If any attestation enhancements come up during Nydia-for-Android development, they’ll be added to the Chrome, Firefox, and Safari extensions as part of this milestone to maintain alignment across the ecosystem.

Clarification Note: A renterd endpoint is used to synchronize passkeys across devices via the Sia network — mirroring how Nydia’s browser extensions work today. As outlined in the “Who benefits from your project?” section, the Android implementation is meant to extend the existing Nydia workflow: users of the browser extensions can synchronize passkeys across Android devices and desktop browsers via the Sia network, while the app remains local-first and fully usable without sync. For users who already run a renterd node, the Android app simply extends that setup with an improved, mobile-friendly experience where tasks like bucket creation and passkey deletion via the renterd API are built into the app’s interface for a seamless user experience without needing to interact with the renterd dashboard. Over time, the browser extensions will adopt the same improved UX.

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. If full implementation proves infeasible during the grant period, initial support will focus on browser-based use cases, with native app flows deferred to a future chapter.

Budget Justification

The project requests $72,000, disbursed in nine equal monthly installments of $8,000, of developer fees for the project author over a 9-month research and development period, acknowledging the substantial engineering complexity required to architect and launch a robust credential provider service for the Android ecosystem.

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 this revised proposal. A few notes:

  • The first milestone needs to occur sooner than 6 months from the start date. Take a look again at your milestones and break them down into 1 month chunks so there can be measurable and steady progress over this 6-month period. And please do the same for the second milestone.
  • Note: we would like the terminology of “developer fees” used over “salary.”

If you’re able to make the above revisions by this Wednesday, September 10th before 5pm ET then this proposal will be reviewed at next week’s Grants Committee meeting.

3

Hi @mecsbecs, thank you for the feedback - I’ll aim for Wednesday 5pm ET, but if I need a bit more time, I’ll submit it soon after.

4

Dear Rebecca and Grants Committee,

It seems that, in my previous (12 August) submission, I didn’t fully explain why the goals required the amount of time they did. In this (9 September) revised proposal, I’ve addressed that by describing many (though not all) of the contributing components to make both scope and schedule more transparent and to show how each milestone is composed. While breaking the work into monthly chunks provides valuable accountability, R&D work naturally involves iterative discovery where breakthroughs do not always align with calendar boundaries. In my most recent grant, a four-month milestone included a complex study of WebAuthn attestation compatibility (“Research WebAuthn attestation mechanisms to expand web service compatibility”), with material progress occurring near the end — typical for R&D, where a significant share of value emerges after the research plateau.

Nevertheless, I take responsibility for potentially creating confusion with my presentation of Project Goals & Milestones in this proposal: unlike my first two grants, which used outcome-based planning, this grant proposal initially came in a task-oriented format, which may have contributed to your request for month-by-month breakdowns. While such granular planning may not fully capture the iterative nature of a complex, R&D-heavy project like CredentialProviderService, I acknowledge that my approach could have been clearer about how progress would be measured. To address this and align with your call for “measurable and steady progress,” I’ve included below an alternative outcome-based version that defines target outcomes, measurable metrics, acceptance criteria, and artifacts (code, written and video reports) — structured into clear checkpoints. This outcome-based approach, which I used in my first two grants, better balances the unpredictability of R&D work with the need for accountability.

Project Goals & Milestones
Note: For planning purposes, the timeline is based on an October 1, 2025 start date.

Milestone #1 (Due by November 2025)

  • Create initial Android project structure on GitHub with a CredentialProviderService skeleton for Android 14

Once the skeleton is in place and Milestone #2 begins, a breakdown of predictability occurs: this phase is both new and complex in the Android ecosystem and requires deep study, experimentation, and testing. Subsequent estimates are grounded in my experience building a passkey authenticator for Chrome, Firefox, and Safari, extrapolating proven approaches. Dates are indicative given R&D variability; acceptance criteria remain fixed.

Milestone #2 (Due by April 2026)

  • CredentialProviderService for Android 14 with UI for passkey management.

Indicative R&D-Aware Monthly Cadence:

December: Handle Credential Manager requests for createCredential / getCredential via CredentialProviderService; initial provider UI and end-to-end wiring in place (Acceptance: provider visible in system picker; UI parses and displays PublicKeyCredentialCreationOptions / PublicKeyCredentialRequestOptions; short demo video).

January–February: Passkey creation across WebAuthn playgrounds and pilot apps; logs. (Acceptance: Successful passkey creation on WebAuthn playgrounds and pilot apps; support for ES256, Ed25519, and RS256 signature algorithms; CBOR attestation objects and COSE keys are valid; authenticatorData flags formed correctly; returns authenticatorAttachment; supports credProps (rk); transport hints returned; short demo video)

February–March: Passkey authentication (assertion) with verification logs. (Acceptance: Authenticates with previously created passkeys; generates valid assertion signatures that pass RP verification; handles allowCredentials and usernameless (discoverable) flows; logs show incrementing signCount; demo video of successful authentication flow).

March: UI passkey management; biometric and device credential flows (Acceptance: In-app UI displays all saved passkeys; delete functionality working; biometric prompt appears and authenticates user; falls back to PIN/pattern when biometric unavailable; demo video showing management UI and biometric flow).

March-April: Implement self attestation support for passkey registration. (Acceptance: Generates a spec-compliant self attestation statement (attStmt) and the signature validates correctly — RP verification passes).

Why some items span two months: January targets a public demo of passkey creation on WebAuthn playgrounds (target January 2, 2026), with ES256 as the baseline algorithm. Coverage for Ed25519 and RS256 may land by the end of February as a function of R&D-driven uncertainty rather than a planned deferral. Importantly, February’s primary objective remains authentication (assertion); any remaining creation-side work from January (e.g., adding algorithms) is completed in parallel, without delaying assertion. This preserves measurable monthly progress while accommodating R&D variability.

Milestone #3 (Due by May 2026)

  • Implement per-credential passkey upload via renterd API.
  • Create renterd settings UI with connection testing and proper settings validation.
  • Implement per-credential passkey backup UI for Sia storage.
  • Implement UI for bidirectional sync of passkeys.
  • Implement in-app bucket creation via renterd API.
  • Implement per-credential passkey deletion via renterd API.
  • Track and display per-credential passkey sync status in the UI.
  • Implement dark theme support with system preference detection.
  • Implement bidirectional passkey sync core via renterd API to reconcile local and remote passkey states.
  • Implement event-driven background upload to renterd on local passkey updates (e.g., signCount increments) to keep local and renterd states consistent.

Milestone #4 (Due by June 2026)

  • Add passkey encryption/decryption.
  • Create 12-word BIP39 seed phrase generation and recovery logic.
  • Develop onboarding UI flow featuring welcome screen, seed generation/restore choice, 12-word display grid, seed input validation with BIP39 dictionary check and error messaging.
  • Determine handling for the scenario where a user enters an incorrect seed phrase and synchronizes passkeys: records are downloaded from the renterd server but remain undecryptable in the database. Research and define optimal approaches for handling this edge case. Define the most appropriate way to present this state to the user in the UI.
  • Enable cross-platform use of the same encrypted passkey set between Android and Nydia browser extensions.

Milestone #5 (Due by July 2026)

  • Implement QR-based cross-device passkey sign-in.
  • Comprehensive compatibility testing and platform-version adaptation, starting with the stable Android 14 credential provider foundation established in Milestone #2, then systematically examining API evolution through Android 15–16 to understand implementation improvements, feature expansions, and technical refinements introduced in subsequent platform releases.
  • If any attestation enhancements come up during Nydia-for-Android development, they’ll be added to the Chrome, Firefox, and Safari extensions as part of this milestone to maintain alignment across the ecosystem.

Thank you for your feedback and patience as I refined this proposal.

1 Like
5

Hi @new0ne - thanks for providing more detail on your milestones. This proposal will be presented to the Grants Committee at the meeting on September 30th.

6

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 doesn’t agree with such a significant gap between Milestone #1 and #2, and recommends breaking Milestone #2 down further. (You can reference our new Development Guide for suggestions regarding milestone and task breakdown.)
  • Additionally, there are still concerns regarding the viability and usability of this application and the Committee recommends you wait until indexd is live as this could offer a potential alteration to the architecture of this project (i.e. the reliance on a renterd endpoint).

We’ll be moving this to the Rejected section of the forum. Thanks again for your proposal, and you’re always welcome to submit new requests if you feel you can address the committee’s concerns.