As of right now, the avatar is transmitted by supplying image URLs as image_url, image_url_medium, and image_url_small respectively. These images have fixed sizes, according to the spec, and they are all we have. So for me to add support for raw images, I’d have to do more work than I was expecting, and just adding another field seems like a super hacky way of doing things.
Instead, I’d like to bring the idea forward to remove these image URLs, and instead federate the image as a nested Photo. Doing so would allow for much more flexibility when it comes to adding new sizes in the future, and I somehow doubt we need to maintain two separate ways of federating photo-like information.
However, while thinking about this, I realized this comes with its own set of issues:
If we refactor diaspora* so that the avatar is, in fact, just a reference to a photo, we’d have to migrate all existing images to an actual photo object. This can be done in a migration, but it would break downwards compatibility horribly. At the moment, I don’t have a good idea on how to keep things compatible.
Looking at the photo spec, we never specified the image URL prefixes we expect to be available. If we use the same resizing- and federation-logic, we should probably specify what we expect in terms of image sizes and image names.
Friendica (and potentially lots of other software) currently doesn’t spend a single thought about Photos, and just federates post-content-photos as inline-markdown. Inconsistent UX in terms of fullscreen photo view aside, I have serious doubts that we’d achieve a state where other projects can reliably build Photo objects.
All of this makes me wonder if this is even the right approach. Does anyone here hold an opinion? @supertux88 maybe?
One alternative approach I could think of is to only ever provide the full-res profile picture on the federation-layer, and building a local cache of resized profile images for each pod. I know some projects are doing this, but I’m a bit concerned about disk space, and CPU cycles. But it would kinda get around some issues, and it would also allow protocol-implementations to resize to their own liking, instead of being limited by a spec. In this case, I actually don’t see the benefit of fixing image resolutions inside a protocol specification.
Would working with the “Photo” element would change something in the way the post is received and processed by Diaspora? If yes, then just tell what I should do.
Very wild idea… media server? Request to example.org/media/photoguid123.jpg?width=200&height=200 provides the image in the requested size if cached, if not nearest cached size and starts to create a cached version in the background for the next request. the possible parameters to be appended to an image would be part of the protocol and then the photo objects would become a single url, original width and original height.
But that’s an alternative to your last paragraph, not really addressing any of your questions.
I just quickly read the problem and didn’t get everything but… we didn’t have problems before the API. Can’t we change the API to request avatar differently than other photos? The URL could be part of the profile object for example. And keep the rest code the way it was before?
Ehm, excuse me? Just because we didn’t see the problem does not mean there is no problem. Right now, even completely ignoring the API, there is no way to show anything besides the images we have right now. Want to build a high-DPI profile image display with more than 500px? Well, too bad, you can’t. Want to build something that allows users to see a full-scale view by clicking on the profile icon (just like we do for post photos)? Well, too bad, you can’t.
As of right now, the API works, matches the spec 100%, and we could ignore everything else. Granted, it doesn’t make too much sense that raw is pointing to the same image than large is, but it’s not a violation, since we don’t actually make guarantees about image sizes. We could just ignore the issue and keep things as it is, but you know that I don’t do the “just look away and act like there is no problem” thing.
I actually really like that idea. Since we have some known- and fixed URLs anyway, so that wouldn’t do much harm. We could do a similar thing as we do with fetching posts, a well-known URL using the GUID, and explain what people can expect. Good idea to keep in mind, for sure, I like it more than all pods doing their local cache (for both a disk usage perspective (as in, large pods with more images will have a large disk anyway), and for economical reasons (we don’t end up recomputing the same image over and over again)). If we can find a solution to the other issues, that would fit very well.
Sorry, I thought your current fix was using scaled_full for raw not only for the avatars, but for every picture. From that point of view, it was a regression comparing before the API. But I was wrong, diaspora* is now as the same state than before the API, so my previous post makes no sense, sorry about it.
