Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Research and design full-content E2EE with OIDC, recovery and trusted devices

Open
  • Is something wrong?
#615 0 comments 0 reactions 1 assignee View on GitHub

Maintainers usually reply within 1 day

@PelikanFix16 is already working on this.

Since Oct 18, 2026.

Assessment

This issue has not been assessed yet.

Description

agent:planning enhancement

Outcome

Founder request from the current session (2026-10-18): provide an optional deployment mode with full end-to-end encryption of Flux content. A person signs in with an existing OIDC/Keycloak identity; their first trusted device creates encryption keys and an offline recovery kit. Conversations, tasks, mind maps, Wiki and files are decrypted only on authorized devices holding the necessary keys. Stealing the server database or backups must not expose that content. Trusted phones and computers should remain convenient without repeatedly entering recovery codes.

This issue delivers thorough research, a feasible architecture and a reviewed implementation contract, before production implementation. OIDC authentication, IdP recovery codes and Flux data-decryption keys are separate concerns. No algorithm, library, key hierarchy or recovery mechanism is selected by this issue.

Ownership and status

  • Implementation owner for the research/design: @PelikanFix16. Independent evaluator: @Zamojski5 or an eligible independent peer.
  • Milestone: Flux — complete application and release.
  • Status: queued, not started; preserve the current WIP limit and finish existing work first.
  • Founder outcome is accepted; the proposed security architecture requires independent assessment before implementation. One comprehensive review and at most one final check of fixes; minor P3 findings do not start another cycle.

Acceptance criteria

  • AC1 — Threat model and complete data inventory. Document protected assets and attacker capabilities: stolen database/backups/blob storage, server/operator or IdP compromise, key substitution, malicious web delivery/XSS, lost/compromised devices and offline attacks on recovery material. Inventory content, titles, attachments, history, drafts, CRDT updates, exports, indexes, notifications, logs, queues and caches. State precisely which metadata remains visible, what the server can verify without plaintext, and the limits of revoking content already obtained by a device. Record gaps explicitly; do not describe partial coverage as full E2EE.
  • AC2 — Evidence-based cryptographic architecture. Compare established protocols and maintained, reviewed libraries using dated primary sources and implementation observations. Design key generation, authenticated encryption, key hierarchy, device authenticity, group sharing, membership changes, rotation, forward-secrecy tradeoffs, replay/tamper protection and concurrent/offline collaboration. Separate observations, vendor claims and inferences. No custom cryptographic primitives or server-held decryption master key. Deliver a justified architecture decision, alternatives and unresolved risks.
  • AC3 — OIDC onboarding, recovery and trusted devices. Design first login for existing/provisioned OIDC identities; generate high-entropy keys on the client and a clearly explained offline recovery code/kit. Compare safe pairing/new-device approval, recovery, code replacement, lost devices, loss of every key, account linking and IdP resets. IdP administrators, password resets and identity impersonation must not automatically decrypt data. Specify protected device storage and practical unlock/lock behavior across desktop and phone/PWA, logout, browser restart, storage clearing and reinstall; verify actual browser/platform support. Never retain an unprotected reusable decryption secret as a convenience shortcut.
  • AC4 — Whole-product integration and migration. Map changes required for current server-side collaboration/validation, permissions, search, previews, notifications, background work, backup/restore, import/export, media and AI/MCP. Define the trust boundary for any explicitly authorized assistant and compatibility with workspace AI lock #614; identify features that require client execution or must be unavailable in E2EE mode. No silent server-decryption fallback. Specify installation configuration, existing-data migration, mixed-mode boundaries, failure handling and downgrade protection, including historical plaintext backups.
  • AC5 — Feasibility evidence and reviewable delivery plan. Produce a reproducible bounded Docker proof of concept with Keycloak, two people and multiple devices, Chromium/WebKit and desktop/phone journeys. Test recovery, pairing/revocation, wrong keys, tampering/replay, membership changes, offline synchronization and restore; inspect stored data/backups/logs for plaintext. Measure meaningful performance/storage impacts, including #228. Commit research, diagrams, UX flows, compatibility matrix, prototype evidence and complete implementation acceptance criteria under docs/. Obtain independent security-focused assessment; distinguish agent review from any external cryptographic audit and record what remains unverified.

Coordination and starting references

Use the current contracts in docs/product/mcp-identity.md, docs/product/mobile-pwa.md, docs/product/decisions.md and the live-editing architecture. Coordinate #614 and #228. Existing media-specific E2EE work (#59/#63) is related, not a substitute for full-content encryption.

Research starting points, checked 2026-10-18, not selected solutions: IETF MLS / RFC 9420, W3C Web Cryptography, Keycloak Server Administration. The owner must perform the deeper research and validate current library/platform capabilities.

Dominant language
TypeScript
Stars
3
Forks
0
Avg merge
19h 9m
Merged PRs (30d)
334

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from ColdPhase/flux

All issues in ColdPhase/flux

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.