How does this differ from Firebase?
https://github.com/bluzi/jsonstore/blob/master/api/database....
21–30 of 55 posts
How does this differ from Firebase?
https://github.com/bluzi/jsonstore/blob/master/api/database....
Nice work!
Earlier quoted context omitted.
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…
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…
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-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.
So there's no actual security on this? That is, given the knowledge of an endpoint, anyone can issue requests against it? How do you plan on responding to requests regarding GDPR requirements from EU residents? What happens when someone starts uploading content that could be covered under the DMCA? Following the links, should we assume that https://www.forter.com is the responsible company?
So there's no actual security on this? That is, given the knowledge of an endpoint, anyone can issue requests against it? How do you plan on responding to requests regarding GDPR requirements from EU residents? What happens when someone starts uploading content that could be covered under the DMCA? Following the links, should we assume that https://www.forter.com is the responsible company?
Be sure to check out webdis ( https://github.com/nicolasff/webdis ) for a similar service you can run on your servers. It's all in C so it's superlighweight.
Basically a https://jsonbin.io clone?
To make it clear: - jsonstore.io is intended for small projects, mostly for the open-source community. It's not a datastore you can use to store all the logs of your company, and we do have quota limits. - We do nothing with your data, it's secured and if you want to store sensitive data you may want to encrypt it. - The idea of this project is to provide the open source community a easy solution for storing casual u…
You mean "it's NOT secured" right?
So there's no actual security on this? That is, given the knowledge of an endpoint, anyone can issue requests against it? How do you plan on responding to requests regarding GDPR requirements from EU residents? What happens when someone starts uploading content that could be covered under the DMCA? Following the links, should we assume that https://www.forter.com is the responsible company?
Yet Wikipedia exists.
So there's no actual security on this? That is, given the knowledge of an endpoint, anyone can issue requests against it? How do you plan on responding to requests regarding GDPR requirements from EU residents? What happens when someone starts uploading content that could be covered under the DMCA? Following the links, should we assume that https://www.forter.com is the responsible company?
Not at all, it has nothing to do with Forter. It's my own personal project.