Plan ready under assumption: make avatar mandatory in onboarding and automatically compress avatars to stay below the profile-size limit.

Read-only sandbox blocked actual edits.

request_user_input UI unavailable, so please confirm verbally if avatar should remain optional instead.

direnv export zsh attempted per repo rules but failed in read-only sandbox because mise tried to write trust/temp state.

Questions

Question 1: Should avatar upload become mandatory in onboarding, or should it stay optional but auto-compress when provided?

Recommended answer: make it mandatory during onboarding, with auto-compression before upload/storage.
Reason: your issue says “users must add an image to their avatar,” and the network concern is size, not optionality.

Please answer one of:

Mandatory + compress — recommended.

Optional + compress — keep current skip behavior.

Mandatory only — require avatar but don’t add compression beyond current limits.

Question 2 : What should the “easy fallback” be when they don’t have an image?

Recommended answer: Generate a simple avatar from their display name: colored gradient/background + initials, saved as a small PNG/JPEG blob and treated exactly like an uploaded avatar.

Why this is best:

zero extra user work,

satisfies “must add an avatar,”

deterministic/lightweight,

avoids shipping a library or asset pack,

works offline,

keeps profile objects small.

Options:

Generate initials avatar — recommended.

Choose from preset icons/colors — more UI, more decisions.

Use a generic default image — easiest, but many users look identical.

Camera/selfie option — useful, but platform permissions/complexity.

Question 3 : What max size should the stored avatar target be?

Current concern: profile data replicates many times, and there’s a 1 MiB limit. We should not aim for “just under 1 MiB”; that’s still heavy for replication.

Recommended answer: target ≤100 KiB, hard fail only if optimizer cannot get it under 1 MiB.

Why:

512×512 PNG can be large for photos.

256×256 or 320×320 JPEG/WebP is visually fine for avatars.

100 KiB is much friendlier for replicated profiles.

The 1 MiB limit remains a safety ceiling, not the goal.

Options:

Target ≤100 KiB, hard max 1 MiB — recommended.

Target ≤250 KiB, hard max 1 MiB — safer quality.

Only enforce ≤1 MiB — simplest but misses “very light object.”

Smaller target, e.g. ≤50 KiB — leanest, more quality risk.

Question 4 : What dimensions/format should optimized avatars use?

Recommended answer: 256×256 WebP when supported, fallback JPEG, square-cropped center.

Why:

256px is enough for avatar UI and much lighter than 512px.

WebP usually hits ≤100 KiB easily.

JPEG fallback keeps compatibility if canvas WebP encode fails.

Square crop avoids layout surprises.

One caveat: if profiles are consumed by environments that may not support WebP, JPEG-only is safer.

Options:

256×256 WebP, JPEG fallback — recommended.

256×256 JPEG only — maximum compatibility.

512×512 WebP/JPEG — higher quality, heavier.

Keep original dimensions, compress only — worse for replication.