r/demo/profile standard for Avatar image

[jefft0]

PR #1983 introduced r/demo/profile with many fields including string field Avatar for the user's image. The great thing about r/demo/profile is that many Gno.land apps can use it. Maybe a user first adds their avatar from a different app. Now the user joins the app I developed and it needs to display their image. But how to interpret the string field? r/demo/profile should provide a recommendation for how to use the Avatar field.

Here are two options. We can discuss other options in this issue.

1. Add a field for AvatarMimeType where the value is something like "image/png" or "image/jpeg". The Avatar field is simply the base64 encoding of the image. (This is preferred by the Berty team since it is more clear and doesn't require parsing the Avatar field.)
2. Add a comment to the Avatar field to suggest that the format should use the data URI scheme, such as "data:image/jpeg;base64,9loflYe3agChS5pK". (This is a fallback if you don't like adding a new field as in option 1.)

[iuricmp]

Great proposal.
We can extend data URI scheme to support IPFS:

data:content/ipfs;base64,ipfs-address-in-base-64

[thehowl]

Let's please try to avoid having image content directly stored on Gno.land as data. Some people will do it (there is no inherent limitation, as you point out), but it is (1) a poor use of the blockchain's space and (2) prone to abuse. So we should incentivize storing data elsewhere.

I like @iuricmp's proposal. However, for ipfs, I'm more tempted to support the ipfs:// schema instead, though.

IMO Avatar should be a URL to an image. We should definitely support:

• data (but discourage it; we may remove support eventually if it gets abused)
• ipfs://
• https://

as schemas for avatars.

[n0izn0iz]

@iuricmp IPFS addresses have a strict string encoding, we don't need to specify the encoding of the cid I believe

having the mime type of the data is nice though since this is not stored at ipfs level, only the content bytes, if the mime type is not included, we have to run magic analysis on the data

I would vote for a data uri scheme with an extension like so

data:<mime-type>;ipfs,<cid>[/path]

for example:

data:image/png;ipfs,QmPK1s3pNYLi9ERiq3BDxKa4XosgWwFRQUydHUtz4YgpqB/some/file.png

but supporting only ipfs://<cid>[/path] is already very good

[github-actions]

This issue is stale because it has been open 6 months with no activity. Remove stale label or comment or this will be closed in 3 months.

[moul]

In the future, we will likely whitelist certain domains for direct image rendering. Other images will not be rendered directly and will require users to click to view them.

For now, I suggest allowing people to experiment.

[jefft0]

I would vote for a data uri scheme with an extension like so

data:<mime-type>;ipfs,<cid>[/path]

for example:

data:image/png;ipfs,QmPK1s3pNYLi9ERiq3BDxKa4XosgWwFRQUydHUtz4YgpqB/some/file.png

Sounds good. To experiment, we'll put an IPFS node with an HTTP gateway on out server (which is also hosting the dSocial indexer). We'll try this URI scheme. Since IPFS can't be a "whitelisted realm" dSocial will prompt for the initial loading of the image and remember the choice. Then we can share and see what you think.