Firebase is proprietary

[cben]

The Firebase backend is proprietary so you can't run your own instance of the full stack.
At this stage, I would not trust myself with running a secure & reliable backend, so using Firebase is better for Mathdown end-users.

OTOH, there is little need to change anything about Firebase and being able to develop as a purely client-side code makes forking and testing much easier - a user can try any fork without exporting/importing user data.
"Running" a fork is as simple as loading the static HTML from anywhere - local checkout, github pages, cloud9 workspace etc.

Any free solution should preserve the ability to fork and use without migrating data.

---

Best free-backend alternatives to Firepad:

• https://github.com/Operational-Transformation/ot.js/ is mature, well documented, has CodeMirror binding.
  Includes node.js server code; no persistence layer?!
• https://github.com/share/ShareJS is simple and has (currently incomplete - ShareJS with Codemirror ? josephg/ShareJS#124)) CM binding.
  Includes node.js server code, needs MongoDB.

For other firebase-like functionality (if we add any), meteor.com looks most similar in spirit, and even provides free hosting for server-side part of the app (arbitrary node.js?).

[cben]

For more firebase alternatives, look at http://nobackend.org/solutions.html. Haven't found a directly usable alternative yet.

[JohnBerg60]

Hood.ie looks promissing!

[cben]

Yay, first comment not by me in this project :-)

Thanks for the link. First impressions:

• I love the Offline First stance.
• From 5 min of googling there is no Hood.ie based real-time collaborative editor.
  According to Real-time collaborative textarea? hoodiehq/hoodie#167 one should use e.g. ShareJS for real-time editing and only use Hood.ie for periodic snapshots.
• It seems I'd need to host my own CouchDB [and ShareJS] server. As mentioned above I don't currently have the time or skill to do that reliably.

[cben]

Turns out the client-side firebase.js was only MIT-licensed by mistake, now corrected:
https://groups.google.com/forum/#!topic/firebase-talk/pAklVV3Whw8

[cben]

Short-term I'm staying on Firebase, long-term I'd love a fully open alternative.

In the medium-term, I'm thinking of combining Firebase for most users with some story for self-hosted backend, even if not scalable.
Specifically, running on Sandstorm.io could be sweet.

[cben]

https://swarmjs.github.io/articles/todomvc looks promising as a firepad alternative.
Based on CRDT (covergent/commutative/conflict-free replicated data types) unlike "some slap-together per-column last-write-wins solution, like Firebase and many others are using". Didn't read enough to know if it's really superior; at first glance their offline story sounds better.

Reading list:
https://github.com/gritzko/swarm/blob/master/lib/Text.js
http://christophermeiklejohn.com/crdt/2014/07/22/readings-in-crdts.html
A comprehensive study of Convergent and Commutative Replicated Data Types
TreeDoc
Merging OT and CRDT algorithms

[tohagan]

I recommend you do some more reading on CouchDb - specifically look at it's Eventual Consistency model and Conflict Management which I think is a mature well thought out solution that you can algorithmically customise as per your app requirements.

CouchDb can replicate and scale from offline mobile device (via PouchDb) => single server => replicated servers => clustered => geospatial replication. Since it's a multi-master database engine, any of these replicated instances can receive both reads and updates. Update conflicts are also retained and replicated in a tree per object that tracks revision ancestry for eventual resolution via a conflict resolution service that you build.

CouchDb + PouchDb (inside Hood.ie) is a killer combo. CouchDb 1.7 is a solid 5 year old technology. Couch 2.0 is now in developer preview and will bring BigCouch clustering (thanks to Cloudant) and much more.

No you don't need to host CouchDb yourself. Have a look at Cloudant.com (IBM), Couchappy.com and IrisCouch.com . Hosting and configuring it all yourself is now much easier and cheaper than it used to be using places like DigitalOcean.com (tons of step by step guides to setup and secure your host) and Hood.ie will also likely help here when it matures. You might want to also look at Docker.

Best of all it's Apache 2.0 or MIT licence - no propriety lock in here!

[cben]

Thanks for the pointers.

Is there any ready implementation of collaborative text editing on top of [CP]ouchDB?
I'm afraid I won't have the time (nor expertise) to roll my own any time soon; at best adapt an existing one, e.g. port Firepad (which is open source) on top of non-Firebase storage — but even that is unlikely to happen in a year...

I'm also eyeing https://github.com/mizzao/meteor-sharejs implementing OT on top of Meteor collections (some more discussion at https://trello.com/c/tkBErvIk/39-operational-transformation).

[tohagan]

You might look at the Delta Pouch plugin for PouchDb

• https://github.com/redgeoff/delta-pouch
  "A PouchDB plugin for partial updates that uses the every-doc-is-a-delta storage pattern. You can use delta pouch to enable conflict-free collaborative editing of the same docs."

Factoryng - AngularJS Adapter

• https://github.com/redgeoff/factoryng

"An all-in-one AngularJS factory that wraps PouchDB and Delta Pouch"
It's also a factory for Firebase in case you change your mind.

Other useful plugins

• http://pouchdb.com/external.html

[cben]

Thanks. I'll need to dig deeper as Delta Pouch is not extensively documented. "conflict-free editing of same docs" is promising but I'm getting the suspicion it's using the Mongo/Couch jargon sense of "doc" = json object, and conflict-free merely means different fields in the json structure can be modified simultaneously
[Source: http://stackoverflow.com/a/25050819/239657 seemed to be the origin of Delta Pouch, with merge() being for (var i in obj2) { obj1[i] = obj2[i]; }; the current code is similar.]

OT indeed represents text as a sequence of write-once deltas, but there is more to it. Not much

Note to self: also look at http://derbyjs.com/, an outgrowth of ShareJS which certainly does support OT.

---

I should note that moving off Firebase is a long-term desire but at the current rate I'm unlikely to touch it anytime soon (say not in a year). There are many things to fix that are more immediately embarrassing.