Gateway: dynamic image for social sharing

[lidel]

We've added a basic social sharing markup in ipfs/dir-index-html#36 (comment) :

@lanzafame pointed me at this nice prior art from Github shows how UX can be improved by showing useful data via image:

In IPFS context, a cool improvement would be to provide image-per-CID with:

• QR code with shareable URL that could be scanned via phone
  • prior art: share.ipfs.io has nice IPFS-branded QR codes (feat: branded SVG QR code ipfs-shipyard/ipfs-share-files#119), we could do something similar
    • I like the idea of having a branded QR code, as it looks interesting even when not consumed.

      
      QR code playground: https://zpao.github.io/qrcode.react/
      URL of the icon: https://share.ipfs.io/favicon-32x32.png

• CID breakdown (codec, hash)
• dag-pb stats (total size, number of blocks)

Hot take:

• If we implement image generation as an alternative response format named share-img (as in, gateway response changing based on parameter ?format=json|cbor|car|block|share-img) then we don't need to inline the data and don't need to deal with relative vs absolute vs cross-origin links (making this work on all gateway types without any additional configuration).

[lidel]

Note to self: this is blocked until we add support for ?format= in go-ipfs, but it is ok to explore the visual side of things in parallel :)

@jessicaschilling @olizilla @lanzafame it seems github ones are one of the best right now, but lmk if you have other good prior art or ideas around this. I'd like us to nail the design/ux part of this.

[jessicaschilling]

Going to name-check @ericronne here, since his group would be the ones to discuss visual implementation details with.

Love the idea of the QR code for 100% of users, but want to raise a small flag about how best to represent the nerdier/meatier details you list above in a way that won't alienate a super-casual user who sees the social card inline in, say, a Twitter stream. Consider the following GitHub analogy:

• Someone wants to link to a repo, an issue, etc, where that additional data is likely to be welcome since the audience will know what it means
• Someone else wants to just link to a .md document in a particular repo because they want to share the content and GH just happens to be where the content is located; the readers care about the content, not about the data, and might actually be turned off by the data depending on the nature of the content ("this link isn't for me")

I believe we've got a similar issue for people sharing gateway links: sometimes the intended audience doesn't need to care at all about the fact that the content is on IPFS, they just care about the content.

[lidel]

Fully agree on making it approachable.

To clarify: we are only able to do this on links to directories, not individual files.
This reduces the number of designs we need to make. Just one, for a directory under /ipfs/{cid} or /ipfs/{cid}/some/sub/path

Image (QR code?), content path and size should be the most prominent, other details I mentioned are nice-to-have (could be skipped, or presented as a background detail).

[jessicaschilling]

Understood about links being to directories only, but I think this still applies: It could be a directory of cat gifs.

[lidel]

Ack. Perhaps we could render names of a few items from the shared directory followed by elipsis, to indicate contents without the need for opening?

[ericronne]

Thanks for the ping. I fear that i require more context. Is this an og image that will be dynamically generated when a user shares the hashlink for a site hosted on ipfs (for those who haven't explicitly defined one in their site code)?

What's the use case for the qr code?

[lidel]

• yes, this is og image, dynamically generated in place of static one when a link to a directory on IPFS is shared
  • examples of current img in Add base64 favicon and social sharing meta tags dir-index-html#36 (comment)
  • examples of directories for testing/prototyping:
    • xkcd: https://ipfs.io/ipfs/QmdmQXB2mzChmMeKY47C43LxUdg1NDJ5MWcKMKxDu7RgQm (total 112 MB, over 1000 subdirectories and files inside)
    • project apollo archives: https://ipfs.io/ipfs/QmSnuWmxptJZdLJpKRarxBMS2Ju2oANVrgbr2xWbie9b2D (62GB, 6 items)
• QR code (if we decide to include it) would include the link to directory at ipfs.io (the canonical public gateway), enabling the user to scan it with phone and open on a mobile device
  • if we have it, we could include the same QR code on the directory listing itself
  • this is just an idea, not a hard requirement: we may skip QR code and have clear visuals that indicate "this is a directory on IPFS", if that works better

[lidel]

go-ipfs 0.13 shipped with ?format= support on gateways, which allows requesting alternative response types for a content path. In the context of this issue, it could be used for generating an image card similar to what github does.

Next steps here could be tackled in parallel, could be by different contributors:

• design: how would the card look like?

  • feel free to post mockups in comments here.

• code: PR that adds necessary support for ?format=foo so we can use it instead of the static image here:

  • https://github.com/ipfs/go-ipfs/blob/a3a6a59dbbb95845586645dd725238093cf4566a/assets/dir-index-html/src/dir-index.html#L10