High resolution images vs screen jpg images:
Shutterfly, for example, does not provide an API for downloading your high
resolution images back to your hard drive. Rather they allow you to
order/buy a CD of those images. Flickr on the other hand does allow
users to download the full resolution content that they previously
uploaded. In cases where we want the high resolution content and
only have access to the low resolution content from the site, there are
few options.
Try to find the high resolution images on
the user's system: One possible option is to search for the high
resolution content on the users system and use those files rather than
the low res content from the website/service. If we want to get
fancy, we could compare the similarity of the low resolution and high
resolution content to see if it represents the same thing.
Browser plug-ins: There may be browser
plug-ins that could help with this project. More thought should go in
that direction.
Why a downloadable application rather
than a web service?
Websites
would block us: If we were just a website, many of the web services
that we'll be helping to be more open would block us.
Users shouldn't give their password to
another website: We should not expect any user to put their
username and password into our website. To do that would be entirely
trusting us to never misuse that password. Flickr uses a persons Yahoo
password. The Yahoo password is sometimes used for financial information
and thus security for this password is especially important. Again, we
should not expect users to ever give one website their password to another
website.
Your local machine = a decentralized solution:
A main goal of this tool is to make it so control of content is
decentralized. Having the content live on a users local machine is
the ultimate in decentralized control. Rather than having a service
that everything feeds through, it will be an application that installs on
a users local machine.
It's easier to make it a free service: As
a local application, it's easier for this service to be free. The
CPU cycles used are mostly that of the users local machine. The
bandwidth costs are shared by the many users and sites.
It's safer to put a password into an open
source local application: We ask users to
download our open source application to their machine. They will be
putting their username and password into that tool. This still requires a level of
trust, but the level of trust needed for this is vastly less than any
other viable alternative. And since this tool is just downloading the
content to the users local machine, it doesn't feel like they're giving
the password to another website (since they're not). Developing the
application as open source means that the community can make sure there isn't any
code that steals passwords.