While repeatedly banging my head against a wall while trying to figure out a nice solution to providing the raw profile picture URL, I decided I need to stop and start a discussion about the way we federate profile pictures.
As of right now, the avatar is transmitted by supplying image URLs as
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.