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

121–130 of 171 posts

Re: Direct Sockets API in Chrome 131

#121

Post by modeless »

flohofwoe wrote: post #78
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.

There's also this new WebTransport thingie based on HTTP/3: https://developer.mozilla.org/en-US/docs/Web/API/WebTranspor... I haven't tinkered with it yet though.

Yeah, not in Safari yet and no peer-to-peer support. Maybe someday though! It will be great if all of WebRTC's features can be replaced by better, smaller-scoped APIs like this.

Re: Direct Sockets API in Chrome 131

#122

Post by rubymamis »

rty32 wrote: post #100
rubymamis wrote: post #76

Earlier quoted context omitted.

I've built my app[1] using Qt (C++ and QML), and I think the UI looks decent. There's still a long way for it to feel truly native, but I've got some cool ideas. [1] https://get-notes.com/

You are probably not solving the same problems many other people are facing. Many such applications are accessible on the web, often with the exact UI. They may even have a mobile/iPad version. They may be big enough that they have a design system that needs to be applied to in every UI (including company website). Building C++ code on all platforms and running all the tests may be too expensive. The list goes on.

I just started prototyping a mobile version of my app (which shares the code as my desktop app) and the result looks promising (still work-in-progress tho).

Offering a web app is indeed not trivial. Maybe Qt WebAssembly will be a viable option if I can optimize the binary and users wouldn't mind first long load time (and then the app should be cached for instant load). Or maybe I could build a read-only web app using web technology.

Currently, my focus is building a good native application, and I think most of my users care about that. But in the future, I can see how a web app could be useful for more users. One thing I would like to built is a web browser that could load both QML and HTML files (using regular web engine), so I could simply deploy my app by serving my QML files without the binary over the internet.

Re: Direct Sockets API in Chrome 131

#123

Post by meiraleal »

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 is used by chromeOS

Re: Direct Sockets API in Chrome 131

#124

Post by rubymamis »

cageface wrote: post #110
rubymamis wrote: post #76

Earlier quoted context omitted.

I've built my app[1] using Qt (C++ and QML), and I think the UI looks decent. There's still a long way for it to feel truly native, but I've got some cool ideas. [1] https://get-notes.com/

That's definitely one of the best looking Qt apps I've seen.

Thank you! I think Qt is absolutely great. One need to put a little effort to make it look and behave nicely. I wrote a blog post about it[1], if you're interested.

[1] https://rubymamistvalove.com/block-editor

Re: Direct Sockets API in Chrome 131

#125

Post by nulld3v »

troupo wrote: post #95
meiraleal wrote: post #89

Earlier quoted context omitted.

Cry me a river. Apple doesn't need you to defend their strategic and intentional PWA boycott.

Which part of "is not a w3c standard and not any standards track" do you not understand? Do you understand that for something to become a standard, it needs two independent implementations? And a consensus on API? Do you understand that "not on any standards track" means it's Chrome and only Chrome pushing this? That Firefox isn't interested in this either? Do you understand that blaming Apple for everything is borde…

There are a lot of reasons why people have such extreme differing opinions on this.

I for one, am still salty about the death of WebSQL due to "needing independent implementations". Frankly put, I think that rule is entirely BS and needs to be completely removed.

Sure, there is only one implementation of WebSQL (SQLite) but it is extremely well audited, documented and understood.

Now that WebSQL is gone, what has the standards committee done to replace it? Well, now they suggest using IndexedDB or bringing your own SQLite binary using WASM.

IndexedDB is very low level, which is why almost no one uses it directly. And it also has garbage performance, to the point where it's literally faster for you run SQLite on top of IndexedDB instead: https://jlongster.com/future-sql-web

So ultimately if you want to have any data storage on the web that isn't just key-value, you now have to ship your own SQLite binary or use some custom JS storage library.

So end users now have to download a giant binary blob, that is also completely unauditable. And now that there is no standard storage solution, everybody uses a slew of different libraries to try to emulate SQL/NoSQL storage. And this storage is emulated on top of IndexedDB/LocalStorage so they are all trying to mangle high level data into key-value storage so it ends up being incredibly difficult to inspect as an end-user.

As a reminder: when the standards committee fails to create a good standard, the result is not "everybody doesn't do this because there is no standard", it is "everybody will still do this but they will do it 1 million different ways".

Re: Direct Sockets API in Chrome 131

#126

Post by anilgulecha »

FpUser wrote: post #120

All nice and welcome. At what point browser becomes full blown OS with the same functionality and associated vulnerabilities yet still less performant as it sites on top of other OS and goes through more layers. And of course ran and driven by one of the largest privacy invader and spammer of the world

> At what point browser becomes full blown OS.

Happened over a decade ago - ChromeOS. It's also the birthplace of other similar tech.. webmidi webusb Bluetooth etc.

Re: Direct Sockets API in Chrome 131

#127

Post by ignoramous »

Uptrenda wrote: post #102
synctext wrote: post #62

Earlier quoted context omitted.

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…

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 side probe target ports at random.

Re: Direct Sockets API in Chrome 131

#128

Post by evbogue »

typedef_struct wrote: post #105
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.

This looks to use Web Sockets, not WebRTC, right? I don't see any RTCPeerConnection, and the peerServer variable is unused. I ask because I've spent multiple days trying to get a viable non-local WebRTC connection going with no luck. view-source: https://thelongestyard.link/q3a-demo/?server=Seveja

Check out Trystero[1], it makes WebRTC super simple to develop with.

[1] https://github.com/dmotz/trystero

Re: Direct Sockets API in Chrome 131

#129

Post by IshKebab »

bpfrh wrote: post #66
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.

You can also use WebTransport with streams for tcp and datagramms for udp https://developer.mozilla.org/en-US/docs/Web/API/WebTranspor...

Not peer to peer though presumably?

Re: Direct Sockets API in Chrome 131

#130

Post by [deleted] »

phildenhoff wrote: post #4
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

Interesting — the Firefox team’s response was very negative, but didn’t (in my reading) address use of the API as being part of an otherwise essentially trusted app (as opposed to being an API available to any website). In reading their comments, I also felt the API was a bad idea. Especially when technology like Electron or Tauri exist, which can do those TCP or UDP connections. But IWA serves to displace Electron,…

[deleted]
Post reply on HN