Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Direct Sockets API in Chrome 131

chromestatus.com

Post reply on HN
Print view View original

151–160 of 171 posts

Re: Direct Sockets API in Chrome 131

#151

Post by topspin »

modeless wrote: post #28
topspin wrote: post #19

Earlier quoted context omitted.

Same browser on win10. Mouse works after you click in the window and it goes full screen. However, it hangs after a few seconds of game play. Stopped hanging... then input locks up somehow. Switched to chrome on win10, same issue: input locks up after a bit.

Yeah that issue I have seen, but unfortunately haven't been able to debug yet as it isn't very reproducible and usually stops happening under a debugger.

Even with the problems, just the few seconds of playing before the crash+input hang got me hooked. So, off to GOG to get q3a for $15. Also, quake3e with all the quality, widescreen, aspect ratio and FPS tweaks... chatgpt 4o seems to know everything there is to know about quake3e, for some reason.

Talk about getting nerd sniped.

Re: Direct Sockets API in Chrome 131

#152

Post by montymintypie »

1oooqooq wrote: post #92
montymintypie wrote: post #56

Earlier quoted context omitted.

What's your recommendation? I've tried so many multiplatform toolkits (including GTK, Qt, wxWidgets, Iced, egui, imgui, and investigated slint and sciter) and nothing has come close to the speed of dev and small final app size of something like Tauri+Svelte.

of course dev speed will be better with tauri plus the literal ton of JavaScript transpilers we use today. but for us an inhouse egui pile of helpers allow for fast applications that are closer to native speeds. and flutter for mobile (using neither Cupertino or material)

Glad to hear that egui is working for you, but in my experience it's not accessible, difficult to render accurate text (including emoji and colours), very frustrating to extend inbuilt widgets, and quite verbose. One of my most recent experiences was making a fairly complex app at work in egui, then migrating to tauri because it was such a slog.

Re: Direct Sockets API in Chrome 131

#153

Post by api »

montymintypie wrote: post #152
1oooqooq wrote: post #92

Earlier quoted context omitted.

of course dev speed will be better with tauri plus the literal ton of JavaScript transpilers we use today. but for us an inhouse egui pile of helpers allow for fast applications that are closer to native speeds. and flutter for mobile (using neither Cupertino or material)

Glad to hear that egui is working for you, but in my experience it's not accessible, difficult to render accurate text (including emoji and colours), very frustrating to extend inbuilt widgets, and quite verbose. One of my most recent experiences was making a fairly complex app at work in egui, then migrating to tauri because it was such a slog.

The web stack is now the desktop UI stack. I think the horse has left the barn.

It’s not great but there’s just no momentum or resources anywhere to work on native anymore outside platform specific libraries. Few people want to build an app that can only ever run on Mac or Windows.

Re: Direct Sockets API in Chrome 131

#154

Post by Uptrenda »

ignoramous wrote: post #127
Uptrenda wrote: post #102

Earlier quoted context omitted.

Hello, I wanted to say I've been working on a peer-to-peer library and I'm very much interested in your work on symmetric NAT punching (which as far as I know is novel.) Your work is exactly what I was looking for. Good job on the research. It will have far-reaching applications. I'd be interesting in implementing your algorithms depending on the difficulty some time. Are they patented or is this something anyone can…

I read OP's thesis (which focuses on CGNAT), and one of the techniques discussed therein is similar to Tailscale's: https://tailscale.com/blog/how-nat-traversal-works ...with the help of the birthday paradox. Rather than open 1 port on the hard side and have the easy side try 65,535 possibilities, let’s open, say, 256 ports on the hard side (by having 256 sockets sending to the easy side's ip:port), and have the easy…

this comment section has been the most useful and interesting thing I've seen for my own work in a very long time. And completely random, too. Really not bad. To me this represents the godly nature of this website. Where you have extremely well informed people posting high quality technical comments that would be hard to find anywhere else on the web. +100 to all contributors.

Re: Direct Sockets API in Chrome 131

#155

Post by justin66 »

modeless wrote: post #10

I think a lot of people don't realize it's possible to use UDP in browsers today with WebRTC DataChannel. I have a demo of multiplayer Quake III using peer-to-peer UDP here: https://thelongestyard.link/ Direct sockets will have their uses for compatibility with existing applications, but it's possible to do almost any kind of networking you want on the web if you control both sides of the connection.

Not really peer to peer though, is it? The q3 server is just running in the browser session that shares a URL with everyone else?

Re: Direct Sockets API in Chrome 131

#156

Post by savolai »

synctext wrote: post #62
ignoramous wrote: post #48

Earlier quoted context omitted.

> Direct sockets will have their uses for compatibility with existing applications... In fact runtimes like Node, Deno, Cloudflare Workers, Fastly Compute, Bun et al run JS on servers, and will benefit from standardization of such features. [WICG] aims to provide a space for JavaScript runtimes to collaborate on API interoperability. We focus on documenting and improving interoperability of web platform APIs across r…

This slowly alters the essence of The Internet, due to the permissionless nature of running any self-organising system like Bittorrent and Bitcoin. This is NOT in Android, just isolated Web Apps at desktops at this stage[0]. The "direct socket access" creep moves forward again. First, IoT without any security standards. Now Web Apps. With direct socket access to TCP/UDP you can build anything! You loose the constrain…

I don’t understand the topic deeply. Is this futureproof, or likely to be shutdown in a cat and mouse game if it gets widespread, like it needs to for a social network?

Re: Direct Sockets API in Chrome 131

#157

Post by synctext »

ignoramous wrote: post #127
Uptrenda wrote: post #102

Earlier quoted context omitted.

Hello, I wanted to say I've been working on a peer-to-peer library and I'm very much interested in your work on symmetric NAT punching (which as far as I know is novel.) Your work is exactly what I was looking for. Good job on the research. It will have far-reaching applications. I'd be interesting in implementing your algorithms depending on the difficulty some time. Are they patented or is this something anyone can…

I read OP's thesis (which focuses on CGNAT), and one of the techniques discussed therein is similar to Tailscale's: https://tailscale.com/blog/how-nat-traversal-works ...with the help of the birthday paradox. Rather than open 1 port on the hard side and have the easy side try 65,535 possibilities, let’s open, say, 256 ports on the hard side (by having 256 sockets sending to the easy side's ip:port), and have the easy…

indeed, Tailscale was the first to realise this.

We added specific 4G and 5G mobile features. these carrier-grade boxes have often non-random port allocations. "By relying on provider-aware IPv4 range allocations, provider-aware port prediction heuristics, high bandwidth probing, and the birthday paradox we can successfully bypass even symmetric NATs."

Re: Direct Sockets API in Chrome 131

#158

Post by meiraleal »

rty32 wrote: post #147
meiraleal wrote: post #123

Earlier quoted context omitted.

It is used by chromeOS

You means apps written by Google as "native apps"? Any use cases outside that? If not, it is probably fair to say nobody uses this.

A PWA is a IWA so lots of people are using it besides Google

Re: Direct Sockets API in Chrome 131

#160

Post by angra_mainyu »

rty32 wrote: post #98
chocolatkey wrote: post #3

When reading https://github.com/WICG/direct-sockets/blob/main/docs%2Fexpl... , it's noted this is part of the "isolated web apps" proposal: https://github.com/WICG/isolated-web-apps/blob/main/README.m... , which is important context because the obvious reaction to this is the security nightmare

Have isolated web apps/web bundle gained any traction over the past few years? I just realized that this thing existed and there were some discussions around it -- I almost completely forgot this. I did a search, and most stuff come from a few years ago.

It makes much more sense to bundle a binary + web extension (w/ native messaging) to handle bridging the browser isolation in a sensible manner.

It's a minimal amount of extra work and would mean you cross browser isolation in a very controlled manner.

Post reply on HN