That would be highly useful and provides a method for imperishable content referencing!
Using a single Gateway like https://<CID>.ipfs.dweb.link/ has even minimal overhead to implement.

If we want to be more reliable, we could maintain a list of fallback gateways:

// Catch clicks on IPFS-links
document.addEventListener('click', async e => {
  const link = e.target.closest('a[href^="ipfs://"]');
  if (!link) return;
  e.preventDefault();

  const nodes = [ 'http://127.0.0.1:8080/ipfs/', 
    'https://ipfs.io/ipfs/', 
    'https://cloudflare-ipfs.com/ipfs/', 
    'https://gateway.pinata.cloud/ipfs/', 
    'https://ipfs.filebase.io/ipfs/',
    'https://ipfs.dweb.link/',
    'https://4everland.io/ipfs/'];

  const cid = link.getAttribute('href').slice(7);
  const urls = nodes.map(n => n + cid);
  const checkForContentOnGateWay = u => fetch(u, { method: 'HEAD', signal: AbortSignal.timeout(1000) }).then(r => r.ok ? u : Promise.reject()); //HEAD only to stop on check on first byte

  // Race Local vs Public Gatway (reduce delay)
  let target;
  try {
    target = await Promise.any(urls.slice(0, 2).map(checkForContentOnGateWay));
  } catch {
    for (let i = 2; i < urls.length; i++) try { target = await checkForContentOnGateWay(urls[i]); break; } catch {}
  }
  location.href = target || urls[1];
});

In T414731#11528117, @Ihlec wrote:

That would be highly useful and provides a method for imperishable content referencing!
Using a single Gateway like https://<CID>.ipfs.dweb.link/ has even minimal overhead to implement.

If we want to be more reliable, we could maintain a list of fallback gateways:

// Catch clicks on IPFS-links
document.addEventListener('click', async e => {
  const link = e.target.closest('a[href^="ipfs://"]');
  if (!link) return;
  e.preventDefault();

  const nodes = [ 'http://127.0.0.1:8080/ipfs/', 
    'https://ipfs.io/ipfs/', 
    'https://cloudflare-ipfs.com/ipfs/', 
    'https://gateway.pinata.cloud/ipfs/', 
    'https://ipfs.filebase.io/ipfs/',
    'https://ipfs.dweb.link/',
    'https://4everland.io/ipfs/'];

  const cid = link.getAttribute('href').slice(7);
  const urls = nodes.map(n => n + cid);
  const checkForContentOnGateWay = u => fetch(u, { method: 'HEAD', signal: AbortSignal.timeout(1000) }).then(r => r.ok ? u : Promise.reject()); //HEAD only to stop on check on first byte

  // Race Local vs Public Gatway (reduce delay)
  let target;
  try {
    target = await Promise.any(urls.slice(0, 2).map(checkForContentOnGateWay));
  } catch {
    for (let i = 2; i < urls.length; i++) try { target = await checkForContentOnGateWay(urls[i]); break; } catch {}
  }
  location.href = target || urls[1];
});

Yeah, that can be implemented per Wiki, if needed. However, first we need to allow the ipfs protocol as such.

Change #1228143 had a related patch set uploaded (by Physikerwelt; author: Physikerwelt):

[mediawiki/core@master] Add ipfs:// to $wgUrlProtocols

https://gerrit.wikimedia.org/r/1228143

@fredw do you happen to know the status of Firefox's support for IPFS links ?

How do browsers handle clicks on ipfs URLs? Any security risk of downloading / executing something malicious?

Change #1234379 had a related patch set uploaded (by Physikerwelt; author: Physikerwelt):

[mediawiki/extensions/Wikibase@master] Add ipfs to urlSchemes of Wikibase-repo

https://gerrit.wikimedia.org/r/1234379

I’m not convinced this is desirable… how would spam fighting (SpamBlacklist, AbuseFilter etc.) work with these URLs, given that they don’t seem to have anything comparable to a domain to match on?

In T414731#11550902, @Tgr wrote:

How do browsers handle clicks on ipfs URLs? Any security risk of downloading / executing something malicious?

I tested the proposed change in wmcloud on the item https://dlockss.wmcloud.org/wiki/Item:Q122926707 with FF, Safari and Chromium (screenshots below). They all ask if you want to assess the link with the application installed.

In T414731#11562210, @Lucas_Werkmeister_WMDE wrote:

I’m not convinced this is desirable… how would spam fighting (SpamBlacklist, AbuseFilter etc.) work with these URLs, given that they don’t seem to have anything comparable to a domain to match on?

You can use the gateway links already now https://bafybeiemxf5abjwjbikoz4mc3a3dla6ual3jsgpdr4cjr3oz3evfyavhwq.ipfs.dweb.link/I/m/Vincent_van_Gogh_-_Self-Portrait_-_Google_Art_Project_(454045).jpg if the suggested change was merged you could get the same material independently of the provider ipfs://bafybeiemxf5abjwjbikoz4mc3a3dla6ual3jsgpdr4cjr3oz3evfyavhwq/I/m/Vincent_van_Gogh_-_Self-Portrait_-_Google_Art_Project_(454045).jpg so eventually you can apply the same technique that you apply to dweb.link links and similar gateway links.

Beyond that there are measures that go beyond that what http (or ftp, which is also supported) provide like described here https://blog.ipfs.tech/2023-content-blocking-for-the-ipfs-stack/

Sounds reasonable to me. The Security team should get a chance to veto it, though.

Change #1234379 had a related patch set uploaded (by Gergő Tisza; author: Physikerwelt):

[mediawiki/extensions/Wikibase@master] Add ipfs to urlSchemes of Wikibase-repo

https://gerrit.wikimedia.org/r/1234379