This looks really promising, this should run in any web-like environment right? Specifically it might be interesting to build a Socket App with this (https://github.com/socketsupply/socket)
Thanks -- we got hello world with Socket, but there's some interesting open source work we'll need to do to support peers acting as servers and take full advantage of the network.
If anyone wants to join the effort, the semantics we are talking about are also aligned with WebRTC delivery, so you'd enable a bunch of p2p topologies with your contribution.
Our ultimate goal is to provide a web browser-compatible environment (for quickly building UIs) with a state of the art P2P protocol — A DTN design that is delay, fault, and partition tolerant, with comprehensive and complete NAT traversal, without any server or cloud infrastructure requirements from the user — lowering the technical and monetary barriers for distributing and parallelizing work beyond the cloud. Our native plugin system was designed to easily support projects like llama.cpp which makes it simple to load any LLM and expose JavaScript APIs over it.
Looks like an interesting project. When I was building my library I considered UDP hole punching but decided to focus exclusively on TCP because of how bad UDP is to work with. The issue with UDP is you're going to have to write a poorman's TCP stack on top of it.
The approach used by this library for NAT determination also seems to be an over-simplification of how NATs work in routers (which is the same problem that Libp2p has) and will result in having hole punching code that barely works. Some properties to consider:
- delta type -- this refers to how the NAT assigns external ports for mappings
- delta value -- this refers to any known patterns observed in the mapping
- nat type -- no NAT, UDP firewall, full cone nat, etc
There are special rules for how traversal can be accomplished depending on the variables above. It's quite complex. But supporting it all greatly increases the chance of punching success.
Another issue I see with this library (and this is personal preference) is the massive amounts of re-inventing the wheel (again -- Libp2p and Protocol Labs are notorious for this.) It seems like there are many custom protocols that you've built into your software but most of what you've built is already part of standard Internet protocols (e.g. STUN)
No offense but your table is kind of deceptive. Obviously you can route between anyone if your strategy is to fallback to using a proxy server. Libp2p do the same thing specifically for the same reason [simplistic code.] But the whole point of p2p networking is to not require one. The reason delta enumeration is important is because the information can allow you to support more restrictive NATs without needing a proxy server. It's more work to write the NAT code and more testing but it is worth it.
nope. it's not a fallback server, if you read our docs you'd see it's using another actual peer, but also many of the other cases are not routable in other libraries such as libp2p (which does fall back to servers in most cases).
We dont have a tutorial for that yet, but we have reached a stable point with the p2p protocol and all the foundation has been laid for doing audio and video. Soon we will be releasing an open source project that demonstrates how to use the p2p protocol. You can sign up for the beta here: https://socketsupply.co/relay/
Hello HN! Creator and co-maintainer of the Socket runtime here. This project is new, and it's very ambitious, so I'm here to answer any and all questions. Some of the key take-aways are...
- A focus on Web Devs (No new languages to learn)
- A runtime, not a library (All developer code is encapsulated)
- Provide a secure context that loads like local web server (to make it easy to bring existing code, and use it like a web developer)
- Normalize native platform features like Bluetooth and UDP sockets - Normalize differences between wkwebview and Webview2, and provide things like a unified WHATWG fetch method and URL class.
- Provides new kinds of communication protocols (like P2P)
Please visit the post for more details and give it a star on GitHub to show your support. Cheers!
We officially support iOS, Android, MacOS, Linux, Windows, XBox, Android TV, and unofficially a few others that are in-progress (Apple Watch, ChromeOS). We should definitely put a list somewhere on the site.
Seems like Socket's mobile platform support is more mature than Tauri's to me. Are there other benefits to solo devs or small teams choosing Socket over Tauri beyond that and not having to write Rust to interact with the underlying system?
The development pattern with Socket runtime is dramatically simpler and more secure than Electron or Tauri because we've made the Main process optional. When you build an Electron app, for example, you spend a huge amount of time and energy marshaling data between the UI and the Main process. You end up essentially designing your own routing system. That can be a lot of work to maintain.
In terms of security, an optional Main process means a smaller surface area to worry about when considering your end-user's safety.
Historically, the super strict separation of UI and Main was implemented as a security precaution. For example, you didn’t want the front end doing naughty things to your file system, because after all, who knows when a rouge request might be somehow injected or some data may be unescaped. But in reality it didn't resolve the problem, it just moved the risk into Main - where the same problems still exist, because Main is an arbitrary binary with many most likely unaudited, transient dependencies, and unmitigated access to the OS.
We reduced the overall surface area and locked it down with CSP (a web standard) to granularly control 100% of the native capabilities. In other words, there is less solution-specific ceremony to spend time on, you get to focus on your real problems.
Yes! It will definitely work in Socket runtime. We don't have an example of how to use Qwick, we have examples of how to use React, Next, Vue since they are some of the most well known frameworks (https://github.com/socketsupply/socket-examples/tree/master/...).
Pretty much any code that runs on the Web will "just work" in Socket.
It was just open sourced, if your pointing out how few stars it has. It also hasn't been officially announced. But HTML, CSS, and JS are far less niche than Rust.
There is also a brand new one called Socket which is similar to Tauri but doesn’t require knowing any Rust. It does all 5 platforms and it’s just pure HTML, CSS, and JS. It’s announcing a stable release on the 15th.
You should probably disclose that you're the primary developer.
The name seems like a terrible idea, as it's so generic and unsearchable. It will be hard to find help with things, even if it becomes more widely used. The peer-to-peer stuff seems interesting, but the documentation is incomplete. Elsewhere the documentation says "It’s built from scratch, 1000 lines of code", but it's way more than 1000 lines (and it would have to be).
Electron, Node, and Bun are also pretty generic and unsearchable. As to the rest of your comment, the p2p component is less than 1000 lines of code. And, as I said it hasn't had an official release yet (due on the 15th).
But socket already has a well-established meaning in software. I think even if you succeed with that name, it will be at the unnecessary cost of making network programming more difficult for everyone. It's easy to choose a unique name (even "SocketEngine" might do), and now is the time to do it.
Oh, that component is <1000 lines, got it.
Whether or not it's officially released, you are already promoting it as an alternative to much more established options, so you should expect people to compare on the same terms.
We've set expectations very clearly in that it's pre-release status with the intent to compete with Electron and similar projects. Node is an extremely common word in software for example, but it's not a problem because people generally apply context to their searches.
There is a brand new one called Socket, it’s more targeted at web developers - no rust or anything required. Backend is also completely optional. It supports all mobile and desktop — it will ship a stable release next month: https://github.com/socketsupply/socket
New to me, had a quick check, Android is not yet supported, and it focuses on peer-to-peer(via bluetooth?). again using webview to do html-ui on desktops is feasible(tauri,wails,webview-c++), the interesting part is how to do that on mobile phone(without using flutter, or ionic)?
if you don't want to learn yet another new framework (flutter), or write native apps, the only option seems to be ionic, how is socket different, is the selling point here p2p instead of client-server otherwise it works just like ionic?
No, Android is fully supported, we’ve even built a demo for Android TV :D p2p is made possible by exposing UDP and Bluetooth as JS APIs (also supported on iOS and Android) but it’s entirely optional. Ionic uses electron for desktop, so you end up with two major frameworks mashed together. Socket was designed from the ground up for desktop and mobile.
