
Show HN: We use Github Gists to store user data - zubairov
http://blog.elastic.io/post/19778691186/your-data-is-owned-by-you
======
redcircle
Another company blog without a link to the company home page. I had to
manually type your company URL to try to learn what this is all about. It is
absurd how common this is.

~~~
VMG
It's hidden under the "see more" widget on the left. There is a tiny
"elastic.io" link under the main headline.

------
Estragon
BTW, your landing page at elastic.io could use some work. The slideshow runs
much too fast (I had to hit the back button at least ten times to read it) and
it didn't really explain the service you're providing (or explain why it's
valuable, though I suppose "avoid billing surprises" is nice.)

~~~
zubairov
Great idea! We also thought about this one. As we will re-sell cloud APIs it
will be definitely a good feature to protect our users from slashdot effects.

------
bmelton
It's a clever idea, to be sure.

I wonder if anyone at Elastic has talked with anyone at Github as, it seems to
me, if Elastic gets any significant traction, this does nothing to help github
(though perhaps I'm overlooking something) and leads into a 'Tragedy of the
Commons' scenario wherein everyone is depleting a shared public resource for
their own personal gain knowing full well that it isn't sustainable long term.

~~~
zubairov
Agree. Also with our current implementation right now we might pose a bit too
much load on Gists (which is actually only our fault), however it's only first
step. We want to give our users their data at hand, I could imagine a
potential independent 3-rd parties storing our data where other companies
(Facebook) will use it on our behalf. Users private data will be more
protected, and portable. So if I would like to switch (Facebook --> Google+,
hypothetically) I would just revoke access from one site and give it to
another.

------
jasonkester
Wow, so they moved off requiring you have a Twitter account to requiring you
have a Github account. Keeping in mind that requiring _any_ 3rd party account
to use your own service is a bad idea, this sounds even worse.

Have you ever tried to sign up for a Github account? Last I checked they made
you perform a bunch of scary crypto stuff on your local machine before they'd
let you in. I gave up at that step, as it would have required downloading and
installing a bunch of random software to pull off. No idea why they would make
people do that (and it's why I still don't have a github account), but...

To limit _your service_ to only accept customers who have navigated that
minefield? Sounds like the ultimate form of adding friction to your signup
process.

~~~
cmelbye
I sincerely hope that this is a troll comment. I suppose it's subjective, but
I don't consider "ssh-keygen -t rsa" to be scary, and I would've thought that
most developers would've already have OpenSSH installed (which is the only
dependency for generating keys, not "a bunch of random software.")

Do you really have no idea why they would make people do that, though? Maybe
it's so that your source code can be securely protected so that only you can
access it and modify it?

~~~
mbell
I'd really like to know if the original comment was a troll, joke or otherwise
as well. According to the posters profile he is actually a developer of
several services.

If it wasn't a joke of some kind I'd like to make a note to never trust any
sensitive data of any kind to his products.

Considering generation of an SSH key 'scary' is a pretty strong indication to
me that there is no tangible level of security being implemented.

------
tensafefrogs
It's a cool idea (storing user data in their own github accounts), but it
sounds like a nightmare when it comes to security and data validation. No
longer can you trust what gets into your database and instead you would
constantly have to validate the data you import.

I suppose that makes the service more like an API where the service generates
the code to run on it rather than the user.

~~~
zubairov
Yes, that's definitely a problem. For our use-case where we want to follow SW
engineering best practices like versioning, continuous integration, etc. we
thought reuse of git as a repository and them to user will be a good thing.

------
natep
Some feedback on your main site: Each slide has a lot of words, and I can't
figure out how to pause it. I'm signing up for the beta because I _think_ I
know what your site does, but I'm really not sure. I'd be more comfortable if
I could see all 4-5 pictures at once, which could easily fit horizontally on
my monitor.

Edit: OK, I was able to read all of the captions via "View Source"

~~~
zubairov
Thnx for your feedback. Very good point! We will definitely improve our
website in the nearest future.

~~~
zalew
The caption on the blog (unseen before you notice the ribbon, and unreadable
before you select it) should be on the main page.
<http://i.imgur.com/KyRQD.png>

------
tjoff
_We don’t want to lock your data in our databases._

GREAT! Now get rid of the _silly_ github requirement (and don't return to the
even more silly twitter requirement) and give your users the _option_ of
storing it in github or retrieve their data some other way.

I can't even begin fathom the decision process that concluded in _requiring_
github.

------
timcameronryan
For specific audiences, using Gists as data storage is really useful. I did
the same for my "reverse StackOverflow": <http://askedtheinter.net/>

Users own all their data, they can revise their answers, and other users can
fork them; just like small Git repositories, and just the use-case that gists
generally solve. Compare: <http://timcameronryan.askedtheinter.net/q/1318314>
with <https://gist.github.com/1318314>

------
rb2k_
Reminds me a little bit of what unhosted (<http://www.unhosted.org/>) does

~~~
zubairov
Exactly. Primary motivation was to have a simple versioning for user data flow
and Git repository management overhead was too much, however after we
implemented it we realized that data portability is a by-product of that.

