feat: choose share link type, native by default#2482
Draft
lidel wants to merge 6 commits into
Draft
Conversation
allow copying local gateway links for use in external apps, with optional localhost subdomain mode for web apps - actions.js: doFilesShareLink returns local and subdomain links - ShareModal: checkbox to toggle local link, nested checkbox for localhost subdomains, QR hidden in local mode - Modals: passes new link variants to ShareModal - en/files.json: added translation keys for new UI elements
The share modal's local links flow through selectGatewayUrl, so the Local Gateway URL override added in #2486 reaches them. Subdomain links are offered only for domain gateways, since subdomain gateways cannot resolve on a bare IP such as 127.0.0.1. - files.js: add getLocalLinks, deriving both links from the gateway url (host, port, scheme); gate the subdomain link to domain hosts and to CIDs that fit a 63-char DNS label; share filename and base32 logic with getShareableLink - actions.js: build the local links via getLocalLinks - share-modal: clear the subdomain choice when the local link is unchecked, so it cannot silently reapply - protocol.ts: type the share-link result as ShareLinks, not string
Refine the local gateway share links so they resolve from other apps and never leave the modal hanging when generation fails. - files.js: a single loopback check in getLocalLinks drives both links, so the path link uses 127.0.0.1 (no DNS) and the subdomain link uses localhost (origins need a hostname); domain gateways and non-loopback IPs are left as-is - modals: catch a failed link generation and show an error instead of a stuck "Generating..." - en/files.json: add the error string; mark the plain link as HTTP
Share Link and Publish to IPNS copy native ipfs:// and ipns:// URIs by default, with opt-in HTTP gateway links for cases that need them. - add a Settings "Sharing IPFS Links" section to choose the link type: native, local path/subdomain, or public path/subdomain - public gateways default to empty and are opt-in; a public option stays disabled until its URL is set, and clearing it reverts to native - native URIs use canonical CIDv1: base32 for /ipfs, base36 libp2p-key for /ipns; the same choice drives Publish to IPNS - local links normalize loopback per type: 127.0.0.1 for path, localhost for subdomain - remove online gateway reachability probes; previews, thumbnails, IPLD explorer and IPNS links load from the local gateway (override or Kubo config), never a third-party gateway unless configured - consolidate the localhost to 127.0.0.1 subresource fix across previews, thumbnails, downloads, CAR links and pinning icons - Explore links honor the configured gateways; a local gateway change refreshes previews at once and reloads the explorer on the next visit
Member
Author
|
Pushed some related tests / changes since review:
So the UI still makes sense the day This is part of wider URI support to move away from copying public gateways by default:
Preview of Settings page
|
This was referenced Jul 1, 2026
Share modal and content links labeled as local could point at the public path gateway when the Kubo config exposed no usable gateway address. Local links draw from the local gateway only (user override or Kubo config), with related fixes and cleanups: - loopback host rewrites apply to http only, so an https://localhost gateway keeps its certificate-valid hostname - a link type without its gateway resolves to native before building, removing per-caller fallbacks in share and publish flows - open-in-new-tab links (file preview, IPNS keys) honor the local subdomain choice from Settings for per-CID origin isolation - pinning service icons resolve against the current gateway at read time and are omitted when no gateway is configured; previews and thumbnails skip gateway embeds in the same case - shared toLoopbackIpUrl and GatewayForm replace per-site localhost rewrites and three near-identical gateway forms - re-saving an unchanged Local Gateway URL no longer schedules an Explore page reload
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

Problem
Share Link always built a URL on a third-party public gateway (dweb.link, with ipfs.io fallback), even for people who never chose one, and Publish to IPNS hardcoded the public path gateway. There was no way to copy a link pointing at your own node for other apps on the same machine (ipfs/ipfs-desktop#2500). The webui also probed gateways with image loads on startup and in Settings.
Fix
ipfs://addresses by default, local or public gateway links (path or subdomain) as opt-inipfs.ioor any other third party unless you configure a public gateway yourselfA type whose gateway is not configured falls back to a native address, so copied links are never empty or broken, and the UI still makes sense the day
ipfs.ioand other public gateways go away.This is part of wider URI support to move away from copying public gateway links by default:
Demo
New "Sharing IPFS Links" section on the Settings screen:
For existing users who chose a specific public gateway on the Settings screen, the UI looks the same, and the new checkbox is opt-in:
Once clicked, we update UI to indicate this is no longer for sharing with friends, and only other apps on the same machine. We use IP-based Path gateway that is known to work everywhere:
Subdomain gateways do not work on all platforms, and only benefit web contexts (browser web apps, websites with relative paths etc), so are opt-in: