I think that usetrmnl.com will compare the newly generate image with the previously generated image, and if they are the same it won't send a new image to the TRMNL device, saving bandwidth and battery.

In my BYOS I generate screens on the fly and don't cache them anywhere, so I can't compare images, but supporting ETags in the firmware would allow servers to implement a similar optimization without caching images.

Edit: I wrote the spec wrong before. Below is an improved one:

Because the images are generated dynamically my /api/display endpoint simply authenticates and returns TRMNL a JSON stucture containing the image_url of the endpoint which will actually generate the image.

As an example, /api/display might return an image_url of https://example.com/api/generate?nonce=<random>. This is the endpoint which needs to determine if the image has changed, which is why we need a nonce to ensure TRMNL always attempts to fetch it.

The image_url endpoint would, along with the image, send the image hash back as an ETag header. The TRMNL device would store the ETag temporarily and add it as a header of the next image_url request.

When the image_url endpoint generates a new image it can compare the new and old ETags to determine if the screen has changed.

If the screen hasn't changed it would return 304 Not Modified. If the image has changed, it would return 200 with a new image and a new ETag.

If the image_url endpoint doesn't return an ETag then the TRMNL device would just behave as it does now.