Earlier quoted context omitted.
What do you mean not going to happen? It's already happening. It's about 45% of internet packets.
Not happening for 55%. Try to connect to github.com over IPv6.
Direct Sockets API in Chrome 131
101–110 of 171 posts
Re: Direct Sockets API in Chrome 131
#102Earlier 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…
Here's a link to an over-view for my system: https://p2pd.readthedocs.io/en/latest/p2p/connect.html
My system can't handle symmetric --- symmetric. But could in theory handle other types of NATs ---- symmetric. Depending on the exact NAT types and delta types.
Re: Direct Sockets API in Chrome 131
#103Anything that moves the web closer to its natural end state— the J(S)VM is a win in my book. Making web apps a formally separate thing from pages might do some good for the web overall. We could start thinking about taking away features from the page side.
Re: Direct Sockets API in Chrome 131
#104Earlier quoted context omitted.
That changed (ahm.. will change) with ipv6. I was surprised to see that I can reach residential ipv6 lan hosts directly from the server. No firewalls, no nat. This remains true even with abusive isps that only give out /64 blocks. That said, I agree that peer to peer will never be seemless thanks mostly to said abusive isps.
IPv6 isn't going to happen. Most people's needs are met by NAT for clients and SNI routing for servers. We ran out of IPv4 addresses years ago. If it was actually a problem it would have happened then. It makes me said for the p2p internet but it's true.
https://aws.amazon.com/blogs/aws/new-aws-public-ipv4-address...
Re: Direct Sockets API in Chrome 131
#105I 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.
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
Re: Direct Sockets API in Chrome 131
#106Earlier 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…
> We utilise parallelism by opening at least 500 Internet datagram sockets on two devices. 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.
U mad. Love it!
Re: Direct Sockets API in Chrome 131
#107Earlier 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…
Re: Direct Sockets API in Chrome 131
#108Re: Direct Sockets API in Chrome 131
#109Earlier 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.
I've also tried Flutter, React Native, Kotlin multiplatform, Wails. I'm landing on Svelte and Tauri too. The other alternative I dabble with is using the Android Studio, XCode to write my own WebView wrappers.
Re: Direct Sockets API in Chrome 131
#110Earlier quoted context omitted.
The cross platform desktop gui toolkits all have some very big downsides and tend to result in bad looking UIs too.
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/