Hacker News Reader

Whoever you choose today to store and keep all your photos is probably not who you're going to be using in 10 years. I'm surprised that HN doesn't really zero in on this. Closed systems are just a temporary solution for a problem that's getting exponentially worse.

Some of us are just less vocal than others, especially when we tend to get shouted down by those who can't be bothered to run their own web servers and then resign themselves to let others control their data. FreedomBox is making things better in this respect, though, and I can't help but think that they would love to hear about Trovebox (hint, hint).

I would just like to thank you very much for OpenPhoto/Trovebox. Even though this is the first I've heard of it, it seems to be something I could really use. I'm currently generating static web albums with gPhoto, then uploading them by hand, but had been thinking about automating the whole shebang for a while. There are plenty of open source photo albums (even packaged for Debian stable, my distro of choice), but so far I hadn't found any that offer mobile clients to automate things. While I'm not on Android, the wife is, and this looks like an awesome way to let her share photos, while still keeping them under her control. I'm also very glad to see that Trovebox is open source, and will be mirror cloning the repos soon :)

I just push my photos up to an SFTP on a home server, which also pushes it to an encrypted offsite backup.

This has the advantage of working equally well for code(git repositories and everything being just directories with files), photos, videos, audio samples/tracks... anything which we're used to representing as files on UNIX-y systems.

I really don't understand why we need to jettison the boatloads of wonderful work which has been done to support files on UNIX, in search of a frontend interface difference for people(yes, many people) who don't understand files.

Not sure I understand completely. But I'm taking a stab...

For something like photos the interface is a very big problem. The UNIX file system, for example, doesn't help to visually organize tens of thousands of files (photos). There has to be a layer on top of that.

FYI, OpenPhoto supports a variety of "file systems" including the local file system or anything which can be mounted.

I think you are entirely corerct.

The macro problem with most photo library software is that it's trying to do far too many things and ends up doing none particularly well. A photo library software suite generally enables:

1. Photo storage, 2. Light photo editing (either of metadata or image data or both), 3. Photo viewing (including basic slideshow functions, etc.), 4. Photo organization (creation of albums, tagging people, and so on), 5. Photo sharing ("post this album to Facebook", etc.)

The problem is that no two of these tasks have a particularly logical relationship to one another. And as to most of them, there are better ways to do it.

As you note, we have put _enormous_ effort as a society into developing a very particular way to store blobs of data: the filesystem. It is a stable way. It is a well documented way. It is a way that has lots of tools that are also stable and well documented and mature. And best of all, it's really, really easy to back up. You can make copies of data on the filesystem in a trivial fashion. Back it up to an external drive! Back it up to a remote server, either owned by you or someone else! Encrypt the backups! Don't! It's easy. The same is true of photo editing, photo viewing, and many other things.

The one problem that photo libraries really solve is organization. It's nice to be able to make albums. It's nice to see all the photos taken around a similar time, or at a particular place, or with certain people in them. In fact, it's what makes huge collections workable. So I'm not knocking that. But what I am proposing is that there's got to be a way to disaggregate that singularly useful function from the mess of other things that photo library software doesn't need to do.

Note also that photos ought to be uncommonly easy to write organizational software for, because so many of them have built-in, well-documented metadata. Take a picture with your iPhone sometime and then dump the full EXIF info. There's a lot in there, way more than most people realize. And yet it's common to begin building photo library software by recreating all of that same information inside a proprietary and undocumented database. EXIF data includes a place for a description field---why doesn't photo library software _write to that?_ And files can have titles (or 'file names,' as they're called in the business)---why would you recreate, in some hidden-away SQLite database or something, the "title" attribute?

Whilst I agree with you in theory, and on the principle that probably 90% of POST, PUT or other various schemes to upload data could probably be better solved (and more securely) by a simple setup of rsync+SSH, there is the issue of end user interface. I don't want to have to browse through an Apache file listing of thousands of files named similarly to "2013-01-02_09:33.jpeg". I want thumbnails, and possibly other context (location, tags, etc). I also don't necessarily want to upload every single photo I take.

+1 for Trovebox. I love that I can use my own domain name (http://photos.masnick.org/) and have Trovebox use my own S3 account for storage.

I haven't had a chance to hack on the source code myself yet, but you actually can contribute to the Trovebox frontend on GitHub (http://github.com/photo/frontend). I've filed a few issues here and fixes were in production on trovebox.com within a few days!

I haven't looked yet, so sorry if it's mentioned, but is there any support for Amazon Glacier integration? If all I want is to make sure my photos are safe, and I'm not interested in really accessing a number of albums, can I select them and have them transferred to my Glacier account? This would be the case for many childhood photos of mine at this point in life.

We don't support Glacier yet. It's a good idea and one I'll run by the team.

I'm not sure why Amazon doesn't have a feature to mirror an S3 bucket to Glacier (which would solve your problem). I imagine they will but for the moment the closest thing they have is the lifecycle feature but it removes the file from S3 once it's moved to Glacier.

Happy to talk it through if you'd like. Drop an email to support@trovebox.com

I love using Glacier for photo archival. Every month, I transfer all the photos of my Android device and my wife's iPhone, zip them, and push to Glacier. It's very manual at the moment, but it's super cheap archival for all my photos.

I signed up for a free account to play around and am quite impressed. Hosted options are nice, even though I have a Linode account for self-hosted apps.

1) How different is the OpenPhoto webapp from the Trovebox app? Does they support all the same features?

2) How does the Dropbox integration work? Can I move photos into the Apps/Trovebox folder and have them be automatically synced with the web site? I'm using the Dropbox Photo Sync feature, so it would be super handy to not have to re-upload them to Trovebox.

3) After signing up and uploading photos, I clicked on a link someone posted below to associate my dropbox account with the trovebox account. My photo upload was still going at the same time, and I started to get dropbox notifications about new files being added so I stopped the uploading. However, I can't see anything in the settings that tells me what storage back my account is using. How can I see/change it?

This is a very exciting app & service, which might be The Solution to sharing photos within my extended family!

1) 99% the same. We've streamlined a few functions on the hosted version (Trovebox). Things like migrating between storage services, importing from 3rd party sites, etc. The core and API are 100% identical. In fact our mobile apps for iOS/Android work for Trovebox & OpenPhoto instances.

2) The Dropbox integration is one way. Trovebox -> Dropbox. On Trovebox we have a beta feature that lets you upload via Dropbox by dragging photos to a specified folder.

3) So that notification is simply us putting the photo in your Dropbox. That's how the Dropbox support works :). Can you let me know what you were expecting?

You can always drop us an email at support@trovebox.com with questions.

> 3) So that notification is simply us putting the photo in your Dropbox. That's how the Dropbox support works :). Can you let me know what you were expecting?

I expected the Dropbox notification. :) What I would like is a way to see where my photos are currently being stored, and a way to switch storage back from Dropbox to Trovebox (I only have 8GB of storage in DB).

Could you send an email to support@trovebox.com?

Am I overlooking a setting, or does the Trovebox iPhone app only allow me to take square photos, and force me to crop pre-existing photos I want to upload? I definitely hope not - I'd like to be able to make that call myself.

The app doesn't do any cropping (unless maybe you apply filters, I have to check on that).

The home screen on the app shows square cropped photos and the Gallery view does a little bit of cropping as well on display.

But the photos themselves are not cropped. A look at the web version shows this a bit more clearly (for example, see the panoramas) -- https://current.trovebox.com/photos/list

Valid point though. We don't want the app confusing people into thinking it's cropping. We're big on retaining the original, unmodified.

This is not my experience. The app only takes square photos, and forces you to crop existing photos if you select them from the camera roll one at a time, regardless of whether you select a filter. Unless I'm missing a setting, which I've looked for.

The uploaded photos viewed on the web are indeed cropped/square.

EDIT: I see there is a separate upload/sync menu item, and that allows you to batch upload uncropped photos. However, if I want photos taken on my phone to be auto-uploaded to Trovebox, they need to be taken through the app, which forces me to take a square picture.

I'd respectfully request that you make cropping an option when taking a photo, not the rule, so I don't need to take photos in one app and upload them manually with another. Better yet, let me tell the app to just incrementally/periodically upload all the photos I take on my phone (ala Everpix)

You're absolutely right. I created an issue here, https://github.com/photo/mobile-ios/issues/288

Automatic uploading is already being tracked here, https://github.com/photo/mobile-ios/issues/234

Thanks for the feedback. We're super easy to reach at support@trovebox.com as well.

Rad! I feel pretty confident you guys are the future.

Oh sorry, the homepage on http://theopenphotoproject.org says, " Stay tuned! Our Android app is coming soon." under mobile apps.

Great work by the way :-)

Thanks.

My problem is the enormous amount of disk space my photos take. Hundreds of GBs. Now you say trovebox supports dropbox, but that doesn't really solve my problem since dropbox just keeps everything on my local hard disk as well.

Is it possible to set this up so that I don't have to take up hundreds of gbs on every device I own?

I also don't see any option for importing iphoto libraries. What if I want to preserve the tagging/album information I have there?

We provide storage which is included in the free/Pro accounts.

I don't use Dropbox for the same reason as you. Instead I use my own S3 bucket.

Dropbox is the only storage option that will sync the files back to your computer (though I believe you can choose not to have our folder "synced" using selective sync).

We don't have an iPhoto plugin yet but if you add tags to your photo then they should be preserved when you upload (we extract EXIF).

sadly iphoto doesn't touch the exif data. It's stored in a seperate (undocumented) sqlite database.

Which is a real scandal, by the way. It's utterly surreal that a file format with some of the most well-documented metadata on the planet is organized into libraries that begin by creating an entirely new, entirely redundant library of metadata on top.

A little confusing:

> Connect to Dropbox or Box > > Allow us to store your photos or use your existing storage account. No pressure to decide. We make it as easy as clicking a few buttons to migrate between storage accounts. We support Dropbox, Box, Amazon S3, CX and DreamObjects.

But once I sign up, I checked under all the Settings I could find, and I don't seem to see any of these options for where to store things?

Selecting your storage is part of the signup process. A selection list that you might have overlooked?

If you have not uploaded any photos (or delete photos in your account) you can link it at the following URLs (for the popular options).

https://trovebox.com/signup/storage/dropbox

https://trovebox.com/signup/storage/s3

https://trovebox.com/signup/storage/box

I noticed and deliberately kept the "Not now" default choice. That implied I could change it later. Which the pre-sign-up text I quoted, also seemed to say.

So I was confused I couldn't find or do this, later.

(I'm not trying to give you a hard time. Just offering n%b user feedback.)

Thanks. I'm going to have a look through the site copy and see if we missed anything when we moved the "migration" option to be a PRO feature.

We do offer migration between storage providers at https://trovebox.com/migrate. It is new-ish so we don't have prominent links for this but one of our important features. You can upload 20,000 photos and then one day decide, I don't want to use Dropbox anymore.

One question (and the most important one for me): does OpenPhoto/Trovebox deal with RAWs?

If so, how? E.g.:

What if the RAW doesn't have an embedded preview JPG?

What if the RAW comes with a sidecar JPG that contains the RAW developed through app XYZ?

Etc., etc.

We don't (yet). It's a fairly common request but one we haven't put on our roadmap yet.

I wish the answer was different :).