Seems we have some magic in Chromium implementation of ipfs:// and ipns:// that makes
ipfs://docs.ipfs.tech correctly redirect to /ipns/ namespace.
While this sounds like useful, it perpetuates incorrect URIs in the wild:
I personally had to reach out to well-meaning authors of some blogposts in the community to fix ipfs//example.com into ipns://example.com because both work in Chromium with Companion, and its easy to miss one letter difference.
Produce intermediate error page which explains that ipfs:// should be only used for immutable identifiers and mutable pointers like cryptographic IPNS rcords and DNSLink domain names should use ipns://.
It should have big green button "Continue to ipns://example.com →" that allows user to get to the correct destination with minimal disruption.
Problem
Seems we have some magic in Chromium implementation of
ipfs://andipns://that makesipfs://docs.ipfs.techcorrectly redirect to /ipns/ namespace.While this sounds like useful, it perpetuates incorrect URIs in the wild: I personally had to reach out to well-meaning authors of some blogposts in the community to fix
ipfs//example.comintoipns://example.combecause both work in Chromium with Companion, and its easy to miss one letter difference.Solution
This is specific to Chrimium handling of
ipfs://, which still theq=hijack hack described hereProduce intermediate error page which explains that
ipfs://should be only used for immutable identifiers and mutable pointers like cryptographic IPNS rcords and DNSLink domain names should useipns://.It should have big green button "Continue to ipns://example.com →" that allows user to get to the correct destination with minimal disruption.