Skip to content

[Bug] Changing a relay's canonical URL leaves user and agent avatars pinned to the old media origin #3601

Description

@HashMac

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/<sha>.<ext>
  • working media after the move: https://new-host/media/<sha>.<ext>

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/<sha>.<ext>.
  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/<sha>.<ext>.
  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/<sha>.<ext> 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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions