search

gnolang / gno

Gno: An interpreted, stack-based Go virtual machine to build succinct and composable apps + gno.land: a blockchain for timeless code and fair open-source.
https://gno.land/
Other
901 stars 378 forks source link

r/demo/profile standard for Avatar image #2598

Open jefft0 opened 4 months ago

jefft0 commented 4 months ago

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 commented 3 months ago

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

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

thehowl commented 3 months ago

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:

as schemas for avatars.

n0izn0iz commented 3 months ago

@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