smaddock

For what it's worth, 'contextIsolation' will become enabled by default in Electron v12 [0].

[0] https://www.electronjs.org/docs/tutorial/context-isolation#w...

The email wasn't complaining about Apple's cut of profits, but rather having their app being killed seemingly arbitrarily when Apple decided to kill a category of apps from the store.

Folks can have a good experience with the app store, until they don't. There's survivorship bias in creating an app unaffected by the ever changing app review policies.

This isn't exclusive to Apple's walled garden either.

Games can be an especially good path to explore for teenagers. There are many disciplines that come together to create something. Even while focusing on one aspect of game development, you can build a desire to pursue another.

For me, it was 3D art that got me hooked. Followed by programming to make my art do something.

Additionally, during the 3 years I've had experience with WebRTC, I've come across at least 2-3 browser bugs causing compatibility issues when connecting peers cross-browser.

This is just not something you run into with WebSockets.

I'd recommend simple-peer for anyone who does choose to use WebRTC. The maintainers are usually able to smooth these issues out in a reasonable timeframe. <3

https://github.com/feross/simple-peer

I use WebRTC and WebSockets in a side project of mine [0]. WebRTC requires coordination of multiple services and fallbacks (relay servers) when peers can't establish a direct connection due to firewalls among other things.

STUN, TURN, and ICE are a few technologies you need to understand to get started with WebRTC. I'd guess most folks aren't familiar when first looking into it.

The complexity is worth it if you're determined to push most bandwidth costs to clients like I am.

If you want near 100% connectivity at a lower complexity, WebSockets are almost always preferred.

[0] https://github.com/samuelmaddock/metastream

The WebTransport API looks to bring WebSockets up to speed with similar features provided by WebRTC: reliable or unreliable connections and multiplexing. The addition of a Stream interface means it will be efficient for uploads and downloads too.

I can see this replacing most use cases of WebSockets once brought to ubiquity.

Roblox supports modding and has a "Developer Exchange" program [0] in which, from what I understand, there's an exchange rate for each microtransaction related to modders' content.

Steam Workshop [1] is a platform for distributing mods for games which support it on Steam. A few years back it introduced support for paid content [2], but was soon after removed due to community backlash [3].

[0] https://www.roblox.com/developer-exchange/help

[1] https://steamcommunity.com/workshop

[2] https://steamcommunity.com/workshop/aboutpaidcontent

[3] https://steamcommunity.com/games/SteamWorkshop/announcements...

The channel has been restored. https://twitter.com/ChilledCow/status/1231302926611644421

This is another case where having a large, supportive audience is one of the only ways of getting Google's attention.

The project I built and mentioned in the article, Metastream [1], is used to sync videos across browsers. It now lives as a browser extension and I'm able to track which web domains are most commonly used by the app.

Based on the usage statistics for the past month (28,711 samples), these are some commonly used media websites:

1. www.youtube.com (69%)

2. www.netflix.com (5%)

3. www.crunchyroll.com (2.5%)

4. www.hulu.com (0.8%)

5. www.funimation.com (0.3%)

6. www.disneyplus.com (0.3%)

7. other (22.1%)

The app is heavily skewed towards anime which already has a problem with piracy. That said, we can at least see that approx. 9% of traffic in my app is for DRM-enabled media.

Personally, I don't think the usage statistics of DRM media matters much. It shouldn't be a requirement to consume any content on the web to begin with.

[1] https://github.com/samuelmaddock/metastream

I could see this having an impact for existing browsers with a larger marketshare. I'd be worried if Firefox were to start and we'd see their influence drop. That would be the unfortunate reality of affecting the user experience of accessing media streaming websites.

I posted on a Google forum recently and got two BitBounce replies in an hour, presumably from users autosubscribed to new threads. I'm going to need to start blocking all replies with the BitBounce template.

I previously developed a consumer, Electron-based desktop application in the last year. One of the thing I was unaware of going in was the cost of code signing certificates. To support Windows and macOS it cost me around $200/year to avoid the OS showing a security warning when opening the application.

The Windows code signing certificate I have is an OV certificate which means it builds up trust over time before the installation security warning goes away. It seemed to go away within a week of release, but was still frustrating to deal with. An EV certificate skips the trust building step and can be purchased for about 5x the cost.

A couple months ago I switched to a Progressive Web Application (PWA) which reduced costs and removed the installation requirement. There are capabilities lacking in web applications, but there are planned features such as native file system API [1]. Hopefully these also make their way into Firefox and others. No desktop PWA support in Firefox at all yet.

[1] https://developers.google.com/web/updates/capabilities

This seems be directed at creators interested in their platform, which would be their audience at this stage. The "algorithm" on YouTube can decide whether or not a video will be discovered. Guaranteeing that subscribers will see their recent content could be a good selling point.

The issue I ran into was in acquiring the necessary licenses that you mentioned. Verified Media Path (VMP) can be used to verify the authenticity of the browser platform. I believe it uses public key cryptography for identification by Widevine's license servers.

It seems like it would be trivial for Widevine to revoke access if there were ever abuse.

I have more details in a blog post I wrote last month. https://blog.samuelmaddock.com/posts/google-widevine-blocked...

Vivaldi builds on top of Chromium. All Chromium browsers will eventually receive these extensions changes as well unless they fork their codebase. Most of them support extensions via the Chrome Web Store though which means they'll need to adopt Manifest V3.

Fortnite is one of the few games that is available on all major platforms, including mobile, which allows online cross-play. I believe its accessibility, cost, and scarcity of alternatives is what makes it appealing to younger audiences.

The portability of Unreal Engine 4 places Epic Games in a unique position where they can deliver this kind of experience.

Sorry for the late reply. Building Metastream as a web browser instead of a web extension was a complexity burden created solely by myself.

One of the main requirements I wanted was the ability to use the app with as little centralized dependencies as possible. P2P is the primary way to connect to users with the app, but even that requires a centralized signaling solution which is prone to downtime. To mitigate this, users can also directly connect to an IP address with the appropriate ports forwarded. Listening on a socket is not supported by a web extension at this time.

Additionally, some actions on the web require a "user gesture" to be performed such as fullscreening a video. I created an auto-fullscreen feature by simulating a user gestured mouse click. It also only fullscreens within the frame of the window instead of the entire screen. [1]

Other features not possible with a web extension/app include local file reading (potential future feature) and Discord Rich Presence (currently implemented).

[1] https://github.com/electron/electron/pull/17203

At one point I did try this, but it ends up being a much more complex solution. It turns out it's fairly difficult to ensure the element appears above every other element. I was using 'position: fixed' with the maximum z-index value.

I've updated the article to include the email exchange, check the edit at the bottom.

Every user in a session will see the same playback timestamp for a video.

There might be potential for Microsoft's PlayReady DRM with their move to a Chromium-based browser. I contacted them while waiting to hear back from Widevine and got this response.

> For Windows Electron/Chromium will not work with PlayReady at this time. I have provided your feedback to the engineering team for future planning. Currently PlayReady can be integrated in a PWA/(Windows Store HTML/JS app) and there would be no royalties on Windows.

This is true, but isn't always possible if you want to ship within a reasonable time frame.

There are some features which make a desktop application more appealing to me. One feature required changing browser behavior [1] which wouldn't otherwise be possible.

A WebExtension could work, but has potential to run into the same gatekeeping issue of being removed by Google from their Web Store. With Google having ~70% market share, this wouldn't be a good outcome.

[1] https://github.com/electron/electron/pull/17203

Sorry to hear that. Hopefully something comes out of this which can improve the process for all of us. :(

This is also the case for Brave browser, a dialog opens asking to download the binary. I suspect this is also the case with other Chromium browsers, they may do it without prompting though.

I don't see the issue here, no video or audio content is being streamed. It's only state such as time and play/pause.

I'm not aware of Castlabs fork working without a production build [1]. I don't think there would be a way for open source users to be able to use a production signed release. Still waiting to hear back more from Widevine.

[1] https://github.com/castlabs/electron-releases/issues/33#issu...

It doesn't. It transmits playback state, but doesn't stream any video or audio content. Each user needs to be logged into web services on their own client.

Those were my initial thoughts, Google misunderstanding how Metastream works. It only sends playback information, no streaming of video/audio content. Each user needs to be logged into their own session on each web service.

I asked for a license agreement to use the Castlabs fork of Electron, which supports Widevine. https://github.com/castlabs/electron-releases