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
- Run a self-hosted Buzz relay at
ws://old-host.
- Upload profile avatars for the user and one or more agents.
- Confirm the saved profile URLs use
http://old-host/media/<sha>.<ext>.
- Expose the same relay database and media store at
wss://new-host / https://new-host and update the Buzz community relay URL.
- Restart or reconnect Buzz Desktop.
- Open the Agents screen and the user's profile.
- Observe avatars falling back to initials.
- Confirm that the original media hashes return HTTP 200 at
https://new-host/media/<sha>.<ext>.
- Edit each avatar URL to use the new origin and save it.
- 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
- Track the prior canonical origin when an existing community relay URL is changed.
- Migrate only URLs that match the relay media path and a known prior origin for that same community.
- Verify the corresponding media object is reachable at the new origin before publishing.
- Republish correctly signed user and managed-agent kind-0 profiles and update local managed-agent records.
- Do not rewrite unrelated external avatar URLs.
- 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
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:
ws://old-hostwss://new-hosthttp://old-host/media/<sha>.<ext>https://new-host/media/<sha>.<ext>After the relay URL changes, the signed kind-0
picturefields and managed-agentavatar_urlvalues 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
ws://old-host.http://old-host/media/<sha>.<ext>.wss://new-host/https://new-hostand update the Buzz community relay URL.https://new-host/media/<sha>.<ext>.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:
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.tsonly 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
Environment
ws/httporigin to privatewss/httpsoriginRelated issues