Your celebration.
Your information.

WedFusion is a development prototype. Use fictional information until production services and an independent security review are complete.

The private host workspace

The iPhone app and /host website encrypt the wedding on your device. Your passphrase and decryption key are not uploaded. Browser storage and iPhone storage are separate; encrypted backups let you transfer your wedding explicitly. A recovery kit lets you restore its saved snapshot and choose a new password using an encrypted recovery file and its separate code. Recovery kits are created on your device; neither the code nor your keys are sent to us. Keep both parts safely and refresh the kit after important changes. There is no automatic cloud backup or email-based password reset. Guest lists and settings do not automatically synchronise between devices.

Biometric unlock on iPhone

On iPhone, optional Face ID or Touch ID unlock stores your workspace password in a biometric-protected Keychain item on that device. It is not uploaded, synchronised through iCloud Keychain or included in wedding backups. Your password remains available as a fallback. Recovering with a new password clears the saved biometric credential; you can enable it again after unlocking with your password.

Private planning diary

You can plan before choosing a wedding date. If you enable partner sharing, diary notes are encrypted on the device and synced through a separate relay. Anyone with the complete partner link can read and edit that diary. Guest contacts, invitations and settings are not included. Earlier notes on a joining device stay private until you explicitly add them to the shared diary.

Offline edits stay local until a successful sync. Simultaneous edits preserve both drafts for review. Stopping sharing removes the relay copy and disconnects your device; downloaded copies remain on each partner’s device. The relay observes connection metadata and revisions. Shared diaries expire 365 days after the last successful write, with removal handled by the operator’s retention task.

Encrypted invitations and replies

Private /guest invitations contain only the details intended for that guest. Invitations and replies travel through a server as encrypted content and are decrypted on the recipient’s device. The server stores opaque identifiers, capability hashes, ciphertext, versions and timestamps, and can observe network metadata. The host reads replies when collecting them; a guest delivery receipt confirms encrypted delivery to the server.

Your complete invitation link grants access to your invitation and response. Share it privately. Anyone receiving a forwarded link may read the invitation or submit a response. Ask the host to replace a lost or forwarded link. The couple can read the information you submit, including optional dietary details.

Contacts, photos and exports

Contact imports are reviewed and saved in the local encrypted workspace. The iPhone picker returns only selected contacts. Importing never sends invitations. The private photo feature opens an album link supplied by the host; Google Drive and other providers have their own permissions and privacy terms. Direct photo uploads and automatic Drive integration are not available in this private flow.

Workspace backups are encrypted. A guest CSV export is an unencrypted file created at the host’s request; protect it appropriately. Sharing files through another app sends them to the destination you choose.

Retention and removal

Hosts can remove published encrypted invitations from the relay without deleting the local wedding. Encrypted relay hubs expire after 365 days; operators must run the retention task to remove expired records. Provider backups have a separate retention process. Ask the couple to remove your local guest record. Removing a server record cannot recall copies already downloaded or shared.

Earlier server-based prototype

The earlier /dashboard and /invite routes use server-side guest records, email services and private photo storage. They do not provide the local-first privacy model described above. Start at /host and use /guest links for the private flow; existing server records are not migrated automatically.