Feat/pb 6323 public link sharing on desktop

[AlexisMora]

What has been changed/Added

This Pull Request adds public-link sharing from the File Explorer context menu. When the user right-clicks a single file or folder inside Internxt Drivet, a new Copy Internxt share link option is displayed in the primary context menu.

The context-menu entry is implemented as a native C++ IExplorerCommand, which is the Windows API required for commands in the primary Windows 11 context menu. The command is hidden for items outside Internxt Drive, the root itself, empty selections, and multiple selections. Its is translated into English, Spanish, French, and German, and the Internxt icon is embedded directly in the DLL.

The native command intentionally performs very little work. When clicked, it sends the selected filesystem path to Electron through a Windows named pipe and returns immediately. This prevents File Explorer from waiting. I chosed this because both processes run on the same machine and only need to exchange a single filesystem path per click. Unlike an HTTP server, it does not require opening a TCP port, selecting and managing a port number, or exposing a network-accessible endpoint

Electron starts the named-pipe server once during application startup. It validates and decodes the UTF-16 path received from the extension, and resolves the local placeholder to its Drive UUID and item type.

Then, we create the public share link using the same general process as Drive Web. It generates a URL-safe share code, encrypts the mnemonic and code, creates the sharing entry through the Internxt SDK, decrypts the returned sharing code, and builds the final public URL. The resulting link is copied to the clipboard, and a native Windows notification reports whether the operation succeeded or failed (Its also has been added English, Spanish, French, and German translations).

Registering a command in the Windows 11 primary context menu requires more than copying the C++ DLL into the application. Windows must know which COM class the DLL exposes and where File Explorer can load it from. COM is the Windows mechanism used by File Explorer to discover and instantiate our IExplorerCommand. This registration is declared through a sparse MSIX. A regular MSIX would package and install the complete application, but Internxt already uses NSIS as its installer. A sparse MSIX lets us keep NSIS for installing the Electron application while using MSIX only to provide the Windows package identity and context-menu registration metadata. The MSIX points to the native files placed by NSIS under resources/context-menu.

MSIX is Microsoft’s Windows application packaging format. Besides distributing application files, an MSIX manifest can declare an application’s identity and Windows integrations such as COM servers and File Explorer commands

The DLL and minimal host executable are compiled with MSVC, Microsoft’s C++ compiler and build toolset. The build script discovers the installed MSVC toolset dynamically, following the existing native-project approach.

The context-menu files are installed in an isolated resources/context-menu directory. This prevents the sparse MSIX from changing permissions across the main Electron installation, The directory also contains a minimal host executable required by the MSIX package identity. It does not execute any sharing logic.

npm run package now produces a complete development installer. It builds the application and native extension, signs the required artifacts with a development certificate, bundles them, and generates the NSIS(Electron) installer. During installation, NSIS trusts the public development certificate when necessary and registers the MSIX(The one needed for the extension). Uninstalling the app removes both the extension registration and that specific certificate.

File Explorer may need to restart before showing the new command. The installer does not restart it automatically because doing so would close the user’s Explorer windows. The command appears after Explorer restarts naturally, after signing out, or after rebooting ( I have commented out the code just in case we end up needing it).

The release pipeline follows the equivalent production flow using DigiCert. It signs the native files, generates and signs the MSIX, builds and signs the final installer, and updates latest.yml.

The remaining validation is running the Windows release workflow and checking the DigiCert-signed production installer.

[github-actions]

This PR changes 2027 lines.

If it contains multiple concerns, consider splitting it. Large PRs are fine when the changes are mechanical, intentionally grouped, or belong together as part of the same feature.

Please make sure the PR description gives reviewers enough context about what matters most to review.

[sonarqubecloud]

Quality Gate failed

Failed conditions
71.6% Coverage on New Code (required ≥ 80%)
B Reliability Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE