Project Name: Oof, a subset of Proof (Send images, audio, video from any scene, to anyone, anytime)
XKCD explains the barrier: it's 2011 and sending large files is still a problem.
Problem: Sending large photos, videos, etc. is still clunky and difficult and takes too long. Most UGC form submissions are web forms, and submit the media via email and/or are restricted to file size limits that don’t make sense in the current market of digital and HD cameras.
Requirements: 'quick,' easy, no-install file transfer; ideally drag and drop FTP from mobile devices (via HTML5 websites); possible FTP optimizations; no logins required, ability to fall back to MMS in no-internet cases
Project Lead(s): Rhiannon (Twitter: @coppinr)
Big Goal for MoJo Hackfest: I'd like to get some of the barebones of an open-FTP system set up that can handle large files. (I'll call it 'oof' -- a subset of 'Proof'.) I don't want to re-invent the wheel (there are a few proprietary semi-open FTP solutions out there -- such as 'Dropbox') but I want to get something created that my colleagues could start using next weekend for getting freelance video submissions. I want to be able to send 50MB of photos to a producer as smoothly as I send a text-only email.... I want to send 2GB+ at a time... I want to be able to send someone a URL and that's all they need to send me the goods!
Key steps toward goal: Set up an FTP server; figure out the best way(s) for getting data off a remote mobile; create a web interface
Pending needs: This had turned into more of an engineering problem -- up to the limits of current browsers, browser memory handling (or lack thereof) and existing file transfer methods and protocols.
Link for more info: PDF: Description (and grid of similar technologies)
End of Day 2 big questions (or big desires): Can I make this an FTP server that can be spawned with a unique URL (like a Google Form)? Do I need or want to considers using Mollify or something similar to allow remote manipulation of the files?
End of Day 3 feedback Some other participants expressed their interest in using a tool like this that solves this "should have been solved already" file sharing problem. Trina explained that in some of the non-profit media orgs. where she has worked, youth have had problems sharing files (struggling with yousendit, FTP programs, library computers, etc.) Others (Cody?) said that they too have been in situations where a lot of time is wasted trying to get remote people who have never used an FTP dropbox to be able to send large files. Some others (Matt T., Sean) talked about possibilities (and impossibilities) of establishing file-sharing systems that maintain any degree of privacy. (I have some new thoughts on this... esp. with browser-based submissions, for example, on very high-=traffic home pages). I'm not sure my project will have applications in "leaks," which really seem to be better left in the physical realm (at least for now).
Conclusion: Is this something my peers would use? Yes. Am I re-inventing a wheel? Not quite. Should I continue to develop this (and get help from Raynor for architecting a peer-to-peer component)? Yes, probably.
Next steps: It was suggested to me (by Mark Boas, I believe) to focus on peer-to-peer transfer -- that is, your computer is opened up as a webserver for the transfer, which would be the final step in doing away with the need to rent space and bandwidth from a service provider. My initial gut reaction is that I don't like the idea of opening up ports on my personal computer that could compromise its integrity or my data; but it is worthwhile researching more. (I know some technologies (all proprietary?) exist to dial-in to another's computer, but I don't know how well this works for semi-public or public applications). [Things to read about in relation to this: Tribler and Chord DHT. The 'easier' continuation of this project is to get mobile integration solid, and a good backend file handler / permission system. I'd like the 'oof' component of this project to be an easily deployable little bundle with clear instructions and low-barriers to entry. Reporters working outside of IT hours *should* be able to set this up without requiring any admin access to their computers.