Recent submissions

Comment · 1 year ago
Comment · 2 years ago
we're working on distributed computing for training LLMs with Socket runtime (https://github.com/socketsupply/socket).

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.

Comment · 2 years ago
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).
Comment · 2 years ago
actually using UDP is the whole point. we explain why it's superior to TCP in the guides (https://socketsupply.co/guides/#p2p-guide_how-p2p-works_why-...).

and our NAT traversal success rate is comprehensive, every known routable path actually works (check this table https://socketsupply.co/blog/the-next-chapter-in-the-story-o...)

we're actually not reinventing too many wheels here, our work is conceptually based on DTNs — cited frequently in our guides and docs.

Comment · 2 years ago
Comment · 2 years ago
Comment · 2 years ago
Comment · 2 years ago
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.

Comment · 2 years ago
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.
Comment · 2 years ago
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!

Comment · 3 years ago
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.
Comment · 3 years ago
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).
Comment · 3 years ago
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.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton