Develop SplitImage

[smcgregor]

The SplitImage proof-of-concept application was first introduced last May but development since then has largely focused on testing infrastructure rather than application development. This project is intended to push the SplitImage application into the wild.

[anmoljagetia]

Firstly congratulations for getting getting selected as a mentoring organisation fro GSoC 2015.

I am Anmol Jagetia, a third year undergraduate student at IIIT Allahabad. I have been programming in HTML, CSS, JS, Java, C, C++ for the past 3 years. I also have some experience with Data URI's and security from client side applications I developed at my internship last year (They were embedded into mobile devices, used Data URI to exchange data, and finally used encryption to communicate with a server to retrieve Points from the server inside a game on iOS, Android and Windows Phone).
I am currently working on the levels and reading the relevant documentation.

Can you please guide me further, as to what are the prerequisites for the project, and any other "tasks" that I might complete to improve my chances of selection.

[smcgregor]

Welcome Anmol! I added a few tasks above.

[vatsalj]

@smcgregor Hello! Following along the lines of your proof-of-concept, I was able to make audio files exchange using privly as well. Video format will work with minor modifications to the code. The code for audio format is available here: https://github.com/vatsalj/privly-applications/tree/gsoc-AudioMessage. Here is the screenshot for the same (the UI is not polished at the moment):
Creating new content:

Viewing content:

Multiple files:

I've used HTML5 audio and video elements with dataURI source. JSFiddle: http://jsfiddle.net/vatsalj/28p4b2pc/

I'd like to ask a few things regarding this idea:

1. Should all the rich media formats be a single application, say RichMedia, which will contain video, audio and images?
2. Data URI for audio and video are not widely supported. Moreover, the support is different for different formats (ogg/mp4 being the properly supported ones). So, I'd like to know how much is cross-browser compatibility an issue?
3. The application performs well for file sizes <2MB. Are files more than 2MB also need to be supported by the application?
4. This is in regard to issue Add Unit Testing to SplitImage #191. The units tests for this "RichMedia" application will be almost same as the PlainPost and Messages?

Thanks!

[smcgregor]

1: I think it would be most appropriate to have the application accept a set of different media types and then have the app provide the relevant UI for the selected files.
2: I think we need to experiment with the HTML5 file APIs here.
3: Yes, larger files will need to be supported. Much of this bottleneck is on the server-side.
4: The current set of unit tests are in transition to be more like traditional unit tests. Most of our unit tests pre-date the integration testing system so the unit tests were testing things that are both unit tests and sometime more appropriately expressed as integration tests. So stylistically there should be a shift to better isolating the unit being tested -- for all new unit tests.

[smcgregor]

Also, very cool extending the proof of concept for audio! Which platforms are audio data URIs supported/not supported on?

[vatsalj]

@smcgregor : Thank you! Someone experimented with the data URI's. Here is the link to the answer: http://stackoverflow.com/a/3802646. It seems like iPad and iPhones do not have support for audio data URI at all, other browsers have varying support.

[vatsalj]

@smcgregor I tried the audio option with files upto ~4 MB, the encoding was quick and encryption made chrome hang for a few moments. However, chrome became quite slow when I inspected the request. Same goes for decryption. When not inspecting via dev tools, it's a bit laggy, but not as slow.

For large files, I think a good alternative would be to split the audio using JavaScript or Flash. That way, both encryption and decryption will be done on smaller chunks of data rather than the whole humongous data. Depending upon the implementation, audio can be streamed on-the-go or the small chunks can be stitched together to create the whole media. What are your thoughts about this?

[anmoljagetia]

Great job with the proof of concept @vatsalj for audio and video. I have previously worked on client side chunking and stiching, something like http://html5-demos.appspot.com/static/media-source.html.
Facebook also has an open source version of a JavaScript library which they used to reduce the images into smaller less resolution version of them, so that they can load faster in a browser (I was thinking a similiar version can be used to increase performance, but then we will face quality vs size issue).
I presently can't find their library (I think they have taken it down, so I'll look into making my own version of it).

[smcgregor]

Devtools run slow when you run them on DOM that has really long strings, like an image encoded in Base64.

-1 for Flash (because Flash)

+1 for JS splitting of audio.

[smcgregor]

I mostly finished porting the old proof of concept to the newer MVC architecture. In the process of updating the branch I didn't fix a few problems since they a good introductory tasks. In order of increasing complexity, these tasks are:

• Lint the application
• Update the new.html template so it has a button for uploading images, in addition to the drop area.
• Update the show.html template so it has a button for uploading images, in addition to the drop area. Note: updating images is currently broken, see below.
• Update the run_each.sh script to test the new scripts.
• Add test cases to cover the new code.
• Hook your repository into coveralls.io to examine your coverage.
• Finish porting the show.js controller to the new MVC architecture.
• Update the icon for SplitImage in the navigation dropdown so that it is an image, instead of the pencil.
• Update the privly-web content server to support larger images. Note: while this is important to the app, this task will not teach you as much about the Privly architecture because the changes are on a content server's database. Most Privly development concentrates on the client.
• Update the seamless posting button so it will also support posting images.

NOTE: The html is not built for the branch, so to do any development work you will first need the build system to be working.

[smcgregor]

@irdan and I were planning our work on SplitImage today. I pushed a few small changes to my fork and will continue development in about two weeks. We broke the development into the following issue areas:

UX

1.0. (done) It uses the drag and drop API for selecting files, but it should also display the traditional form-based file selection dialog.
1.1. Set the upper limit on the responsive image size so it doesn't make small images massive
1.2 Add the white background from the show.html to the new.html preview of the image
1.3 Fix the list of metadata for the image. Make the metadata a drop down instead of always shown?
1.4 Add drag/drop updating of images on the show page
2. Integrate image sharing with seamless posting
3. Integrate the Message and SplitImage apps with navigation inside the apps. Since they use the same crypto, users do not need to be aware of the differences between the apps so we can hide the fact that they are different apps with navigation.
?. Image preview after selection should be scaled to preserve ux [selection? what selection?]

Functionality

1. Update the content server to allow for larger images. It is currently very limited

Promotion

1. Record demo videos and tell people how to access it via the "secret menu" [0]

Generally Related to Development

1. Update the "show" action to appropriately use the new MVC. It is currently 3/4 of the way completed.
2. Remove rendered HTML from the repo. This will make it easier to manage the files across apps.
3. move apps into a subfolder so the root directory doesn't become too crowded over time

Security

1. Develop a threat model and add it to this repo. (we generally need a more formal threat model for ZeroBin, SplitImage is the same)

Testing

1. (done) Test the application on more platforms from the hosted context. These web standards are newer and likely have numerous inconsistencies that we should keep in mind as we continue development. Sean Notes: Minimal inconsistencies were found. This should work everywhere with minimal changes after completing the implementation.
2. (done) Test image injection for the updated proof of concept (gsoc-splitimage branch)
3. Complete unit test coverage
4. Complete selenium coverage, including checking the ASII representation of injected images.

Remaining Priorities:
UX (1)
Generally Related to Development (1) and (2)
Security (1)
Functionality (1)
Testing (3) and (4)
UX (2) and {3}
Generally Related to Development (3)
Promotion (1)

[0] The "secret menu" is typing directly into the address bar.