Introducing HumbleNet: Cross-Platform Networking Library for the Browser | Hacker News Reader

Introducing HumbleNet: Cross-Platform Networking Library for the Browser

hacks.mozilla.org

123 pointsindescions_201718 comments

WebRTC is one of the fundamental building blocks that has been missing from the platform. Luckily, with the next macOS and iOS release we'll finally get support in Safari [0], which is the last holdout.

I've gotta say, though... It's a tad underwhelming to open up all the links and not see any of the demos hosted somewhere for you to try.

It looks like support was added to Quake 3 over two commits [1][2]. I don't know much about game development, but I'm surprised it took so few changes.

[0] http://caniuse.com/#feat=rtcpeerconnection

[1] https://github.com/HumbleNet/quake3/commit/a5469b0b1032cde40...

[2] https://github.com/HumbleNet/quake3/commit/9b96742651edc73d0...

Quake 3's code is open source but it relies on proprietary assets that you must get from buying the game, but they could make a freely-accessible web version of OpenArena (it's a free open source game that uses Quake 3's code and game mechanics with free assets).

What about web clients talking to dedicated browserless servers over a unreliable UDP-style datachannel? That's something I imagine could be quite useful for gaming applications.

>Currently HumbleNet implements 2 modes:SEND_RELIABLE and SEND_RELIABLE_BUFFERED.

No unreliable messages? Isn't this practically just recreating TCP on top of UDP if you can't opt out of reliable sends?

Didn't Mozilla already work on something for connecting browsers together?

The demo i recall was using Firefox phones as game controllers for a racing game being projected from a laptop.

That was FlyWeb [1][2]. Judging by the wiki, it seems the project isn't too active anymore, at least publicly (empty calendar, no meeting minutes from 2017).

[1] https://flyweb.github.io/

[2] https://wiki.mozilla.org/FlyWeb

It seems like you have been accidentally shadowbanned for replying to https://news.ycombinator.com/item?id=14291773 (turn on showdead if you can't see why that might happen). Maybe try emailing the mods to get it reverted?

Weird, thanks very much for letting me know. I've emailed the mods.

So how is the initial peer discovery happening again? Isnt that part centralised problem? Any suggestions how to solve it?

That depends on what exactly the concerns of the browser vendors are. They could just expose UDP sockets and ask for a "access the internet" permission like android apps do. But they don't, which aiui mostly is due to security concerns .

Most people aren't interested in decentralized peer discover because it doesn't cost much in bandwidth and it doesn't need low latency.

AFAIK the only benefit of decentralized peer discovery is to be resilient to censorship.

> AFAIK the only benefit of decentralized peer discovery is to be resilient to censorship.

No, not really. One example where it's not about censorship is offline scenarios, but connected to the same network. If there is a central, upstream server for discovery, you won't be able to find other peers. If the discovery works offline/locally (as with Bonjour/mDNS), you can still find other peers. So it has a lot of value.

So who runs the STUN and TURN servers?

Can this technology be used for in-browser BitTorrent?

Yup, and it already exists! Check out WebTorrent [0].

My favorite example of WebTorrent in action is Instant.io [1], which lets you easily transfer files across browsers.

[0] https://webtorrent.io

[1] https://instant.io

In my opinion webtorrent hardly qualifies as a proper bittorrent implementation due to the limitations of webrtc.

It cannot interoperate with existing bittorrent clients. And it cannot maintain decentralized networks, i.e. it needs a central rendezvous server and session tokens, bittorrent needs no such thing due to the DHT.

Currently there is no single entity that could be ordered to shut down a bittorrent swarm. With the need for rendezvous servers on the other hand you could order them to block specific content.

For all practical purposes BitTorrent needs trackers for initial peer discovery so it's not really much of a downgrade.

Even with a DHT for any kind of practical content discovery, sites would need to track at least one member of the swarm so new peers can join.

> For all practical purposes BitTorrent needs trackers for initial peer discovery

It does not. I have downloaded many DHT-only torrents. Startup time tends to be a little longer, but that's mostly because implementations are tweaked for low packet per second rates and not low latency, which in turn is somewhat related to the poor quality of many home routers which do not deal well with the UDP traffic.

> so it's not really much of a downgrade.

Since people are trying to decentralize the web recentralizing already decentralized protocols seems a huge step backwards to me.

> Even with a DHT for any kind of practical content discovery, sites would need to track at least one member of the swarm so new peers can join.

In bittorrent the DHT is not about content discovery, it is a global network which you only need to join once (contacts are persisted - something not possible with webrtc) which can then be used for peer discovery for individual swarms.

This makes it fully decentralized.

Reply on news.ycombinator.com