Skip to content

feat: choose share link type, native by default#2482

Draft
lidel wants to merge 6 commits into
mainfrom
feat/share-modal-local-gateway-url
Draft

feat: choose share link type, native by default#2482
lidel wants to merge 6 commits into
mainfrom
feat/share-modal-local-gateway-url

Conversation

@lidel

@lidel lidel commented Mar 10, 2026

Copy link
Copy Markdown
Member

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

  • Settings gains a "Sharing IPFS Links" section used by both Share Link and Publish to IPNS: native ipfs:// addresses by default, local or public gateway links (path or subdomain) as opt-in
  • public gateway defaults are empty; nothing goes through ipfs.io or any other third party unless you configure a public gateway yourself
  • Share modal offers a local HTTP link checkbox, with optional localhost subdomains for web apps that need origin isolation
  • links labeled local draw from the local gateway only, never the public fallback, and https gateway hostnames stay intact for TLS
  • gateway reachability probes removed; URL format is validated and the user's choice trusted

A 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.io and 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:

Screenshot 2026-07-02 at 00-39-36 Settings IPFS

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:

1_2026-03-10_18-00

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:

2_2026-03-10_18-00

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:

3_2026-03-10_18-00

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

@guillaumemichel guillaumemichel left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested & approved

lidel added 2 commits June 30, 2026 04:20
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
@lidel lidel added the status/blocked Unable to be worked further until needs are met label Jun 30, 2026
lidel added 2 commits June 30, 2026 22:36
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
@lidel

lidel commented Jul 1, 2026

Copy link
Copy Markdown
Member Author

Pushed some related tests / changes since review:

  • Share Link and Publish to IPNS now default to native ipfs://cid (and ipns://name). Public gateways are a conscious opt-in: nothing goes through ipfs.io or any other third party unless you configure a public gateway yourself.
  • Added a "Sharing IPFS Links" settings section to choose the link type, with e2e tests for the default and each option.

So the UI still makes sense the day ipfs.io and other public gateways go away:

This is part of wider URI support to move away from copying public gateways by default:

Preview of Settings page

Screenshot 2026-07-02 at 00-39-36 Settings IPFS

@lidel lidel changed the title feat: add local gateway URL options to share modal feat: choose share link type, native by default Jul 1, 2026
@lidel lidel removed the status/blocked Unable to be worked further until needs are met label Jul 1, 2026
@lidel lidel marked this pull request as draft July 3, 2026 14:07
@lidel lidel added the status/blocked Unable to be worked further until needs are met label Jul 3, 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

status/blocked Unable to be worked further until needs are met

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants