Feature request: Official Flatpak distribution for Linux (Flathub)

[NicolaeFericitu]

Is your feature request related to a problem? Please describe.

Linux distribution can be highly fragmented. New or inexperienced Linux users often face significant hurdles when trying to install applications that don't have a binary specifically built for their distribution (e.g., .deb vs .rpm vs AUR). Many users simply give up on installing IPFS Desktop because they cannot install it as easily as they do on Windows or macOS, facing dependency hell or complex terminal commands.

Describe the solution you'd like

The Request: Provide an official Flatpak release, ideally published on Flathub.

Why this is critical for adoption:

1. Universal Compatibility: Flatpak works on virtually all Linux distributions (Ubuntu, Fedora, Arch, Linux Mint, Pop!_OS, etc.) out of the box.
2. Sandbox Security: Flatpak provides a sandbox environment, running IPFS in isolation from the rest of the system, which improves stability and security.
3. Ease of Use: It offers a "one-click install" experience similar to Windows/macOS, lowering the entry barrier for non-technical users who want to join the Web3 ecosystem.
4. Immutable OS Support: Essential for modern systems like SteamOS (Steam Deck), Fedora Silverblue, or Endless OS where traditional package installation is restricted.

Benefit: Ensuring easy installation across any Linux distribution is the future of application distribution on Linux and will significantly widen the IPFS user base.

Alternatives considered

• AppImage (good, but lacks the repository integration and auto-updates of Flathub).
• Snap (often slower and less preferred by the community).
• Continuing with distro-specific packages (high maintenance burden).

[lidel]

Thanks for the suggestion! Here's where we're at with this:

• Flathub: Publishing there requires either granting broad permissions to GitHub, or verifying control of a domain like ipfs.io or ipfs.tech. Neither is straightforward for us right now, requires careful risk/complexity analysis.
• Snap: We've had a rough experience with the Snap ecosystem in the past, and the overhead of maintaining packages for centralized app stores hasn't been a good use of our limited time -- especially given our current userbase size. (For context, the Snapcraft permission model process was particularly painful.)
• Our approach: We publish a tar.xz archive that package managers can use for repackaging into their preferred formats. This lets us focus our energy where it matters most -- fixing bugs, triaging issues, and reviewing PRs.

Marking this as P3 for now. If there's enough community interest or demand, we're happy to revisit the priority.