Duplicate avatar endpoints

[joshtrichards]

There are two ways to retrieve avatars from the server: the REST endpoint and the WebDAV endpoint.

Today, basically all clients and code paths use the REST endpoint, as you can see below.

Unless I'm missing something (such as a significant functional difference), I think we can clean up the small use of WebDAV avatar retrieval in the Desktop client¹ and drop the DAV avatar endpoint implementation from the server entirely.

Avatars: Endpoint Usage Table by Client/App

This table summarizes which endpoint(s) each official Nextcloud client/app or key library uses to retrieve avatars.

Client / App	Uses REST Endpoint (/avatar/{user}/{size})	Uses DAV Endpoint (/remote.php/dav/avatars/...)	Notes
Web UI	Yes	No	Always uses REST for avatars in all UI elements.
Desktop Client	Yes (fallback for old servers only)	Yes (default)	Uses DAV endpoint as primary for Nextcloud 10+; REST as fallback.
Android Client	Yes	No	Only REST endpoint.
Android Library	Yes	No	Only REST endpoint.
iOS Client / NextcloudKit	Yes	No	Only REST endpoint.
Spreed/Talk (Server)	Yes2	No	Uses custom REST endpoints and proxies to avatar REST, not DAV.
Talk Android	Yes	No	Uses REST endpoints for avatars.
Talk Desktop	Yes	No	Uses REST endpoint for avatar URLs.
nextcloud-vue	Yes	No	Only REST-style URL construction.
nextcloud-router	Yes	No	Only REST-style URL construction.
Nextcloud Neon	Yes	No	All avatar fetches via REST endpoints, not DAV.

---

Summary

• Only the Desktop client uses the DAV endpoint, and only as the default for NC10+; all other clients and code use the REST endpoint exclusively for avatar retrieval.
• The REST fallback remains in the Desktop client for compatibility with ownCloud or old (from it's implementation's perspective; which may be wrong) Nextcloud servers.
• All other clients, mobile apps, frameworks, and libraries use only the REST endpoint.

Footnotes

1. Its only use is in one small spot in the Desktop client, and this appears to be due to an old port of changes from the oC Desktop client, rather than a deliberate architectural choice. I don't see a compelling reason for this otherwise, especially since there's a fallback to the REST endpoint, controlled by server version. ↩

2. Spreed/Talk implements its own REST endpoints for room avatars and proxies user avatar requests to the REST endpoint; it does not use DAV. ↩