Safari Support (2020)

[skyzyx]

The older approach to building extensions that was first released in Safari 5 has been deprecated. With Safari 13, all extensions are applications, which are developed as macOS apps and exposed in Safari. Building a Safari App Extension is the entrypoint to the developer documentation on this topic.

Would love to see support for this be added to the roadmap. The code should be able to align closely with any native macOS app you provide.

[lidel]

IIUC this is still a proprietary API created by Apple: Safari does not use WebExtensions APIs which are supported by virtually every other vendor (Google Chrome, Firefox, Edge, Brave, Opera etc).

This means IPFS Companion codebase can't be reused – something new, specific to Safari would have to be created.

---

Safari App Extension docs say:

[..]
When a user runs your app for the first time, the app extension immediately becomes available in Safari.

If "IPFS Safari App Extension" is to be created, it sounds like it should part of ipfs-desktop, which is our Electron-based desktop app.

Would be useful if someone already familiar with Safari App Extensions evaluated feasibility of the whole idea: given available APIs, which features of IPFS Companion could be re-implemented?

For example:

• detect a request to a public IPFS gateway and redirect it to local daemon
• provide UI for uploading files and directories
• detect network failures and recover from them by loading content from IPFS

[skyzyx]

Well yeah, they're all proprietary. They're also all fully-documented APIs that are open to the public to use and build on. But calling one API proprietary while suggesting the other is not is misleading at best. It's like saying that VP9 is "open" and H.265 is "closed" — neither statement is true.

But I'll let the semantics nerds fight over that one.

Electron won't solve the problem because it's not native code. You may be able to include it if there is an Xcode packaging step that includes the (native) extension as part of the (Electron) app bundle, but I'm not close enough to the process to speak definitively about it.

I do, however, understand that the implementing code for a Safari extension will be a second set of code that has to be maintained separately from the Electron and Chrome extension code bases. It's not "free" in terms of dev effort, and I'm certainly sympathetic to that. But as a Mac/iOS/Safari user, I wanted to at least ask.

[lidel]

Interesting development: Apple announced support for Web Extensions (Manifest V2) at WWDC 2020:

When you create a Safari Web Extension, you can help people get common online tasks done more quickly and efficiently. We'll show you how to build a new Safari Web Extension and host it on the App Store, as well as how to use the safari-web-extension-converter tool to migrate existing extensions from other web browsers like Chrome, Firefox, or Edge with very little effort.
– https://developer.apple.com/videos/play/wwdc2020/10665/

By looking at the video under link above, initial notes:

• requires macOS and XCode (there is a conversion step)
• publishing requires signing and Developer account at Apple (we could reuse IPFS Desktop one)
• not all APIs are supported (hard to tell without giving it a try, but interop problems for advanced extensions like IPFS Companion are very likely)
  • update: good news is that compatibility tables at MDN include Safari, so we can easily check if necessary API is available in Safari runtime. Bad news is that most of critical APIs are not supported yet (for example, blocking webRequest).
    • This means IPFS Companion can't run in Safari without additional work. It is possible that when Manifest V3 ships in Chrome (context: What to do about Manifest V3 #666), we will have a version that does not rely on blocking webRequest, and that could be also used in Safari.