Provide a webui + geoip CID (a folder linking to the webui and geoip CIDs directly), making it easy to pin the geoip data

[Jorropo]

Describe the bug

ipfs pin add $(ipfs name resolve webui.ipfs.io)

doesn't pin the geoip data.

Expected behavior Pinning the webui should in an offline first manner, download the application fully. To do so the CIDs published at webui.ipfs.io should embed a link to the geoip data.

Additional context Loading the webui from IPFS can be slow, I expect that pinning the webui would cache it locally and make that fast. It mostly works, however it doesn't fully, the geoip data is not pinned and just as slow.

You actually have find out by some dark magic that https://github.com/ipfs-shipyard/ipfs-geoip/blob/5b85b6d94d3ae40d20392ba40e156760d7d61886/src/lookup.js#L11 is the other thing you need to pin.

Pinning this CID substantially increase the peer tab speed. (like from ~>30s to resolve everything to ~<3s).

[lidel]

ipfs-webui is 27MiB, ipfs-geoip data is ~388 MiB:

ipfs dag stat --progress=true Qmbt1YbZAhMoqo7r1t6Y5EJrYGVRgcaisNAZhLeJY6ehfg 
Size: 388840361, NumBlocks: 220203

Asking people who want to pin webui to also fetch 400MiB does not sound like a good default.

What we could do is to:

• publish ipfs-geoip CID as additional info in RELEASE NOTES
  • if someone wants it, they will now know what to pin in addition to webui
• switch ipfs-geoip from JSON to binary dag-cbor
  • this shuld decrease the size of geip DAG and improve load performance – see https://github.com/ipfs-shipyard/ipfs-geoip/issues/85

[Jorropo]

I think we could propose two options: We could give a webui CID and webui + geoip CID.

Obviously, the webui + geoip CID would be a folder linking to the webui and geoip CIDs directly. (so people pinning this webui + geoip folder would be able to share just the webui to thoses who want it).