perf(avatar): return actor avatar versions with the participant list

[pringelmann]

☑️ Resolves

• Server side: perf(core): allow versioned avatar URLs to be cached for 30 days server#64295
• Nextcloud Vue: feat(NcAvatar): add a version prop for longer avatar caching nextcloud-libraries/nextcloud-vue#8959
• Follows Improve avatar management to reduce load during large Talk calls server#61726

Returns actorAvatarVersion for each participant. Clients put it in the avatar URL as ?v=, and the server then caches it for 30 days instead of 1.

Avatars are one of the heaviest things a big call pulls, and with a 1 day TTL they expire between weekly calls, so everyone refetches every participant every time. In a HAR I grabbed from a company call, 199 of 236 avatar requests came from the participant list.

Scope is deliberately just the participant list. Chat messages and the rooms list were left out after @Antreesy pointed out the payload cost of a field per message. Chat avatars keep the 1 day cache, nothing breaks.

AI (if applicable)

• The content of this PR was partly or fully generated using AI

🖌️ UI Checklist

🖼️ Screenshots / Screencasts

Nothing visual. Avatars render identically, only the URL gains &v=.

🏁 Checklist

• 🌏 Tested with different browsers / clients:
  • Chromium (Chrome / Edge / Opera / Brave)
  • Firefox
  • Safari
  • Talk Desktop
  • Integrations with Files sidebar and other apps
  • Not risky to browser differences / client
• 🖌️ Design was reviewed, approved or inspired by the design team
• ⛑️ Tests are included or not possible
• 📗 User documentation in https://github.com/nextcloud/documentation/tree/master/user_manual/talk has been updated or is not required

🛠️ API Checklist

🚧 Tasks

• Bump @nextcloud/vue once the version prop is released

🏁 Checklist

• ⛑️ Tests (unit and/or integration) are included or not possible
• 📘 API documentation in docs/ has been updated or is not required
• 🔖 Capability is added or not needed

[nickvergessen]

In a HAR I grabbed from a company call, 199 of 236 avatar requests came from the participant list.

I think that is a critical point here. Are we not having conditional rendering of the entries here like on the left sidebar?
Or is it because people join and therefor it resorts which entries are at the top and should be rendered? cc @Antreesy

[pringelmann]

In a HAR I grabbed from a company call, 199 of 236 avatar requests came from the participant list.

I think that is a critical point here. Are we not having conditional rendering of the entries here like on the left sidebar? Or is it because people join and therefor it resorts which entries are at the top and should be rendered?

The list does virtualise, but you're right about the re-sorting. Sort keys are online status, in call, raised hand and user status, so the order churns constantly during a call and different people keep landing in the rendered window. My HAR reflects that:108 of 178 requests in the first 10s, then 70 more over the next minute.

[nickvergessen]

The list does virtualise, but you're right about the re-sorting. Sort keys are online status, in call, raised hand and user status, so the order churns constantly during a call and different people keep landing in the rendered window. My HAR reflects that:108 of 178 requests in the first 10s, then 70 more over the next minute.

Should work more towards the idea of grouping (and collapsing) participants by type, so people without rights are not shown by default in "big" conversations.
Will take this to the team week in addition.

[SystemKeeper]

Should work more towards the idea of grouping (and collapsing) participants by type, so people without rights are not shown by default in "big" conversations.

In addition to that I wonder how much impact the avatar in the system message has. Each participant joining generates a system message, we collapse most of them at some point, but we should also check that for collapsed messages we don't do the request.