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:
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:
1. Generate initials avatar — recommended.
2. Choose from preset icons/colors — more UI, more decisions.
3. Use a generic default image — easiest, but many users look identical.
4. 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:
1. Target ≤100 KiB, hard max 1 MiB — recommended.
2. Target ≤250 KiB, hard max 1 MiB — safer quality.
3. Only enforce ≤1 MiB — simplest but misses “very light object.”
4. 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:
1. 256×256 WebP, JPEG fallback — recommended.
2. 256×256 JPEG only — maximum compatibility.
3. 512×512 WebP/JPEG — higher quality, heavier.
4. Keep original dimensions, compress only — worse for replication.