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

From a Security perspective, we do not recommend enabling the ipfs:// URL scheme on Wikimedia projects as this is considered a HIGH privacy risk.

IPFS retrieval relies on a decentralized peer-to-peer network and/or third-party gateways outside of WMF control. As a result, users who access such links may disclose their IP addresses and request metadata to unknown peer nodes or gateway operators whose logging practices, jurisdictions, and data retention policies are not transparent.

Additionally, IPFS is designed for durability and content immutability. Once material is distributed, it may remain accessible indefinitely as long as any node continues to host it. This creates a persistent pathway to content that may contain personal data or other privacy-violating material (e.g., leaked datasets or doxxing archives) that cannot be removed or remediated through WMF governance, moderation, or legal processes.

I'm going to close this out for Security but please feel free to reach out if you have any further questions, thank you!

Just to confirm - are we still ok with allowing the ipfs over http links mentioned in T414731#11562997?

@aranyap thank you for your review.

IPFS retrieval relies on a decentralized peer-to-peer network and/or third-party gateways outside of WMF control. As a result, users who access such links may disclose their IP addresses and request metadata to unknown peer nodes or gateway operators whose logging practices, jurisdictions, and data retention policies are not transparent.

That is correct. Whenever, you click on a link with your browser you disclose your IP unless you disguise it. Whatever method you use for HTTPS connections you can use to connect to your trusted IPFS gateway for maximum privacy. In particular, WMF could also decide to host an IPFS gateway.
If you run your own IPFS node, you publicly ask to get a certain content. This is similar to clicking on a http (without s) link. However, unlike HTTPS, IPFS guarantees that the content that was linked is delivered, instead to get content from someone who currently owns the domain that was used when the link was created. IPFS links to badbits should be removed from the version history like any other files or textual elements that violate WMF policy. Here IPFS`s advantage is that content moderation does not need to be repeated.

Additionally, IPFS is designed for durability and content immutability. Once material is distributed, it may remain accessible indefinitely as long as any node continues to host it. This creates a persistent pathway to content that may contain personal data or other privacy-violating material (e.g., leaked datasets or doxxing archives) that cannot be removed or remediated through WMF governance, moderation, or legal processes.

True, hashes of of badbits should be removed, like the badbits itself (for example bad images are removed from Wikimedia commons regularly). In addition, like it is a common practice with GIT (that also uses hashes as well) sensitive data such as private keys or passwords need to be invalidated after being exposed to the public. Unlike sharing of bad content via HTTPS where filenames are often used to identify content people looking for those bad contents do not need to be afraid of viruses or any other content that is even worse than the content they were hoping for originally. This might lower the bar for people with criminal intentions to search for illegal content on IPFS. See https://www.usenix.org/system/files/usenixsecurity24-sokoto.pdf for additional background.

In conclusion, I understand that for most users relying on a IPFS gateway seems preferable and adding the repetitive and time-dependent information on the gateway is preferable over the public request for a particular content.

Change #1234379 abandoned by Physikerwelt:

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

Reason:

See https://phabricator.wikimedia.org/T414731

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

Change #1228143 abandoned by Physikerwelt:

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

Reason:

See https://phabricator.wikimedia.org/T414731

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

@Aklapper do you know how to unlink the accidentally liked paste P4945?

I do not think you can unlink mentions.