[Bug] Changing a relay's canonical URL leaves user and agent avatars pinned to the old media origin
- Dominant language
- Rust
- Stars
- 32.7k
- Forks
- 4.3k
- Avg merge
- 1d 13h
- Merged PRs (30d)
- 253
Description
## Describe the bug
When an existing self-hosted Buzz community is moved from one canonical relay origin to another while keeping the same relay database and media store, Buzz reconnects successfully but existing user and agent avatar records remain pinned to the retired HTTP origin.
For example:
- old relay: `ws://old-host`
- new relay: `wss://new-host`
- old avatar: `http://old-host/media/.`
- working media after the move: `https://new-host/media/.`
After the relay URL changes, the signed kind-0 `picture` fields and managed-agent `avatar_url` values still contain the old URL. The desktop then falls back to initials for the user and agents. Local avatar caches can sometimes mask the problem, but they do not repair the durable profile data and do not help mobile clients or fresh installations.
In a reproducible test, this affected the user's profile plus every custom and built-in agent profile.
## Steps to reproduce
1. Run a self-hosted Buzz relay at `ws://old-host`.
2. Upload profile avatars for the user and one or more agents.
3. Confirm the saved profile URLs use `http://old-host/media/.`.
4. Expose the same relay database and media store at `wss://new-host` / `https://new-host` and update the Buzz community relay URL.
5. Restart or reconnect Buzz Desktop.
6. Open the Agents screen and the user's profile.
7. Observe avatars falling back to initials.
8. Confirm that the original media hashes return HTTP 200 at `https://new-host/media/.`.
9. Edit each avatar URL to use the new origin and save it.
10. Observe the avatars immediately return and the newly signed profile records persist.
Hostnames and profile identifiers above are anonymized.
## Expected behavior
When the canonical URL of the same community/relay changes, Buzz should safely migrate first-party relay media references to the new origin and republish valid profile records:
- update the user's signed kind-0 profile;
- update each managed agent's agent-signed kind-0 profile;
- update the managed-agent configuration;
- preserve arbitrary external avatar URLs unchanged; and
- keep the repaired avatars available on Desktop, mobile, and fresh installations.
## Actual behavior
Buzz updates the active relay connection but leaves existing profile and managed-agent avatar URLs on the old origin. The old links fail, and profiles render as initials until every profile is manually edited and republished.
## Confirmed boundary
In Buzz Desktop 0.5.0, `desktop/src/shared/lib/mediaUrl.ts` only rewrites a `/media/.` URL when its origin matches the currently active relay origin. Once the community has moved to a new origin, the old first-party URL is treated like an unrelated external URL and is returned unchanged.
Managed-agent profile reconciliation also does not self-heal this state when both the local agent record and its signed profile event contain the same stale URL.
This is therefore a durable profile-migration problem, not only a rendering or cache fallback problem.
## Suggested acceptance criteria
1. Track the prior canonical origin when an existing community relay URL is changed.
2. Migrate only URLs that match the relay media path and a known prior origin for that same community.
3. Verify the corresponding media object is reachable at the new origin before publishing.
4. Republish correctly signed user and managed-agent kind-0 profiles and update local managed-agent records.
5. Do not rewrite unrelated external avatar URLs.
6. Add an end-to-end test covering a relay origin change, the user avatar, custom and built-in agent avatars, restart, and a second/fresh client.
## Environment
- Buzz Desktop: 0.5.0
- OS: macOS
- Deployment: self-hosted relay
- Migration: local `ws/http` origin to private `wss/https` origin
- Relay database and media store: unchanged
## Related issues
- #2576 — custom agent avatars missing after restart; local fallback does not repair stale signed URLs
- #2665 — transient user-avatar fallback/cache behavior
- #2366 — related relay-local profile/media portability problem across communities
- #2476 — imports pasted avatar URLs into current-relay media, but does not migrate existing signed profiles after a relay-origin change
Contributor guide
Research direction
Start with desktop/src/shared/lib/mediaUrl.ts and trace the community relay URL change and managed-agent profile reconciliation paths. Verify the existing media and profile behavior against the stated acceptance criteria, then add end-to-end coverage for a relay-origin change, user and agent avatars, restart, and a fresh client. Done means first-party URLs and signed profiles migrate while external URLs remain unchanged.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100