simple-peer VS A-Frame

Disclosure: I'm the author of WebTorrent.

It's so fulfilling to see WebTorrent still popping up on Hacker News after all these years. I started the project in 2013 and devoted most of my 20s to working on it, ultimately becoming a full-time open source maintainer, and writing hundreds of npm packages including buffer (https://github.com/feross/buffer), simple-peer (https://github.com/feross/simple-peer), and StandardJS (https://standardjs.com/).

I started WebTorrent with the goal of extending the BitTorrent protocol to become more web-friendly, allowing any browser to become a peer in the torrent network. Within less than a year of starting the project, I got WebTorrent fully working. And it worked _well_, beating many native torrent apps in terms of raw download speed and the ability to stream videos within seconds of adding a torrent.

WebTorrent never got as much attention as the cryptocurrency projects selling tokens throughout the mid-2010s, even though WebTorrent actually worked and had more real users than almost all of them :) I was never tempted to add a crypto-token to WebTorrent, despite many well-meaning friends telling me to do it. Nonetheless, WebTorrent served as an accessible on-ramp to the world of decentralized tech, along with other projects like Dat (https://dat-ecosystem.org/) and Secure Scuttlebutt (https://scuttlebutt.nz/).

But WebTorrent is more than a protocol extension to BitTorrent. We built a popular desktop torrent client, WebTorrent Desktop (https://webtorrent.io/desktop/), which supports powerful features like instant video streaming.

We also build a `webtorrent` JavaScript package (see https://socket.dev/npm/package/webtorrent) which implements the full BitTorrent/WebTorrent protocol in JavaScript. This implementation uses TCP, UDP, and/or WebRTC for peer-to-peer transport in any environment – whether Node.js (TCP/UDP), Electron (TCP/UDP/WebRTC), or the web browser (WebRTC). In the browser, the `webtorrent` package uses WebRTC which doesn’t require a browser plugin, extension, or any kind of installation to work.

If you’re building a website and want to fetch files from a torrent, you can use `webtorrent` to do that directly client-side, in a decentralized manner. The WebTorrent Workshop (https://webtorrent.github.io/workshop/) is helpful for getting started and teaches you how to download and stream a torrent into an HTML page in just 10 lines of code.

Now that WebTorrent is fully supported in nearly all the most popular torrent clients, including uTorrent, dare I say that we succeeded? It's been a long and winding journey, but I'm glad to have played a role in making this happen. Special shoutouts to all the open source contributors over the years, especially Diego R Baquero, Alex Morais,

P.S. If you're curious what I'm up to now, I'm building Socket (https://socket.dev). And there's actually a WebTorrent connection, too. Socket came out of a prior product we built called Wormhole (https://wormhole.app), an end-to-end encrypted file transfer application built using WebTorrent under-the-hood (Show HN thread: https://news.ycombinator.com/item?id=26666142). Like Firefox Send before it, security was a primary goal of Wormhole (see security details here: https://wormhole.app/security). But one area where we were lacking was in how we audited our open source dependencies. Like most teams building a JavaScript app, we had a large node_modules folder filled with lots of constantly updating third-party code. The risk of a software supply chain attack was huge, especially with 30% of our visitors coming from China. As most teams do, we enforced code review for all our first-party code. But similar to most teams, we were pulling in third-party dependencies and dependency updates without even glancing at the code (this is something that almost every company does today). We knew we needed to do better for our users. We looked around for a solution to analyze the risk of open source packages but none existed. So we decided to build Socket.

Socket helps developers ship faster and spend less time on security busywork by helping them safely find, audit, and manage OSS. Socket provides a comprehensive open source risk analysis. By analyzing the full picture – from maintainers and how they behave, to open-source codebases and how they evolve – we enable developers and security teams to identify risk from malware, hidden code, typo-squatting, misleading packages, permission creep, unmaintained or abandoned packages, and poor security practices. For one quick example, take a look at the risks we identified in this Angular.js calendar library: https://socket.dev/npm/package/angular-calendar/issues/0.30....

Thanks for trying it out!

The frontend is built with Svelte. This was my first time using the framework and I found their website super helpful: https://svelte.dev/docs

Used Mapbox API and geolib (https://github.com/manuelbieh/geolib/) for building routes and for other geospatial tasks.

"Talkie" was built with simple-peer (https://github.com/feross/simple-peer) and WebRTC. Great tutorial can be found on MDN: https://developer.mozilla.org/en-US/docs/Web/Guide/API/WebRT...

On the backend I use Vercel's serverless functions which are mostly acting as trivial proxies for various open API's.

Feel free to email me if you need more info.

I use simple-peer package: https://github.com/feross/simple-peer. They got good documentation and examples to get started. One thing is that you need to know more about creating signaling server to establish connection between peers - I use socket.io for that.

I am trying to implement a video chat app using simple-peer library. I am using the stream channel to exchange webCam videos of peers. And for text messaging I am using the data channel from simple peer. I implemented the video streaming part using the stream channel and it works perfect as I wanted to. But when I tried to add the text chat functionality and used the data channel to exchange messages between peers the stream channel does not work fine and all the socket connection between peers breaks up. Also again if I remove the data channel snippet from the code everything works fine. I also raised an issue on simple-peer's repo: https://github.com/feross/simple-peer/issues/899

Our team got off the ground really quickly using https://github.com/feross/simple-peer to handle the majority of the WebRTC client implementation. We're sending video and voice, so websockets aren't feasible. I'd say it was a lot easier than I expected coming in cold, and about 95% of connections establish quickly and don't have any problems.

However for that remaining 5%, I have a lot to learn. Using an abstraction is great when it works, but I'm interested in going through OP's project to get a better sense of what's happening when things go wrong.

For the VoIP part you would look up tutorials on creating your own VoIP server and clients. This is the part where you would have to research a ton when you're not familiar with a technology. Looking into it a bit, CrewLink seems to mainly use a library called simple-peer to connect people together and pass audio between them.

It is using the simple-peer library to manage the peer connections. You can open the share url in a separate tab if you want to try it locally. If you know how to use the developer tools you can see it is not uploading to a server. The only thing my server is doing is creating a websocket connection initiating the peer connection then it closes the socket. Everything else is done on the browser without the need of a server.

Custom peer-to-peer video call implementation can also be done using vanilla webrtc or https://github.com/feross/simple-peer but using an SFU such as Janus can help

Not an expert here but have some experience with it:

Assuming that each peer is connected to every other peer via a mesh network [see this image for reference: https://github.com/feross/simple-peer/blob/master/img/full-m...], each outgoing stream (esp. audio / video) is likely going to be duplicated, per recipient.

Scalability over a mesh network is fully dependent on CPU and network performance of all of the connected devices, and I'd doubt it could handle 12 participants if there is video involved, unless all participants are running relatively high-end and modern devices, with optimal network conditions.

You'll need a SFU or an MFU running on the server to handle larger rooms, while enabling all connected devices to only have to send one output stream per media type, regardless of how many connected participants there are.

I looked at it seriously for content authoring but gave it up.

The big problem is you cannot import images, textures, 3-d models and such from ordinary tools. You have something like constructive solid geometry to work with but only so much and there is a slider you can use to set the number of players and the more players the less geometry you can use.

I want to make worlds based in photographs (particularly pano and stereo) and art. McDonalds needs to put a Coca-Cola logo on the side of the cup. Either way it is a non-starter.

HW supports collaboration (more than one person shares the world) but https://aframe.io/ lets me make the content I want. If I have to choose one or the other I am going to pick the second.

My take on Meta Quest is that it seems highly successful as a gaming environment based on an app store but is skews towards single-player experiences. Like a lot of AAA games, the excellent Asgard’s Wrath 2 has some multiplayer tacked on but it is all meaningless like leaderboards and the occasional ghost that shows up in a procedurally generated dungeon.

Of course, Meta wants to make multiplayer experiences but somehow they just can’t do it.

... I remember inventing signals circa 2005 for a knowledge graph editor I worked on in GWT back when I didn't care about knowledge graphs. Not long after that I was using similar concepts to develop a complex Silverlight decision support application for sales territories.

I'm still a little appalled that people have forgotten how to make HTML form applications like we made in 1999 and frequently use React for things that don't really need it. React has, I think, one of the most elegant methods of implementing a widget set ever invented (sure beats XAML, FXML, Visual Basic, etc.) but it doesn't support a real answer to maintaining application state that would be adequate for applications as complex as RIAs made by early adopters in 2005.

My favorite use for React is

https://aframe.io/

which works like a cross between VRML and Unity Framework. Here you can easily build a virtual world that people can experience with desktop, mobile and VR headsets. Something you can't do with HTML forms!

I have a few side projects based on HTMX but I am pretty sure we will see something like it but better soon. In particular back end frameworks need to be updated for the new reality. Often you have a "component" like a dropdown box which can either be drawn as part of a bigger page or updated on its own and you really need some way you can reuse the HTML template for those purposes and hopefully also reuse associated code that does database lookups and such.

A lot depends on what kind of app you want to build.

For my current side projects I am interested in two kinds of technology.

(1) ML-enhanced apps that involve sorting and classifying content. Here I am drawing everything in the back end and using HTMX to partially update the screen to, for instance, create modal dialog boxes. The point here is that I want to quickly add new UI tasks and it will not be so quick if a front end build process is involved. (Notably in my system you can roll out a new task on the back end without reloading the front end)

My back end is Python which I am souring on. The basic problem is that it does not have threads. So if I have a 1GB ML model and a celery with 32 processes I could waste memory with 32 copies of the model. There are ways of working around all this but if I was just using Java, one copy of the model could be shared by any number of threads. Java doesn’t have the ML libraries though.

The general principle here is that the vast majority of React apps are just ordinary form processing apps that could be developed using the methods we used back in 1999 and seem to have either forgot or never learned (if we are young.). You could make the case that DX and UX were better then.

(2) Virtual reality applications using

https://aframe.io/

here there is no back end. With these tools you can make a world that is browsable with an ordinary web browser but put on a VR headset and you are there. This is another counter to the boring React app because it is something you could never do with an frontendless site.

Meta Quest also has full support for WebXR which lets you bypass all the app store BS. You can use this framework to make worlds visible on most XR headsets as well as desktop and mobile

https://aframe.io/

My understanding is that Apple is making excuses about being slow to support WebXR.

Meta Quest. It even runs on Android. For that matter, so does Magic Leap 2. If they deign to do so all the "usual suspects" who make Android phones could make Android-based VR headsets.

As much as the media has been obsessed with the train wreck that is Horizon Worlds, it's a well kept secret that Meta Quest has an app store that works like the app store on a game console. You can even sideload phone, tablet and TV apps and they "just work" most of the time.

There is no working "metaverse" and even meaningful multiplayer games are thin on the ground, but no shortage of good single-player games and what I'd call game-adjacent apps.

It's little recognized that XR apps are highly portable because they are almost always based on portable frameworks like Unity. In fact, just about every XR headset supports WebXR which makes it outright easy to make web-based virtual worlds

https://aframe.io/

these work with desktop, phones and tablets as well as most of the AR and VR headsets. All it takes is that you "think different" and choose to live life outside the app store.

WebXR is pretty amazing. You can make a site with

https://aframe.io/

which can be navigated with a browser on desktop and mobile. Using a VR headset you can give permission and… you’re in the world! It’s like one of those kids TV shows where people can jump into the world of a book.

With WebXR you can make applications that run on Meta Quest, Magic Leap 2, Hololens 2, PCVR and other platforms. It kinda drives me up the wall that so many people are hung up on Apple because AVP competes with quite a few different platforms that are all pretty similar and if this kind of thing catches on you’d better believe people will be porting applications between them…

To Facebook's credit, Facebook really is investing in developing a new platform, which is more than you can say about Google, Apple, Amazon, etc.

The reality is that Horizon Worlds is a joke (maximum 20 players in a world and you trade players for geometry, a 20 player world is much smaller than an 8 player world.) Horizon Worlds doesn't let you import images, video or sound.

A VR world has to fit everything you can see in a headset. A really big game like Asgard's Wrath 2 (absolutely amazing) is like an open world game which is full of hidden loading screens and it's quite expensive to develop if you want it to feel open.

By not letting you load those kind of resources HW keeps the size of the world under control, plus it disappears pornography, copyright violations and a whole lot of trouble. It kills HW for me because I want to make content based on photography and visual art, and kills it for commercial users because McDonald's just has to put a Coca-Cola logo on the side of the cup.

The MQ3 is basically an Android phone you wear on your face and the mainstream way to deliver apps for it is the same as a mobile phone. Unlike Apple, you can sideload, in fact you can sideload many ordinary phone apps, such as the Tailscale client or the Denon HEOS client and they usually work. It's not less any open an environment than mobile.

On top of that you can create webpages with WebXR that appear in VR at the touch of the button and this framework

https://aframe.io/

you can make worlds that are browsable on phone, tablet and desktop but that you can enter with a VR headset. (Makes me think of a few kids TV shows where the characters can jump into books) These are compatible across a range of devices such as the Hololens 2, PCVR headsets, and even the Apple Vision Pro.

Google and Microsoft provide plenty of models for half-baked efforts that end in failure (every time a B2B startup gets bought by Google the competitors have a meeting of their salespeople the next day and say... "YOU'RE ON COMMISSION, YOU'RE GOING TO GET RICH!) Facebook is the one big tech company that is seriously investing in a new platform and they deserve some credit for it, whereas all the rest of them are so wrapped up in "business theater" and "technology theater" that nobody realizes Google hasn't made anything since they bought YouTube.

Traditionally, VR and AR development involved complex frameworks and languages, but Node.js brings a fresh approach to the table. Its familiarity with JavaScript allows developers to write code for VR and AR applications with ease. By utilizing libraries like A-Frame for VR and AR.js for AR, developers can create immersive experiences directly in the browser using Node.js. This seamless integration opens up opportunities for a wider range of developers to enter the VR and AR landscape.

if there is none, how could it work? I'm not a dev, i work in design, UX, art. however this seems excellent system https://aframe.io yet I'm sure are others. runs in the browser, super fast, the code is just simple human readable, text, so works with HTML, JavaScript.