Default avatar is not passed to the app

[mitar]

My test user does not have an avatar set. Sandstorm display the default Avatar and says this will be the picture to identify the user, but that avatar URL is not send to the app to be really used.

[mitar]

And I know that it is proposed that if picture is null, app should be using those same avatars, but I would claim that if Sandstorm shows some picture, that picture should be propagated to the app.

[dwrensha]

From https://docs.sandstorm.io/en/latest/developing/auth/ :

X-Sandstorm-User-Picture: The URL of the user's profile picture. [...] If this header is missing, the user has no profile picture. In this case, it is recommended that apps use identicon.js, with the user's ID (from X-Sandstorm-User-Id) as the input, to produce identicons consistent with those that Sandstorm's own UI would produce. Note that you should NOT hash the ID; just pass the hex ID directly to the Identicon constructor as the hash argument.

[mitar]

Yes, but this requires change to the app, just to be consistent with Sandstorm? Wouldn't it be better if Sandstorm would just provide that default avatar and this is it?

[kentonv]

The identicon is generated client-side using identicon.js. There is nothing for the server to pass.

[mitar]

I know, but just to make it easier for apps, it could generate it on the server and passed it.

I made necessary changes and now package can run on the server as well: https://github.com/stewartlord/identicon.js

I am generating it myself now in the app, but it would be really better if it would be done by the Sandstorm: https://github.com/mitar/council-app/blob/master/packages/core/documents/user.coffee#L37

[kentonv]

Unfortunately identicon.js produces PNGs that seem to be essentially uncompressed, probably because it doesn't use a real PNG library but rather a hack meant for use in client-side data URLs / blobs. If you can fix that too, then maybe we're getting somewhere.

[mitar]

Done: peer/mind@c767482

https://github.com/mitar/council-app/blob/c76748268af4b20e63262c4cd42c125d3b25ec78/packages/core/documents/user.coffee#L37

Only this is needed to compress the avatar:

compressedPng = PNG.sync.write PNG.sync.read uncompressedPng

You can use pngjs package for this.

[paulproteus]

Hi @mitar,

I'm not sure I understand what you mean when you say "done" here, and I'm interested in seeing this ticket progress forward. Particularly:

• What kind of space savings do you get with/without the compression?
• Would you be willing to submit something like this a pull request to Sandstorm, so that we could test and merge that?

If not, that's fine, but I thought I might as well ask!

[mitar]

I'm not sure I understand what you mean when you say "done" here

Done as that those few lines of code create Sandstorm compatible avatar and compress it as requested by @kentonv. It works for my app, but I think (as I described above) this is not something what each app should implement on its own, but something provided by Sandstorm.

So I think similar code could be used in Sandstorm.

What kind of space savings do you get with/without the compression?

If I remember correctly ~2kB -> ~150B.

Would you be willing to submit something like this a pull request to Sandstorm, so that we could test and merge that?

Not sure where to. Where would be a good place to generate such an avatar in Sandstorm?

[dwrensha]

While investigating ways to supply a collections app with app icons, as part of #2027, I tried implementing this approach and got some numbers for a typical icon:

side length (pixels)	indenticon.js (bytes)	pngjs (bytes)
24	1716	146
128	17268	461
512	263792	2329

(These are the lengths of the raw buffers, which would then need to be base64ified to be put into a data URI.)

User avatars are typically 512 by 512 pixels. Packing the resulting ~2KB of data into a HTTP header to pass it to the app strikes me as somewhat unwieldy, but maybe it would be worth it.

It would be really nice if the data size did not need to scale with the image size. Maybe what we really need is for identicon.js to produce SVGs rather than PNGs.

[mitar]

I do not think this should be passed as header, but it should be an URL hosted and generated by Sandstorm. So there would be only a normal URL passed through a header.

[dwrensha]

That's an interesting idea. In addition to our current static.sandstorm-example.com/:assetId route, we could add something like identicon.sandstorm-example.com/:size/:id where the server would render the identicon on demand.

[mitar]

I am not sure if size is an useful parameter. In fact I think it would be more beneficial to have large size which can then be nicely cached once by the browser across all sandstorm apps.

[mitar]

Also, the header is just one, so it can be just one URL. We could maybe add multiple headers for multiple sizes, but this overkill in my opinion. What I hoped with this ticket is that header should never be empty. If there is a default avatar then it should point to this default Sandstorm avatar URL hosted by Sandstorm.

Then the apps do not have to have any special handling of that avatar. They just use the URL and this is it. Also no special handling for different sizes: they just use the same URL for all sizes.

[dwrensha]

Then the apps do not have to have any special handling of that avatar. They just use the URL and this is it.

Right, but also it would be good if the Sandstorm server did not need to store anything it its database for these icons. So the server should be able to tell whether it's a normal static asset or an identicon being requested.