Let's try to launch V1 on Test Pilot by June 30

I don't have Redis installed locally, but when I type npm start things go a bit silly.
Not sure if we should fail hard[er] if the Redis connection fails.

➜  something-awesome git:(master) npm start

> [email protected] start /Users/pdehaan/dev/github/mozilla/something-awesome
> watchify frontend/src/main.js -o public/bundle.js -d | node server/portal_server.js

Portal app listening on port 3000!

{ Error: Redis connection to 127.0.0.1:6379 failed - connect ECONNREFUSED 127.0.0.1:6379
    at Object.exports._errnoException (util.js:1026:11)
    at exports._exceptionWithHostPort (util.js:1049:20)
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1136:14)
  code: 'ECONNREFUSED',
  errno: 'ECONNREFUSED',
  syscall: 'connect',
  address: '127.0.0.1',
  port: 6379 }

{ Error: Redis connection to 127.0.0.1:6379 failed - connect ECONNREFUSED 127.0.0.1:6379
    at Object.exports._errnoException (util.js:1026:11)
    at exports._exceptionWithHostPort (util.js:1049:20)
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1136:14)
  code: 'ECONNREFUSED',
  errno: 'ECONNREFUSED',
  syscall: 'connect',
  address: '127.0.0.1',
  port: 6379 }

...

Let's get a metrics.md going.

Two weeks after launch ensure we've reviewed and made adjustments to V2.

So webrtc is known to have connection issues in the real world. We've decided we don't want those issues to be a factor in this experiment. A more traditional client-server model should be more reliable but has a different set of challenges for our use case.

I would like to be able to revisit a P2P architecture in the future if this experiment proves successful. I think there's several benefits to P2P for both the users and us if the tech is reliable enough. With that in mind I'd like to keep the UX and service architecture to be "P2P compatible".

Here's what I imagine that to be:

1. Sender makes a request to the server that creates a link to share
2. Sender opens a websocket or xhr long poll to the server to wait for the Receiver to connect
3. Receiver visits the link triggering a handshake with the Sender
4. Via websockets or xhr a secure handshake and crypto happens 👋
5. Sender starts uploading the encrypted data
6. Receiver starts downloading the data
   a. Meanwhile the server is not storing the data anywhere
7. The transfer completes and session is closed

What I like about it:

• The flow and UX is the same as webrtc with TURN
  • could allow us to do webrtc testing with a server fallback transparently
  • could swap for webrtc when its solid
• Saves us from storing data
• Greatly (I think) simplifies the encryption implementation
  • key exchange happens live vs IDKWTF

Possible downsides:

• Both parties must still be connected at the same/whole time
  • price of P2P compatibility

Thoughts?

• Add a linter so that we all follow the same coding conventions
  https://github.com/eslint/eslint
  https://github.com/stylelint/stylelint

• Protect master branch, and hook up Travis or Circle CI to check that it passes for PRs

framework, etc, needs discussion

cloudformation / ansible / whatevs

We should check the previous uploads list against the server to see if they're still available. This should have it's own server endpoint that the frontend can use.

Create a page (or whatever) that implements the design elements from @sevaan's invision design https://mozilla.invisionapp.com/share/M8BMZM7TZ#/screens/232885168_Link_Generator in the browser.

Create the functionality that allows a sender to visit a page and generate a link that can be shared with a receiver. When the receiver visits the link the two parties should connect via webrtc.

Our current implementation doesn't work for me on files > 2GB. It tries to load the whole file into the browser before encrypting. We'll probably need to do some kind of chunking. There's some prior art for webrtc that we might be able to get inspiration from: https://github.com/otalk/filetransfer/blob/master/filetransfer.js

Re: https://p2p.dev.lcip.org

Speaking of interesting challenges, creating a /__version__ route which lets us (friendly neighborhood QA) know exactly what code (Git SHA) is deployed on the dev/stage/prod server and would be pretty useful [eventually].

Currently https://p2p.dev.lcip.org/__version__ returns a 404 (as expected).

Here's a sample of what we get back from something like TestPilot prod server (https://testpilot.firefox.com/__version__):

{
  "commit": "c4639a25b938bd4717aadc3ead840e80f0a0f059",
  "version": "2017-05-04",
  "source": "https://github.com/mozilla/testpilot"
}

Placeholder for QA signoff of v1 release

Really minor, but the new Fetch API plays really nice w/ promises, and makes for a fun little future refactoring.

Should return a 200 if the service is healthy, and a 500 otherwise. This should check dependent services like the database connection to ensure that they are healthy.

Any other page content is allowed, although keep it short, simple, and quick loading as this will get hit all the time.

We want to ensure the :id matches a hex string with the regex /[0-9a-fA-F]{32}/

http://expressjs.com/en/guide/routing.html#route-parameters

Should respond 200 if the service is up, 500 otherwise. This is for load balancer checks and should not check dependent services.

Any other page content is allowed, although keep it short, simple, and quick loading as this will get hit all the time.

???

https://www.npmjs.com/package/mozlog

A webextension should allow us to transfer files without the UI tab open

To show the list of previous uploads on the main page after a page reload we should read the list from localstorage. We may want to change the way items are stored so we don't need to iterate over all the keys.

When a "Share" menu on Android or iOS detects that the shareable content is a file, we should have an item appear in the share menu to send the file via the service.
(If "is this a file?" is not possible, consider a whitelist.)

Whatever the flow for uploading, we could conclude with the option to copy to clipboard (though consider autocopy) and another share option for the URL, allowing users to send the URL straight to someone via email/text/whatever.

If a user chooses a file with a size > 2GB the upload currently silently fails. We should check the file size before loading it with the FileReader and tell the user the file is too big.

Currently we're hot linking to a hosted version of [email protected] on ajax.googleapis.com:

<script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/jquery/3.2.1/jquery.min.js"></script>

We should host jQuery locally so we aren't using third party servers. Not sure if we want to grab it via npm and bundle it w/ Webpack or Rollup or whatever.

Placeholder for legal signoff of V1

https://[your name here].firefox.com

https://send.firefox.com (see #7)

Randomly spotted while trolling your repo:

➜  something-awesome git:(master) ls -lash public/resources
total 5280
5160 -rw-r--r--  1 pdehaan  staff   2.5M Jun  7 22:03 background.png
  40 -rw-r--r--  1 pdehaan  staff    20K Jun  7 22:03 link_expired.png
  48 -rw-r--r--  1 pdehaan  staff    22K Jun  7 22:03 share.png
  32 -rw-r--r--  1 pdehaan  staff    13K Jun  7 22:03 upload.svg

Note that the public/resources/background.png is 2.5 MB. But we'll probably want to try running all the images through imagemin and/or svgo.

To start:
Describe the project.
Step by step instructions on how to run.

When displaying the links after upload they wrap over a few lines - would be cleaner if they fit on one line.

Off the top of my head (there are probably more):

• How many users are we expecting?
• How many users at the same time?
• Is there a filesize limit?
• Is there a total size limit per "account"?

Per: Host something on AWS #2, we now have a https://p2p.dev.lcip.org/ dev server. But when I try uploading/downloading files, I still see some references to "localhost".

We'll need to try determining the environment at runtime to distinguish between local and dev server stuffs.

Other than that, everything worked and looked great! Awesome work, @abhinadduri!

framework, etc, needs discussion

At a minimum they use prefixes on the window.crypto.subtle API. There may be other issues as well.

As far as I know Safari uses window.crypto.webkitSubtle and IE uses window.msCrypto.subtle

What's it going to be? (Spoiler alert: "Send")

TODOs:

• Rename repo (#171)
• Remove any references to something-awesome (PR #182)
• Remove any references to portal
• Tweak README.md (PR #182)
• Update package.json (PR #182)
• Update contribute.json PR (#148) after repo/URL is updated (PR #182)
• Update dev and stage server URLs (#166)
• Update docker image names? (PR #167; "build docker image with new name")
• Update Circle-CI