Design: optional wallet profile pictures (beyond address-seeded blockies) #230

New issue

Closed

opened 2026-05-21 04:48:15 +00:00 by PlasticDigits · 2 comments

PlasticDigits commented 2026-05-21 04:48:15 +00:00 (Migrated from gitlab.com)

• Copy link
• Copy Markdown

Summary

Today every wallet / contract identity in the dapp is shown with a deterministic ethereum-blockies identicon seeded only by the address (WalletBlockie → AddressInline). Explore letting connected users choose a custom profile image for their wallet while everyone else still gets the existing blockie (or a sensible fallback).

This is a design / product idea issue — no implementation commitment yet. Goal is to align on UX, storage, trust, and how custom avatars compose with the canonical address row from GitLab #98.

Current behavior

• WalletBlockie (frontend/src/components/WalletBlockie.tsx) renders an 8×8 pixelated identicon from ethereum-blockies, cached per address in walletBlockieCanvas.ts.
• AddressInline (frontend/src/components/AddressInline.tsx) pairs blockie + truncated label + optional MegaETH Etherscan link — used across TimeCurve (live buys, podium, arena), referrals leaderboard, scanner links, etc.
• Blockie styling is covered by visual QA (GitLab #226 — live-buy row must not add radial gradient tint; global image-rendering: pixelated on canvases).

Implication: There is no per-user avatar layer today; two different humans sharing no onchain link look identical except for address text.

Problem / opportunity

• Recognition: Repeat players (leaderboards, live buys, WarBow, referrals) are easier to spot with a chosen face than with another purple/green blockie.
• Personality: Fits the playful “Blockie Hills” brand without removing blockies as the default anonymous look.
• Competitive parity: Many wallets and social dapps show ENS / uploaded / Gravatar-style avatars; we only show address-derived art.

Design questions (decide before build)

Who can set an avatar?

• Connected wallet only sets avatar for msg.sender / active connector address?
• Viewing others: show their custom image if set, else blockie — or blockie-only for third parties until they opt in?

Source of image

Approach	Pros	Cons
User upload (IPFS, object storage, indexer blob)	Full creative control	Moderation, size limits, malware, cost, CDN
ENS / NFT avatar (existing token URI)	No upload infra; web3-native	Not all users have ENS; contract avatars vary
External URL (user pastes)	Simple	SSRF, broken links, hotlink abuse, privacy
Onchain small metadata	Verifiable owner	Gas, size limits, immutability

Storage & authority

• Offchain DB keyed by address (indexer/API) vs onchain mapping vs hybrid signature-bound JSON?
• AGPL / product guardrail: avatar is display-only — must not affect buys, CHARM, WarBow, referrals, or any authoritative game logic.

Trust & safety

• Default blockie is trustless (address → pixels). Custom images need moderation policy (report/block?), max dimensions, allowed MIME types, and alt text / aria-hidden strategy for decorative vs meaningful avatars.
• Phishing: similar-looking avatars next to truncated 0x… tails — keep full address on hover / explorer link unchanged.

UX details

• Where is “Edit profile picture” — wallet menu, referrals register, settings page?
• Crop / circular mask vs square (match current blockie box)?
• Show blockie badge or ring when custom image is set (provenance hint)?
• Loading / error states: fall back to blockie if fetch fails.

Proposed direction (strawman — revise in comments)

1. Phase A (read): API or indexer field avatar_url optional per address; AddressInline / WalletBlockie wrapper tries custom URL then blockie.
2. Phase B (write): Connected user uploads or picks ENS avatar; server validates signature (personal_sign message binding address + image hash or URL).
3. Keep explorer link + label behavior from #98; blockie remains fallback for contracts, zero address, and unset profiles.

Touchpoints in codebase (grep after design lock)

rg 'WalletBlockie|AddressInline' frontend/src -g '*.tsx'

Likely extend rather than fork: one WalletAvatar component that delegates to blockie or custom <img> with shared size / className contract.

Acceptance criteria (for a future implementation issue)

• Product decision doc section (or docs/frontend/design.md anchor) describing source of truth, moderation, and fallback rules.
• Connected user can set/clear avatar; others see it where AddressInline is used (or scoped list e.g. leaderboard + live buys only).
• Invalid / missing / blocked avatar → blockie, no layout shift beyond existing blockie box.
• No change to onchain permissions or game scoring from avatar presence.
• Tests: unit fallback chain; Playwright smoke for “set avatar → appears on leaderboard row” (if in scope).

Out of scope (this idea)

• Username / display name separate from address (separate issue if needed).
• Contract “profile” branding (treasury, FeeRouter) — likely stay blockie-only.
• NFT collection as mandatory identity.

Related

• GitLab #98 — canonical address row (blockie + label + explorer)
• GitLab #226 — blockie CSS / live-buy visual QA
• frontend/src/lib/walletBlockieCanvas.ts, frontend/src/components/WalletBlockie.tsx

## Summary Today every wallet / contract identity in the dapp is shown with a **deterministic ethereum-blockies identicon** seeded only by the address (`WalletBlockie` → `AddressInline`). Explore letting **connected users** choose a **custom profile image** for their wallet while **everyone else** still gets the existing blockie (or a sensible fallback). This is a **design / product idea** issue — no implementation commitment yet. Goal is to align on UX, storage, trust, and how custom avatars compose with the canonical address row from [GitLab #98](https://gitlab.com/PlasticDigits/yieldomega/-/issues/98). ## Current behavior - **`WalletBlockie`** (`frontend/src/components/WalletBlockie.tsx`) renders an 8×8 pixelated identicon from `ethereum-blockies`, cached per address in `walletBlockieCanvas.ts`. - **`AddressInline`** (`frontend/src/components/AddressInline.tsx`) pairs blockie + truncated label + optional MegaETH Etherscan link — used across TimeCurve (live buys, podium, arena), referrals leaderboard, scanner links, etc. - Blockie styling is covered by visual QA ([GitLab #226](https://gitlab.com/PlasticDigits/yieldomega/-/issues/226) — live-buy row must not add radial gradient tint; global `image-rendering: pixelated` on canvases). **Implication:** There is **no** per-user avatar layer today; two different humans sharing no onchain link look identical except for address text. ## Problem / opportunity - **Recognition:** Repeat players (leaderboards, live buys, WarBow, referrals) are easier to spot with a chosen face than with another purple/green blockie. - **Personality:** Fits the playful “Blockie Hills” brand without removing blockies as the default anonymous look. - **Competitive parity:** Many wallets and social dapps show ENS / uploaded / Gravatar-style avatars; we only show address-derived art. ## Design questions (decide before build) ### Who can set an avatar? - **Connected wallet only** sets avatar for `msg.sender` / active connector address? - **Viewing others:** show their custom image if set, else blockie — or blockie-only for third parties until they opt in? ### Source of image | Approach | Pros | Cons | |----------|------|------| | **User upload** (IPFS, object storage, indexer blob) | Full creative control | Moderation, size limits, malware, cost, CDN | | **ENS / NFT avatar** (existing token URI) | No upload infra; web3-native | Not all users have ENS; contract avatars vary | | **External URL** (user pastes) | Simple | SSRF, broken links, hotlink abuse, privacy | | **Onchain small metadata** | Verifiable owner | Gas, size limits, immutability | ### Storage & authority - Offchain DB keyed by `address` (indexer/API) vs onchain mapping vs hybrid signature-bound JSON? - **AGPL / product guardrail:** avatar is **display-only** — must not affect buys, CHARM, WarBow, referrals, or any authoritative game logic. ### Trust & safety - Default blockie is **trustless** (address → pixels). Custom images need **moderation policy** (report/block?), max dimensions, allowed MIME types, and **alt text** / `aria-hidden` strategy for decorative vs meaningful avatars. - **Phishing:** similar-looking avatars next to truncated `0x…` tails — keep full address on hover / explorer link unchanged. ### UX details - Where is “Edit profile picture” — wallet menu, referrals register, settings page? - Crop / circular mask vs square (match current blockie box)? - Show **blockie badge** or ring when custom image is set (provenance hint)? - Loading / error states: fall back to blockie if fetch fails. ## Proposed direction (strawman — revise in comments) 1. **Phase A (read):** API or indexer field `avatar_url` optional per address; `AddressInline` / `WalletBlockie` wrapper tries custom URL then blockie. 2. **Phase B (write):** Connected user uploads or picks ENS avatar; server validates signature (`personal_sign` message binding address + image hash or URL). 3. **Keep** explorer link + label behavior from #98; blockie remains fallback for contracts, zero address, and unset profiles. ## Touchpoints in codebase (grep after design lock) ```bash rg 'WalletBlockie|AddressInline' frontend/src -g '*.tsx' ``` Likely extend rather than fork: one `WalletAvatar` component that delegates to blockie or custom `<img>` with shared `size` / `className` contract. ## Acceptance criteria (for a future implementation issue) - [ ] Product decision doc section (or `docs/frontend/design.md` anchor) describing source of truth, moderation, and fallback rules. - [ ] Connected user can set/clear avatar; others see it where `AddressInline` is used (or scoped list e.g. leaderboard + live buys only). - [ ] Invalid / missing / blocked avatar → blockie, no layout shift beyond existing blockie box. - [ ] No change to onchain permissions or game scoring from avatar presence. - [ ] Tests: unit fallback chain; Playwright smoke for “set avatar → appears on leaderboard row” (if in scope). ## Out of scope (this idea) - Username / display name separate from address (separate issue if needed). - Contract “profile” branding (treasury, FeeRouter) — likely stay blockie-only. - NFT collection as mandatory identity. ## Related - [GitLab #98](https://gitlab.com/PlasticDigits/yieldomega/-/issues/98) — canonical address row (blockie + label + explorer) - [GitLab #226](https://gitlab.com/PlasticDigits/yieldomega/-/issues/226) — blockie CSS / live-buy visual QA - `frontend/src/lib/walletBlockieCanvas.ts`, `frontend/src/components/WalletBlockie.tsx`

PlasticDigits commented 2026-05-21 13:21:02 +00:00 (Migrated from gitlab.com)

• Copy link
• Copy Markdown

mentioned in issue #234

mentioned in issue #234

PlasticDigits commented 2026-06-03 13:20:12 +00:00 (Migrated from gitlab.com)

• Copy link
• Copy Markdown

Verification report (GitLab #230)

Issue type: Design / product idea — optional wallet profile pictures beyond address-seeded blockies. No implementation commitment on this issue; acceptance checklist in the issue body is explicitly scoped to a future implementation issue.

What was verified

Item	Result	How
Issue is design-only (no build scope on #230)	PASS	Issue title/labels/body state “design / product idea” and “no implementation commitment yet”.
WalletBlockie → ethereum-blockies 8×8 identicon, cached in walletBlockieCanvas.ts	PASS	Read frontend/src/components/WalletBlockie.tsx, frontend/src/lib/walletBlockieCanvas.ts (WALLET_BLOCKIE_GRID = 8, getWalletBlockieSourceCanvas).
AddressInline pairs blockie + truncated label + optional explorer / profile (#98, #258)	PASS	Read frontend/src/components/AddressInline.tsx; grep usage across arena live buys, podium, referrals, WarBow sections, WalletProfileModal.
No per-user custom avatar layer (avatar_url, WalletAvatar, upload UI)	PASS	rg avatar in frontend/src and indexer/ — no product avatar fields; only marketing art prompts.
Touchpoint inventory (rg 'WalletBlockie|AddressInline' frontend/src -g '*.tsx')	PASS	11 consumer files listed in issue touchpoints; matches repo layout.
Blockie CSS / live-buy visual invariants (#226)	PASS	cd frontend && npm test -- --run src/lib/walletBlockieCss.test.ts src/lib/walletBlockieCanvas.test.ts — 7/7 tests passed (no radial gradient tint on live-buy blockie; global image-rendering: pixelated on canvases).
Frontend sanity	PASS	cd frontend && npm run typecheck — clean.
Future implementation AC (product doc anchor, set/clear avatar, Playwright smoke, onchain isolation)	SKIP	Listed under “Acceptance criteria (for a future implementation issue)” — not in scope for #230.

Manual / QA steps from issue body

• Design questions table & strawman (Phase A/B): Reviewed in issue text; no code changes required on this ticket.
• #226 live-buy blockie styling: Covered by automated CSS tests above; no full-stack or browser run required for a design verification pass.

Conclusion

Current codebase matches the “Current behavior” and “Implication” sections of #230. Custom wallet avatars are not implemented; blockies remain the sole wallet identity art in product UI. This issue can be closed as a captured design brief; open a separate implementation issue when product signs off on source of truth, moderation, and fallback rules.

Follow-ups (optional)

• When ready to build: spawn an implementation issue referencing #230 strawman, #98 (AddressInline contract), and #258 (WalletProfileModal) for “Edit profile picture” placement.
• Add a docs/frontend/design.md anchor (source of truth, moderation, fallback) as part of that implementation issue’s first deliverable.

## Verification report (GitLab #230) **Issue type:** Design / product idea — optional wallet profile pictures beyond address-seeded blockies. No implementation commitment on this issue; acceptance checklist in the issue body is explicitly scoped to a **future implementation issue**. ### What was verified | Item | Result | How | |------|--------|-----| | Issue is design-only (no build scope on #230) | **PASS** | Issue title/labels/body state “design / product idea” and “no implementation commitment yet”. | | `WalletBlockie` → `ethereum-blockies` 8×8 identicon, cached in `walletBlockieCanvas.ts` | **PASS** | Read `frontend/src/components/WalletBlockie.tsx`, `frontend/src/lib/walletBlockieCanvas.ts` (`WALLET_BLOCKIE_GRID = 8`, `getWalletBlockieSourceCanvas`). | | `AddressInline` pairs blockie + truncated label + optional explorer / profile (#98, #258) | **PASS** | Read `frontend/src/components/AddressInline.tsx`; grep usage across arena live buys, podium, referrals, WarBow sections, `WalletProfileModal`. | | No per-user custom avatar layer (`avatar_url`, `WalletAvatar`, upload UI) | **PASS** | `rg avatar` in `frontend/src` and `indexer/` — no product avatar fields; only marketing art prompts. | | Touchpoint inventory (`rg 'WalletBlockie\|AddressInline' frontend/src -g '*.tsx'`) | **PASS** | 11 consumer files listed in issue touchpoints; matches repo layout. | | Blockie CSS / live-buy visual invariants (#226) | **PASS** | `cd frontend && npm test -- --run src/lib/walletBlockieCss.test.ts src/lib/walletBlockieCanvas.test.ts` — 7/7 tests passed (no radial gradient tint on live-buy blockie; global `image-rendering: pixelated` on canvases). | | Frontend sanity | **PASS** | `cd frontend && npm run typecheck` — clean. | | Future implementation AC (product doc anchor, set/clear avatar, Playwright smoke, onchain isolation) | **SKIP** | Listed under “Acceptance criteria (for a future implementation issue)” — not in scope for #230. | ### Manual / QA steps from issue body - **Design questions table & strawman (Phase A/B):** Reviewed in issue text; no code changes required on this ticket. - **#226 live-buy blockie styling:** Covered by automated CSS tests above; no full-stack or browser run required for a design verification pass. ### Conclusion Current codebase matches the “Current behavior” and “Implication” sections of #230. Custom wallet avatars are not implemented; blockies remain the sole wallet identity art in product UI. This issue can be closed as a captured design brief; open a separate implementation issue when product signs off on source of truth, moderation, and fallback rules. ### Follow-ups (optional) - When ready to build: spawn an implementation issue referencing #230 strawman, #98 (`AddressInline` contract), and #258 (`WalletProfileModal`) for “Edit profile picture” placement. - Add a `docs/frontend/design.md` anchor (source of truth, moderation, fallback) as part of that implementation issue’s first deliverable.

PlasticDigits (Migrated from gitlab.com) closed this issue 2026-06-03 13:20:18 +00:00

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

main

cac-design-issue-544

renovate/configure

No results found.

Labels

Clear labels   

agent:fix_bugfix

  

agent:fix_conflicts

  

agent:fix_security

  

agent:gap_analysis

  

agent:implement

  

agent:open_issues

  

agents

  

agent:security_audit

  

agent:verify

  

area

timecurve

  

arena

  

arena-v2

  

audit

  

block:feature_review

  

block:security

  

bug

  

contracts

  

design

  

devops

  

docs

Documentation

  

documentation

  

enhancement

  

epic

Epic / umbrella issue

  

feature

  

frontend

  

indexer

  

low priority

Low priority, investigate other issues first

  

megaeth

  

operations

  

ops

Deploy and operations

  

performance

  

QA

  

qa checklist

  

referrals

  

removal

Legacy removal

  

security

  

smart-contracts

  

tech-debt

  

testing

  

time-arena

TimeArena v2 revamp

  

timecurve

  

visual-qa

No labels

agent:fix_bugfix

agent:fix_conflicts

agent:fix_security

agent:gap_analysis

agent:implement

agent:open_issues

agents

agent:security_audit

agent:verify

area

timecurve

arena

arena-v2

audit

block:feature_review

block:security

bug

contracts

design

devops

docs

documentation

enhancement

epic

feature

frontend

indexer

low priority

megaeth

operations

ops

performance

QA

qa checklist

referrals

removal

security

smart-contracts

tech-debt

testing

time-arena

timecurve

visual-qa

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

code/yieldomega#230

No description provided.