[Bug]: Incoming federated calendar owner avatar is resolved through local /avatar endpoint and falls back incorrectly

[hirschrobert]

Bug description

For incoming federated calendars, the Calendar app appears to pass a federated remote user id into the normal local avatar endpoint. The local avatar request returns 404, and the UI then shows an incorrect dark avatar/placeholder instead of a proper fallback.

Example requested URL on the receiving instance:

/avatar/YWxpY2VAY2xvdWQtYS5leGFtcGxlLm5ldC9uZXh0Y2xvdWQ=/64/dark

The decoded identifier is a federated id like:

alice@cloud-a.example.net/nextcloud

Steps to reproduce

1. Set up two federated Nextcloud instances.
2. Share a calendar from user alice on instance A to user bob on instance B.
3. Open the Calendar app on instance B.
4. Look at the incoming shared calendar in the sidebar or calendar picker.

Expected behavior

The owner avatar for an incoming federated calendar should either:

• render a valid remote/federated avatar, or
• use a stable guest/placeholder avatar intentionally.

It should not rely on a local avatar lookup that is guaranteed to fail for a federated remote principal.

Actual behavior

The Calendar app requests a local avatar path for the federated id, and that request returns 404 on the receiving instance because the federated id is not a local user account.

On the affected instance:

• /avatar/<encoded federated id>/64/dark returns 404
• /avatar/<encoded federated id>/64/dark?guestFallback=true returns a valid generated PNG

This suggests the Calendar app is using NcAvatar with a federated principal/user id, but without handling the remote-user case.

Environment

• Nextcloud Server: 33.0.2.2
• Calendar app: 6.2.2
• PHP: 8.4
• OS: Debian 13
• Web server: Nginx

Additional information

The current main branch still appears to render shared calendar owner avatars through NcAvatar using the owner principal's userId in places such as:

• src/components/AppNavigation/CalendarList/CalendarListItem.vue
• src/components/Shared/CalendarPickerOption.vue

Related issue with a similar failing /avatar/.../dark pattern:

• In public calendars, open attached files (with nextcould calendar client) require login #5357

[SebastianKrupinski]

Hi @hirschrobert

You're analysis is correct, we do not have specific logic for this case, this will need to be investigated.