
Introducing HumbleNet: Cross-Platform Networking Library for the Browser - indescions_2017
https://hacks.mozilla.org/2017/06/introducing-humblenet-a-cross-platform-networking-library-that-works-in-the-browser/
======
TheAceOfHearts
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](http://caniuse.com/#feat=rtcpeerconnection)

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

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

~~~
AgentME
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).

------
AlexMax
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.

------
AgentME
>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?

------
digi_owl
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.

~~~
nathcd
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/](https://flyweb.github.io/)

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

~~~
yorwba
It seems like you have been accidentally shadowbanned for replying to
[https://news.ycombinator.com/item?id=14291773](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?

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

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

~~~
Jyaif
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.

~~~
diggan
> 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.

------
0xdeadbeefbabe
So who runs the STUN and TURN servers?

------
gressquel
Can this technology be used for in-browser BitTorrent?

~~~
TheAceOfHearts
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](https://webtorrent.io)

[1] [https://instant.io](https://instant.io)

~~~
the8472
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.

~~~
Spivak
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.

~~~
the8472
> 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.

