5 ms·

Disclaimer: Founder of Trovebox / OpenPhoto I still believe there's a lot of promise in "the cloud". It's unfortunate that these types of shut downs leave such

by jmathai 13y ago

Disclaimer: Founder of Trovebox / OpenPhoto I still believe there's a lot of promise in "the cloud". It's unfortunate that these types of shut downs leave such a bad taste in people's mouths. There is a way to do it though. Decoupling application logic from data storage basically solves this problem. If we (Trovebox) ever has to send an email like this it would be along the lines of "Our service is shutting down but your photos are safe where they are, you don't have to do anything. If you want to continue using the service here are the ways to do it on your own."

yesplorer 13y ago
I wanted to tell you this the last time you submitted to HN, but don't you feel the photo of the child on your homepage portrays a cold, zombie-esque feeling? I don't know if it's deliberate but it hardly made me felt welcomed
- jmathai 13y ago
  You're not the first person to say that. The home page will change shortly. Thanks for the feedback.
  - yesplorer 13y ago
    Good to know you are working on it
hga 13y ago
How can that work and still provide unified billing while you're in operation. E.g. let's say the photos are stored in S3, would they either have to pay bills to both Amazon and you, or switch to a smaller bill from Amazon upon your demise? The other problem is of course that very few of these companies do that sort of thing as far as I know (which I wouldn't, particularly, seeing as I only use rsync.net for off-site safety (http://en.wikipedia.org/wiki/2011_Joplin_tornado http://en.wikipedia.org/wiki/2011_Joplin_tornado) and otherwise use local disk plus LTO tape with a full backup always in a safe deposit box).
- jmathai 13y ago
  There is no unified billing at the moment. Not sure that is desired though. Decoupling payment is part of data ownership. Remember that we provide storage as well. There is unified billing that way at the cost of data ownership. This coupled with the ability provided to migrate to another storage provider is as good of a solution as possible today. I hope this gets better in the future as I realize it is not ideal. But it is at least headed in an interesting direction :).
  - hga 13y ago
    How is customer acceptance going? Me, I'd love such a thing, but ... well, you may be ahead of your time, but I suppose at least one of your unique selling propositions is that you aren't like the other "cloud" vendors, and the more the others screw over their customers like in this example the stronger that proposition will be. A friend of mine who has a fist full of patents on basic hard drive technology, including several in every hard drive you own, has a maxim that goes something like this: "When you buy a hard drive you should start planning for its death and the loss of all your data on it." The popularity of various backup services, especially in the face of strict data cap regimes outside of Verizon, suggests that plenty have learned this lesson, which I would assume also helps your case. Anyway, it sounds like you're doing a very good thing, I wish you the best of luck!
    - jmathai 13y ago
      We've had good adoption but it is TBD if there's a big enough demand from the consumer market. However, our architecture opened up other interesting opportunities which we'll be announcing soon. Have a look at the University of Southern California Digital Repository. They have system for long term digital preservation. They discard any storage media after 3 years and continually check for "rotting" of files.
tmzt 13y ago
What kind of API do you see as valuable for something like that, disconnecting the ownership and control of data from stewardship? Can you see a design for something that would applicable to other products, whether it was built on S3 or a new shared data source, distributed solution, opaque data protection, etc. Would Firebase supporting API keys that can be delegated by the data owner, rather than the application provider, be a solution on the transactional/database side? I started thinking more about this following Fred Wilson's post on how this is happening in the investment community, as well as his vision for the future of VC (as I understand it). http://www.avc.com/a_vc/2013/06/decoupling-advisory-from-custody.html http://www.avc.com/a_vc/2013/06/decoupling-advisory-from-cus... As I mentioned on comments there, I'm working on a concept in a different area but with the same fundamental pattern, which I see emerging as we desire more ownership and control of our assets, and permanency of data and other resources. I'm also working on a blog post about this.
- jmathai 13y ago
  Not sure I understand exactly but I'll take a stab at answering. For us, the API needs to simply abstract how and where data is stored. The same API works for any supported storage service. We've open source large parts of our code and that falls under the "stewardship" banner. We act as a broker but make it as simple as possible if you want to be the broker yourself.
  - tmzt 13y ago
    Thanks for the reply. Do you have a Github repository or some other URL for this code? Sorry for the confusion, but by "stewardship" I meant that you maintain or manipulate the data but do not control the place that is stored. I could have chosen a better word. This new model needs clearly defined terms for these roles.

by jmathai 13y ago

yesplorer 13y ago

I wanted to tell you this the last time you submitted to HN, but don't you feel the photo of the child on your homepage portrays a cold, zombie-esque feeling? I don't know if it's deliberate but it hardly made me felt welcomed

jmathai 13y ago
You're not the first person to say that. The home page will change shortly. Thanks for the feedback.
- yesplorer 13y ago
  Good to know you are working on it

hga 13y ago

How can that work and still provide unified billing while you're in operation. E.g. let's say the photos are stored in S3, would they either have to pay bills to both Amazon and you, or switch to a smaller bill from Amazon upon your demise? The other problem is of course that very few of these companies do that sort of thing as far as I know (which I wouldn't, particularly, seeing as I only use rsync.net for off-site safety (http://en.wikipedia.org/wiki/2011_Joplin_tornado http://en.wikipedia.org/wiki/2011_Joplin_tornado) and otherwise use local disk plus LTO tape with a full backup always in a safe deposit box).

jmathai 13y ago
There is no unified billing at the moment. Not sure that is desired though. Decoupling payment is part of data ownership. Remember that we provide storage as well. There is unified billing that way at the cost of data ownership. This coupled with the ability provided to migrate to another storage provider is as good of a solution as possible today. I hope this gets better in the future as I realize it is not ideal. But it is at least headed in an interesting direction :).
- hga 13y ago
  How is customer acceptance going? Me, I'd love such a thing, but ... well, you may be ahead of your time, but I suppose at least one of your unique selling propositions is that you aren't like the other "cloud" vendors, and the more the others screw over their customers like in this example the stronger that proposition will be. A friend of mine who has a fist full of patents on basic hard drive technology, including several in every hard drive you own, has a maxim that goes something like this: "When you buy a hard drive you should start planning for its death and the loss of all your data on it." The popularity of various backup services, especially in the face of strict data cap regimes outside of Verizon, suggests that plenty have learned this lesson, which I would assume also helps your case. Anyway, it sounds like you're doing a very good thing, I wish you the best of luck!
  - jmathai 13y ago
    We've had good adoption but it is TBD if there's a big enough demand from the consumer market. However, our architecture opened up other interesting opportunities which we'll be announcing soon. Have a look at the University of Southern California Digital Repository. They have system for long term digital preservation. They discard any storage media after 3 years and continually check for "rotting" of files.

tmzt 13y ago

What kind of API do you see as valuable for something like that, disconnecting the ownership and control of data from stewardship? Can you see a design for something that would applicable to other products, whether it was built on S3 or a new shared data source, distributed solution, opaque data protection, etc. Would Firebase supporting API keys that can be delegated by the data owner, rather than the application provider, be a solution on the transactional/database side? I started thinking more about this following Fred Wilson's post on how this is happening in the investment community, as well as his vision for the future of VC (as I understand it). http://www.avc.com/a_vc/2013/06/decoupling-advisory-from-custody.html http://www.avc.com/a_vc/2013/06/decoupling-advisory-from-cus... As I mentioned on comments there, I'm working on a concept in a different area but with the same fundamental pattern, which I see emerging as we desire more ownership and control of our assets, and permanency of data and other resources. I'm also working on a blog post about this.

jmathai 13y ago
Not sure I understand exactly but I'll take a stab at answering. For us, the API needs to simply abstract how and where data is stored. The same API works for any supported storage service. We've open source large parts of our code and that falls under the "stewardship" banner. We act as a broker but make it as simple as possible if you want to be the broker yourself.
- tmzt 13y ago
  Thanks for the reply. Do you have a Github repository or some other URL for this code? Sorry for the confusion, but by "stewardship" I meant that you maintain or manipulate the data but do not control the place that is stored. I could have chosen a better word. This new model needs clearly defined terms for these roles.