4 ms·

So this is the same what Pastebins are for unstructured texts and image hoster for pictures. At one point, at least everybody realizes that JSON can host arbitr

by ktpsns 9y ago

So this is the same what Pastebins are for unstructured texts and image hoster for pictures. At one point, at least everybody realizes that JSON can host arbitrary data -- such as unstructured text -- and pictures as containers, can do as well. I wonder how the operators of these free services act in terms of durability. https://jsonbin.io/ https://jsonbin.io/ proudly reports: "21838 bins created". That probably does not need much storage. But what if I use it regularly from my systems? I'm not so much convinced of just another service which allows storing data for some time, probably with a nice UI. (Actually I noticed this with http://sprunge.us/ http://sprunge.us/ -- I included uploading a build log into my build systems which my team is using now. At one point, sprunge.us started to give back 500's for us, basically stopping working. Sure, switching the service takes a blink of an eye.)

mr_ali3n 9y ago
JSONbin.io developer here. Tracked the thread using GA after unusual spike in the traffic. Good point. We cannot trust any random service. It takes some amount of investment, dev time & server costs to keep the service up and running. The reason I developed this service is to ease the storage process for the developers developing mobile or small scale apps, so that they can focus on the app rather than spending time setting up the database. Just to keep the website up and running, I'm going to introduce nominal amount plans which developers can afford and it pays my server bills. I'll ensure that I've SLA in place when am introducing pricing. The only reason I've not introduced pricing on the website is I don't want to charge for something basic what am providing for now. Will add it when I provide more powerful features which are already under development.
- toomuchtodo 9y ago
  What's your take on developers not putting the effort forth to use their own object store (ie S3) for this? I'm not against developer velocity (disclaimer: not a dev), but this seems to be a cycle where hosted tool comes out, people rely on it, tool becomes too expensive to run, neglected, etc, and then tool goes dark one day. Would time be better spent on client libraries that ease the difficulties of using existing durable storage systems? Or open source javascript frontends you can drop into your S3 bucket to provide a GUI for manipulating JSON in the same object store? I am seeking enlightenment, not an argument. In tech for almost 20 years now, and have seen my fair share of the cycle.
  - mr_ali3n 9y ago
    It's not just about efforts but it's more like the developer needs to maintain another piece of a service. I agree that uploading a simple Json file doesn't sound too complez to maintain but at a cost of you paying for S3 service with limited amount of features.
  - balls187 9y ago
    > What's your take on developers not putting the effort forth to use their own object store (ie S3) for this? Services like these are really geared towards the hacker mentality of getting prototype built as quick and dirty as possible. As the parent wrote--to focus on the app. Using a durable source like S3 sounds good, but now you have the additional requirement of having an AWS Account. Granted the barrier to getting an AWS account is minor, but it is still is a barrier.
  - sowbug 9y ago
    I believe your question is equivalent to the question of solving the tragedy of the commons, which suggests it's indeed a tricky problem. As a strawman proposal, we could take some of Elinor Ostrom's suggestions for a non-governmental solution (https://en.wikipedia.org/wiki/Tragedy_of_the_commons#Non-governmental_solution https://en.wikipedia.org/wiki/Tragedy_of_the_commons#Non-gov...) and apply them: 1. Introduce the concept of an API key to allow users to voluntarily segregate the traffic into accounts. API keys are only voluntary because it's easy to extract someone else's key from a client binary and masquerade as that person. 2. Issue API keys only to users who agree to a set of community standards. 3. Nontrivial usage that still complies with the community standards requires payment. The payment should be structured so that it's reasonable for medium-traffic users to stay, but more economical for heavy-traffic users to leave the community and start up their own clone of the service. For style points, the community standards should have specified that anyone who starts with the free community service and graduates to hosting a clone must also host low-traffic free users, basically causing the service to become federated. Maybe the original service replies with 301 redirects to the new service so that old clients keep working. I think all of this can be fully automated, and if you're cool accepting Bitcoin for usage above the free tier, then you don't even have to worry about how to handle payments. There are plenty of VPS providers that accept Bitcoin these days, so the system is even closed-loop from the perspective of the service operator.
- mercer 9y ago
  So, my first thought is that I'd set up a service like yours primarily because I'd be fascinated by the data provided. While that might not result in malicious use of said data (it'd not be my intention), it's quite possible the resulting data might provide interesting opportunities. Now, I'd consider it unlikely that I'd setup such a service without being a peeping Tom, so if something interesting were to come my way, I'd probably notice it. How do you deal with this? A firm resolve not to, at the very least, check out shady avenues of information? Giving in to that urge but not using it for profit? The reason I'm wondering about this is that I'm part of multiple IRC channels where with some regularity people will link to a service such as yours with code that exposes private keys, and while usually the people helping out in those channels will be quick to point out the privacy leakage, it struck me that all of it is still available to the hoster. And in fact, switft removal of said code my ping the hoster that this might be interesting data.

by ktpsns 9y ago

mr_ali3n 9y ago

JSONbin.io developer here. Tracked the thread using GA after unusual spike in the traffic. Good point. We cannot trust any random service. It takes some amount of investment, dev time & server costs to keep the service up and running. The reason I developed this service is to ease the storage process for the developers developing mobile or small scale apps, so that they can focus on the app rather than spending time setting up the database. Just to keep the website up and running, I'm going to introduce nominal amount plans which developers can afford and it pays my server bills. I'll ensure that I've SLA in place when am introducing pricing. The only reason I've not introduced pricing on the website is I don't want to charge for something basic what am providing for now. Will add it when I provide more powerful features which are already under development.

toomuchtodo 9y ago
What's your take on developers not putting the effort forth to use their own object store (ie S3) for this? I'm not against developer velocity (disclaimer: not a dev), but this seems to be a cycle where hosted tool comes out, people rely on it, tool becomes too expensive to run, neglected, etc, and then tool goes dark one day. Would time be better spent on client libraries that ease the difficulties of using existing durable storage systems? Or open source javascript frontends you can drop into your S3 bucket to provide a GUI for manipulating JSON in the same object store? I am seeking enlightenment, not an argument. In tech for almost 20 years now, and have seen my fair share of the cycle.
- mr_ali3n 9y ago
  It's not just about efforts but it's more like the developer needs to maintain another piece of a service. I agree that uploading a simple Json file doesn't sound too complez to maintain but at a cost of you paying for S3 service with limited amount of features.
- balls187 9y ago
  > What's your take on developers not putting the effort forth to use their own object store (ie S3) for this? Services like these are really geared towards the hacker mentality of getting prototype built as quick and dirty as possible. As the parent wrote--to focus on the app. Using a durable source like S3 sounds good, but now you have the additional requirement of having an AWS Account. Granted the barrier to getting an AWS account is minor, but it is still is a barrier.
- sowbug 9y ago
  I believe your question is equivalent to the question of solving the tragedy of the commons, which suggests it's indeed a tricky problem. As a strawman proposal, we could take some of Elinor Ostrom's suggestions for a non-governmental solution (https://en.wikipedia.org/wiki/Tragedy_of_the_commons#Non-governmental_solution https://en.wikipedia.org/wiki/Tragedy_of_the_commons#Non-gov...) and apply them: 1. Introduce the concept of an API key to allow users to voluntarily segregate the traffic into accounts. API keys are only voluntary because it's easy to extract someone else's key from a client binary and masquerade as that person. 2. Issue API keys only to users who agree to a set of community standards. 3. Nontrivial usage that still complies with the community standards requires payment. The payment should be structured so that it's reasonable for medium-traffic users to stay, but more economical for heavy-traffic users to leave the community and start up their own clone of the service. For style points, the community standards should have specified that anyone who starts with the free community service and graduates to hosting a clone must also host low-traffic free users, basically causing the service to become federated. Maybe the original service replies with 301 redirects to the new service so that old clients keep working. I think all of this can be fully automated, and if you're cool accepting Bitcoin for usage above the free tier, then you don't even have to worry about how to handle payments. There are plenty of VPS providers that accept Bitcoin these days, so the system is even closed-loop from the perspective of the service operator.
mercer 9y ago
So, my first thought is that I'd set up a service like yours primarily because I'd be fascinated by the data provided. While that might not result in malicious use of said data (it'd not be my intention), it's quite possible the resulting data might provide interesting opportunities. Now, I'd consider it unlikely that I'd setup such a service without being a peeping Tom, so if something interesting were to come my way, I'd probably notice it. How do you deal with this? A firm resolve not to, at the very least, check out shady avenues of information? Giving in to that urge but not using it for profit? The reason I'm wondering about this is that I'm part of multiple IRC channels where with some regularity people will link to a service such as yours with code that exposes private keys, and while usually the people helping out in those channels will be quick to point out the privacy leakage, it struck me that all of it is still available to the hoster. And in fact, switft removal of said code my ping the hoster that this might be interesting data.