What I learned from WebTorrent

What I learned from WebTorrent

What I learned from WebTorrent: Lessons learned from starting and running a P2P open source project

Presented by Feross Aboukhadijeh in Berlin, Germany at Data Terra Nemo 2019 (https://dtn.is)

WebTorrent:
https://webtorrent.io
https://github.com/webtorrent
https://twitter.com/WebTorrentApp

Feross:
https://feross.org
https://github.com/feross
https://twitter.com/feross

B498d33041627b07726dc29c28f02df7?s=128

Feross Aboukhadijeh

May 17, 2019
Tweet

Transcript

  1. WHAT I LEARNED FROM WEBTORRENT: LESSONS LEARNED FROM STARTING AND

    RUNNING A P2P OPEN SOURCE PROJECT
  2. WHAT WE DID RIGHT WHAT WE DID WRONG

  3. None
  4. None
  5. None
  6. None
  7. None
  8. None
  9. LESSON 1 SHARE YOUR WORK EARLY AND OFTEN

  10. > Late 2013: Announced WebTorrent > Early 2014: PeerCDN acquired,

    got job at Yahoo > Mid 2014: Released BitTorrent CLI > Late 2014: Works in the browser, end-to-end > Early 2015: Quit job > Mid 2015: WebTorrent is stable and useful
  11. LESSON 2 FIND A JOB THAT ALLOWS SIDE PROJECTS

  12. > 2016: Released WebTorrent Desktop > 2017: Brave Browser bundles

    WebTorrent > Late 2017: Burnout > Early 2018: WebTorrent Desktop hits 1 million downloads
  13. None
  14. WEBTORRENT IN 2019 > Website: 150,000 page views and 65,000

    users per month > JS Library: Loaded 5 million times per month > Desktop App: 2 million installs, 100,000 monthly users
  15. None
  16. MIT/STANFORD PHILOSOPHY > Simplicity: the design must be simple, both

    in implementation and interface. It is more important for the interface to be simple than the implementation. > Correctness: the design must be correct in all observable aspects. Incorrectness is simply not allowed. > Consistency: the design must not be inconsistent. A design is allowed to be slightly less simple and less complete to avoid inconsistency. Consistency is as important as correctness. > Completeness: the design must cover as many important situations as is practical. All reasonably expected cases must be covered. Simplicity is not allowed to overly reduce completeness.
  17. WORSE-IS-BETTER PHILOSOPHY > Simplicity: the design must be simple, both

    in implementation and interface. It is more important for the implementation to be simple than the interface. Simplicity is the most important consideration in a design. > Correctness: the design must be correct in all observable aspects. It is slightly better to be simple than correct. > Consistency: the design must not be overly inconsistent. Consistency can be sacrificed for simplicity in some cases, but it is better to drop those parts of the design that deal with less common circumstances than to introduce either implementational complexity or inconsistency. > Completeness: the design must cover as many important situations as is practical. All reasonably expected cases should be covered. Completeness can be sacrificed in favor of any other quality. In fact, completeness must be sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness if simplicity is retained; especially worthless is consistency of interface.
  18. WORSE-IS-BETTER PHILOSOPHY > Simplicity: the design must be simple, both

    in implementation and interface. It is more important for the implementation to be simple than the interface. Simplicity is the most important consideration in a design. > Correctness: the design must be correct in all observable aspects. It is slightly better to be simple than correct. > Consistency: the design must not be overly inconsistent. Consistency can be sacrificed for simplicity in some cases, but it is better to drop those parts of the design that deal with less common circumstances than to introduce either implementational complexity or inconsistency. > Completeness: the design must cover as many important situations as is practical. All reasonably expected cases should be covered. Completeness can be sacrificed in favor of any other quality. In fact, completeness must be sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness if simplicity is retained; especially worthless is consistency of interface.
  19. int fd = open("file.txt", O_WRONLY | O_APPEND); write(fd, "hello, world\n",

    13);
  20. char buf[] = "hello, world\n"; int buf_size = sizeof(buf); int

    fd = open("file.txt", O_WRONLY | O_APPEND); int bytes_written = 0; while (bytes_written < buf_size) { bytes_written += write(fd, buf + bytes_written, buf_size - bytes_written); }
  21. WEBRTC IS WORSE-IS-BETTER > Has performance issues > Terrible API

    > Yet, it enabled P2P on today's web > proved that the dweb is a valid web use case > Makes it easier to argue for better P2P web APIs
  22. LESSON 3 WORSE IS BETTER

  23. "The lesson to be learned from this is that it

    is often undesirable to go for the right thing first. It is better to get half of the right thing available so that it spreads like a virus. Once people are hooked on it, take the time to improve it to 90% of the right thing."
  24. $ webtorrent --help Usage: webtorrent [command] <torrent-id> <options> Example: webtorrent

    download "magnet:..." --vlc Commands: download <torrent-id> Download a torrent seed <file/folder> Seed a file or folder create <file> Create a .torrent file info <torrent-id> Show info for a .torrent file or magnet uri Specify <torrent-id> as one of: * magnet uri * http url to .torrent file * filesystem path to .torrent file * info hash (hex string) Options: --airplay Apple TV --chromecast Chromecast
  25. LESSON 4 PROVIDE VALUE ALONG THE WAY

  26. None
  27. WHO IS YOUR IDEAL USER?

  28. None
  29. const client = new WebTorrent() client.add('magnet:...', torrent => { //

    Torrents can contain many files. Let's use the .mp4 file const file = torrent.files.find(file => file.name.endsWith('.mp4')) // Display the file by adding it to the DOM file.appendTo(document.body) })
  30. npm install render-media

  31. LESSON 5 SOLVE ONE USE CASE PERFECTLY

  32. webtorrent_success = js_bet * electron_bet * webrtc_bet

  33. js_bet = .95 electron_bet = .80 webrtc_bet = .50 webtorrent_success

    = nodejs_bet * electron_bet * webrtc_bet console.log(webtorrent_success) // 0.38
  34. LESSON 6 TECHNICAL BETS ARE MULTIPLICATIVE

  35. None
  36. LESSON 7 HAVE A SIMPLE PITCH

  37. HTML – THE ORIGINAL WEB API <script src="webtorrent-element.min.js"></script> <web-torrent src="magnet:..."

    file="Sintel.mp4" />
  38. None
  39. LESSON 8 DESIGN FOR THE LEAST TECHNICAL USERS

  40. Thanks for the feature request! WebTorrent Desktop values simplicity more

    than most torrent apps. This sometimes means saying 'No' to good ideas. We try to implement only the most important features that a torrent app needs and make those features as good as possible. We don't want the app to get overloaded with knobs and dials that may only benefit a small percentage of users. That's not to say we won't ever add large new features. We support powerful features like instant streaming, dynamic piece prioritization, web peers (WebRTC), etc. but only when they have a clear benefit to a vast majority of users. See the 80-20 rule. I don't think it makes sense to implement this feature right now. I hope this makes sense!
  41. None
  42. None
  43. None
  44. None
  45. LESSON 9 IGNORE THE NERDS

  46. // App version telemetry.version = config.APP_VERSION // Screen resolution telemetry.screens

    = getScreenInfo() // OS version and amount of RAM telemetry.system = getSystemInfo() // # of torrents currently active, # in list, total size telemetry.torrentStats = getTorrentStats(state)
  47. None
  48. None
  49. LESSON 10 GROWTH MATTERS

  50. None
  51. LESSON 11 BE PROACTIVE, NOT REACTIVE

  52. None
  53. LESSON 12 BUILDING DECENTRALIZED SOFTWARE WITH CENTRAL COORDINATION IS OKAY

  54. "MECHANICAL SYMPATHY"

  55. None
  56. LESSON 13 DWEB APPS ARE NOT ROBUST ( YET )

  57. !

  58. LESSON 14 THE OPPORTUNITY IS HUGE

  59. HAPPY HACKING! @FEROSS • FEROSS.ORG