Move away from webtorrent

[ArtskydJ]

The "music room" project has been slowing down recently, mostly due to webtorrent. Although webtorrent is a really cool project, it is making the "music room" hard to test and develop:

• I'm not able to test on windows, because there are not any node WebRTC modules that work on windows and implement webRTC data channels.
• On other machines, it is often hard to get the WebRTC modules to build.
• In all my testing, webtorrent started slowly. I don't know why, and I don't know if it was per-torrent, or just startup.

I'm thinking of moving away from webtorrent.

Pros:

• Easier to test/develop
• More compatible with older browsers, probably

Cons:

• Scaling/Load - Lack of peer-to-peer file sharing will likely cause higher server load. I don't see it as being an issue right now.

---

What to use instead

Good ol' http posts should handle uploading songs to the server just fine.

The server can then host d2b49d6e46f5.mp3 and d2b49d6e46f5.ogg. (Full UUIDs)

At some point the server will send out a message using socket.io, like "new song", "d2b49d6e46f5", and the client can put that as the source in an audio element:

<audio controls>
    <source src="d2b49d6e46f5.ogg" type="audio/ogg">
    <source src="d2b49d6e46f5.mp3" type="audio/mpeg">
</audio>

OR

var audio = new Audio();

socket.on('new song', function (filename) {
    audio.src = filename + '.mp3'
})
socket.on('play', function () {
    audio.play()
})

Client-side js will start the audio, when the server tells it to.

---

@TehShrike thoughts?

[TehShrike]

Oh man. It seems so sad to move away from bittorrent for distribution. I think one of the main reasons that Listening Room was taken offline instead of just left on the internet was because the bandwidth costs were non-trivial.

Still, waiting for solid Webtorrent support is getting old, and a music room using a single file server is better than no music room.

Also, if the "upload new song" and "give me an element for this song id I know is on the server" APIs are reasonable, changing them to use Webtorrent eventually shouldn't be too bad.

We might be able to do better than HTTP for uploads - this socketio-file-upload module could give us better streaming/ui.

GETs to access the audio files on the server will probably be the simplest thing to get working with <auido> elements.

[ArtskydJ]

Here is my current plan. Not sure if I'll implement it all right away.

• Stick with webtorrent for distributing files between clients
• Use http posts/socket.io for file uploads/downloads so the server can convert them.
  • Perhaps the first version will always upload to the server, serve the file to the original uploader, and assume that all clients have chrome/firefox.
  • Future versions should only upload the file to the server if...
    • ...a browser does not support the distributed file type or
    • ...a browser does not support webrtc (in which case, it downloads the file directly from the server).