jamest

Check out http://firepad.io, it's an open source project that uses Firebase on the backend. You could use that as a starting point and then put together your own backend.

http://socrates.io, built with Firebase.

Thanks Ido, I absolutely agree we should guide developers towards best practices.

We'll be aiming to do this with future tutorials on security.

Thanks Patrick. Point well taken.

I'll add one now.

[Firebase Founder] Hi Robin,

You’re right, some folks don’t fully setup their security rules. We remind our developers to do this, but can -- and clearly need -- to do more. Your suggestion about requiring security rules is a good one. We’ll be going through our customers and providing more personalized feedback on their security rules in the coming days. Also, we are working on additional tutorials and examples to teach our devs how to use our security rules in an interactive way.

Thanks for pointing out some of the areas we can improve our examples. They’re intended to illustrate design patterns, not be robust production apps. Again, we can do better here, and the code we use as an example should be bullet proof.

Like any application, Firebase-powered apps are only as secure as the developers make them. If you do not control access with security rules, your app could be vulnerable. XSS attacks can affect Firebase apps like any other application.

Finally, we would have really liked you to provide responsible disclosure on the specific Firebases you found issue with and given us enough time to speak with those customers before taking this public.

We’ll reach out to you via email now.

I've seen worse on the internet :)

To answer your questions:

1. We put our code in escrow for very large customers. We are thinking about the best way to address the concerns of everyone else. Stay tuned.

2. This is coming. It'll be a little while.

Thanks again for your comments. Criticism helps us figure out where we need to improve.

[Firebase Founder] Hi Justin, we're pretty excited about leaving beta and think it's fairly significant. Building robust infrastructure isn't an easy task and this change is meant to signal that we're ready for primetime. I hope that comes across!

If you're worried about lock-in, I'd first try Firebase along with our AngularJS[1] or Backbone[2] bindings. You don't have to change the way you write your app and can switch Firebase our for another backend easily. We recognize that we're only going to win a developer's trust by building a reliable service with the best tools and fair pricing -- so this is what we're going to do

I'd love to dispel any concerns, please feel free to email me anytime (james at firebase)

[1] https://github.com/firebase/angularFire

[2] https://github.com/firebase/backfire

[Firebase founder] Thanks for the suggestion! We'll chat with other users and see if there is high demand for this.

We used Videopixie for a number of our customer case studies. Their editing service was literally an order of magnitude cheaper than the studio who shot the video was bidding to edit.

The quality was great too, you can easily get multiple iterations and give feedback easily.

Here are some GitHub projects that user Angular & Firebase

https://github.com/search?q=firebase+angular&ref=command...

[OP / Firebase founder here] We certainly aren't trying to be disingenuous with the 'serverless' title. The piece of code on GitHub allows you to build WebRTC functionality that doesn't require you to run a signaling sever. (or, any server if you want to go that far) Though, yes, we still run and maintain the Firebase servers to make this happen.

Sorry for any confusion. I'll add some explicit language in the README on GitHub.

Thanks for checking out the code.

Seconded! Congratulations Mike, Fred & team.

[Firebase founder] Thanks for the feedback! We're definitely aware that it's a concern. Hopefully we can go a little way towards winning your trust by showing you the great apps built on us by larger companies (happening soon) and by giving you the best customer service we possibly can. And, hey, toys are a good starting place too.

Regarding pricing, you can find it here: https://www.firebase.com/pricing.html

Pricing is difficult and we're trying to get it right. Your feedback would be great.

They way they've used videos on their homepage to tell the stories of their customers is great. It's unique for a dev tools company to take this angle, but I think it's very smart. You should be selling the end and the means.

12-24?

If you're successful you'll be working for far longer than that. Even if you're not successful good teams will continue to iterate or change ideas, which will often take far longer than 24 months.

(Firebase Founder here)

Saurik - We're glad that there are people like you searching for holes in services like Firebase. Hopefully it'll keep making all of us better. Please keep doing it.

As ivolo noted, we do have a security feature set we're testing. It has taken a little while to build something that is both functional and usable. We're pretty confident we've got something that our users will love.

Excited to show you soon!

We use Lockitron on the Firebase office door. I highly recommend it. Giving access to new employees is a couple of clicks, rather than making & tracking a new physical key.

Check your inbox :)

You can find our REST API docs here: http://www.firebase.com/docs/rest-api.html

We're definitely working on security full speed. We have some basic security but it's not ready yet. If you'd like to beta test it, please email us: beta@firebase.com

You can check out our FAQ for more info: http://www.firebase.com/faq.html

Absolutely

Good point. This was on while we were in stealth. I've removed the whois protection.

Good question. Meteor is an application framework, like Ruby on Rails. Firebase is a database, like MySQL.

We both think that application development is going to radically change in the future and we're both building products that promote a new way of developing apps. We're stoked about Meteor and see our products as very complementary.

Hosting can be handled much more efficiently / easily by someone designed just for content distribution, like a CDN. Our own site is 100% server from a CDN, which makes for very nice scaling characteristics. Also, it's free right now...

(Co-founder of Firebase here)

We know the Meteor guys well and are really excited about what they're building. It's very complementary.

We're both advocating a new paradigm in software development and the faster it comes the better.

Great work guys!

+1

Founder of Envolve here; yes, we did build a version of Envolve for HN called envo.lv

It was always intended to be a marketing gimmick. The critical mass required to sustain good conversation only lasted for the time the story was on the front page.

Getting a website owner to install a chat system, (rather than just having an overlay) combined with integrating with site credentials will make an on-site chat system significantly more viable.

This solves a problem that I have all the time. Existing movie aggregators are a pain to navigate the filled with ads.

I like the Rotten Tomatoes integration. Nice work.

Completely agree with the sentiment that food often becomes a burden rather than a joy.

Love the idea and congrats on knocking it out in a weekend.

Awesome, thanks so much for the input.

- Flood control is already baked in. 4 messages every 10 seconds is the limit.

- Pasting images gets ugly (eg porn). We'll think of a good way to do this soon.

- JS editor is a sweet idea!

- Personal ban list / spam reporting are on their way.

Thanks again.