Qortal-Nextcloud-Integration/docs/product/prd-v1.md

# NuQloud for Nextcloud
## PRD v1

## 1. Product summary

NuQloud for Nextcloud is a plugin suite that replaces external identity providers and backup dependency with a vendor-neutral stack.

It ships with two runtime modes:

1. `powered` mode: Qortal internals hidden from end users/admins.
2. `full_qortal` mode: native Qortal terminology and advanced capabilities exposed.

## 2. Personas

1. `Nextcloud Admin (SMB/MSP)`: wants simple setup, clear costs, low risk.
2. `Security/Compliance Admin`: wants verifiable identity and tamper-evident publishing/accountability signals.
3. `Power User / Qortal-native Operator`: wants full protocol visibility and controls.

## 3. Problems to solve (v1)

1. Dependence on external OIDC vendors for identity.
2. Dependence on centralized backup vendors.
3. Poor portability and weak proof/verification in restore paths.
4. High friction when crypto-native concepts are exposed too early.

## 4. Goals

1. Provide vendor-neutral OIDC for Nextcloud login.
2. Provide NuQloud encrypted backup publishing with verifiable replication status.
3. Abstract protocol complexity in `powered` mode while preserving `full_qortal`.
4. Support paid NuQloud package tiers with predictable capacity model.

## 5. Non-goals (v1)

1. No user-managed wallets in public/default flows.
2. No cross-instance federation features.
3. No marketplace/discovery surface.
4. No public debug APIs/UI in production mode.

## 6. Modes and packaging

### 6.1 Runtime modes

1. `powered` (default)
   - “NuQloud Identity” naming.
   - “Publishing credits” abstraction.
   - Minimal advanced controls.
2. `full_qortal`
   - Existing advanced behavior retained.
   - Qortal language and internals exposed.
   - Debug tools available (admin-gated).

### 6.2 Commercial packages

1. Free Core
   - NuQloud identity + baseline service connectivity.
   - No managed package entitlements.
2. Starter / Advanced / Pro
   - Single-user and lighter hosted-account package tiers.
3. Team Starter / Team Advanced / Team Pro
   - Multi-user hosted package tiers.
4. Branded / Branded Pro / Branded Enterprise
   - Managed branded instance packages for organizations and communities.
5. Capacity add-ons + publishing credit top-ups
   - Capacity block model (not punitive overage wording).

## 7. Functional requirements

### 7.1 Identity

1. Admin can enable Create Account / Login (OIDC).
2. Admin can require NuQloud Identity for new users.
3. End user sees no wallet/seed terminology in `powered` mode.
4. Broker/internal services remain token-protected.

### 7.2 Backups

1. Admin can enable encrypted NuQloud backups.
2. Admin can configure schedule + retention.
3. System records backup proof metadata (hash/time/status).
4. Restore preview must verify integrity before restore action.

### 7.3 Replication

1. Replication guarantees are explicit by package tier.
2. Status panel shows guarantee target vs healthy mirrors.
3. Degraded state is visible and alertable.
4. Replication nodes never receive plaintext data.

### 7.4 Credits and billing abstraction

1. User/admin-facing UI can show “credits” instead of QORT in `powered` mode.
2. Metering must be deterministic and auditable.
3. Ledger entries must include source action, quantity, timestamp, actor.
4. Migration path to full QORT display exists for `full_qortal`.

### 7.5 Admin controls

1. Feature flags are configurable in admin panel and persisted.
2. Mode switch is explicit and reversible.
3. Debug mode is admin-only and warning-labeled.
4. Risky options are hidden by default in `powered`.

## 8. Security and trust requirements

1. No plaintext password storage.
2. Internal broker endpoints require internal token.
3. Sensitive logs redacted by default.
4. SSRF-prone node URL controls are restricted in `powered`.
5. Claims language must avoid absolute security promises.

## 9. UX language policy

Use defensible wording in public/product UI:

1. Prefer: “tamper-evident”, “verifiable”, “resilient”, “vendor-neutral”.
2. Avoid: “unhackable”, “impossible to take down”, “guaranteed uncensorable”.

## 10. Acceptance criteria (v1)

1. New install defaults to `powered` mode.
2. Admin can switch modes without breaking existing user mappings.
3. OIDC login works in both modes.
4. Backup job can publish and verify with recorded proof metadata.
5. Replication status panel displays healthy/degraded/error states.
6. Package limits enforced with clear UI messaging.
7. 3 default backup settings options

- Nextcloud Config (all useful config files / php / nextcloud conf / etc.)
- User files (all 'data' for users, with user-specific identifiers but published under instance name.)
- Acccounts + related (anything here to keep OIDC reproducible/operational in case of failure. Broker/Q Backup Files for accounts.)

## 11. Rollout phases

1. Phase A: mode system + naming + flag wiring.
2. Phase B: identity hardening + powered UX.
3. Phase C: backup proof model + replication status. - later addition Q-App for independent verification outside NC backend.
4. Phase D: package enforcement + metering.
5. Phase E: docs, migration tooling, marketplace prep.

## 12. Success metrics

1. Time to first successful login (admin + user).
2. Time to first successful backup + proof.
3. Replication health percentage over time.
4. Reduction in support tickets caused by crypto terminology confusion.
5. Conversion from free core to paid replication tiers.