Live data from Hacker News

Mozilla Labs: TogetherJS

togetherjs.com

11–20 of 66 posts

Re: Mozilla Labs: TogetherJS

#11
This is a really cool and ambitious project. Although some mention ShareJS, I would say that the OT portion more closely resembles that employed by Firebase in their Firepad project [1] (in that no centralized server manages ordering and history). Actually, this system has many of the features of Firebase in a self-hosted package.

As a user of ShareJS (for the real-time collaboration on Plunker [2]), I can see some interesting benefits offered by TogetherJS; the system has cursor and presence features out of the box.

That being said, the main drawback that I see in TogetherJS is that it seems to be tightly coupled in a way that it is hard to take smaller parts of the overall system. It would be great if the P2P network system could be extracted and plugged into a node.js Stream interface. That would allow the code to plug into a whole ecosystem of interesting libraries [3].

I'm really excited by all the powerful libraries that Mozilla has been pumping out these days. The web is a great place to be.

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

[2] http://plnkr.co/edit/?p=streamer&s=TogetherJS (Demo)

[3] https://github.com/substack/stream-handbook#introduction

Re: Mozilla Labs: TogetherJS

#12
post #11

This is a really cool and ambitious project. Although some mention ShareJS, I would say that the OT portion more closely resembles that employed by Firebase in their Firepad project [1] (in that no centralized server manages ordering and history). Actually, this system has many of the features of Firebase in a self-hosted package. As a user of ShareJS (for the real-time collaboration on Plunker [2]), I can see some i…

We provide wysiwyg editor integration (Aloha-Editor) with presence and remote cursor. We are working on a hosted/downloadable service with low-level data-sync api and high level wiki features: https://wikidocs.com

Re: Mozilla Labs: TogetherJS

#13
post #10

Video and Audio chat functionality are real advantages over other collab tools...awesome work...i will surely check this out some time..BTW is IE11 will be providing WebRTC support??

IE10 has WebSockets: http://caniuse.com/websockets – but TogetherJS doesn't support IE10 either (simply haven't been able to keep up testing with IE in addition to other browsers).

Re: Mozilla Labs: TogetherJS

#14
post #11

This is a really cool and ambitious project. Although some mention ShareJS, I would say that the OT portion more closely resembles that employed by Firebase in their Firepad project [1] (in that no centralized server manages ordering and history). Actually, this system has many of the features of Firebase in a self-hosted package. As a user of ShareJS (for the real-time collaboration on Plunker [2]), I can see some i…

I agree that it's cool and ambitious, but it seems to have a large intersection with Google Wave.

Re: Mozilla Labs: TogetherJS

#15
post #8
post #7

Does this require using Mozilla's servers on the backend? I've played with ShareJS and a commercial hosted OT service, but they all required talking to the server. So, I assume this does too, but I haven't seen where I could install it on my server.

Look here: https://togetherjs.com/docs/contributing.html#hosting-the-hu...

Note that we haven't really "finished" the story around self-hosting, so the details of this are likely to change.

That's exactly what I was looking for - Thanks! It looks like they still have some documentation to fill out, but at least it's coming.

Re: Mozilla Labs: TogetherJS

#16
post #11

This is a really cool and ambitious project. Although some mention ShareJS, I would say that the OT portion more closely resembles that employed by Firebase in their Firepad project [1] (in that no centralized server manages ordering and history). Actually, this system has many of the features of Firebase in a self-hosted package. As a user of ShareJS (for the real-time collaboration on Plunker [2]), I can see some i…

It doesn't seem to be a P2P system, since it requires a server. According to the docs, "This server does not rewrite the messages or do much of anything besides pass the messages between the participants" [1] , so it's not really P2P.

I'm fairly sure the Firebase requires a server too... (their server, or else they couldn't charge for it).

[1] https://togetherjs.com/docs/#technology-overview

Re: Mozilla Labs: TogetherJS

#17
Looks cool! I wonder how you'd negotiate authentication with this... both users logged in presumably, you could record edit author as whoever clicked the save button (or upon each action in a "real time" saving application).

Re: Mozilla Labs: TogetherJS

#19
post #11

This is a really cool and ambitious project. Although some mention ShareJS, I would say that the OT portion more closely resembles that employed by Firebase in their Firepad project [1] (in that no centralized server manages ordering and history). Actually, this system has many of the features of Firebase in a self-hosted package. As a user of ShareJS (for the real-time collaboration on Plunker [2]), I can see some i…

[Author here] The big way TogetherJS differs from many of the other realtime products out there, like Firebase or (to a lesser degree) ShareJS, is that it doesn't do any storage. It coordinates real-time sessions, but it's not there to take the place of the application, instead it augments the application. If your application has persistence, it has traditional persistence. Whatever auth system you have is your own. At the same time while it dodges any persistence, it extends the scope beyond what those other tools typically do to include more with session management and the standard tools that I think are needed for collaboration. There's nothing exciting about text chat, but you need it anyway.

Still, ignoring persistence I think will help keep the surface area of the TogetherJS smaller compared to some other tools. Or at least focused on other things.

People have mentioned the idea of being able to chop TogetherJS up before, but I have a hard time seeing how that would actually work. For instance, the architecture is built around a pretty dumb server, so hooking into Streams would seem counter to that principle. And just allowing for the possibility would add a lot of complexity. Ultimately the UI is actually the bulk of what makes up the TogetherJS code (or maybe it's the part I find hard and so I feel like I spend a lot of time with it), and I don't know how to make this kind of UI while being modular. Without the UI I don't think it's nearly as compelling a project (becomes more like ShareJS, or Firebase, or Google Drive Realtime API – neat but a big investment, and sometimes only appropriate for greenfield projects.

Anyway, I'm certainly interested in how people want to extend or integrate with TogetherJS. I'm skeptical of splitting it up into pieces, as it is theoretically easier to do things that way, but I expect in practice it will just leave a confusing pile of pieces that aren't fun to put back together. But that doesn't mean that there aren't use cases worth exploring... and with some creativity there might be other approaches to handling those cases.

Re: Mozilla Labs: TogetherJS

#20
post #16
post #11

This is a really cool and ambitious project. Although some mention ShareJS, I would say that the OT portion more closely resembles that employed by Firebase in their Firepad project [1] (in that no centralized server manages ordering and history). Actually, this system has many of the features of Firebase in a self-hosted package. As a user of ShareJS (for the real-time collaboration on Plunker [2]), I can see some i…

It doesn't seem to be a P2P system, since it requires a server. According to the docs, "This server does not rewrite the messages or do much of anything besides pass the messages between the participants" [1] , so it's not really P2P. I'm fairly sure the Firebase requires a server too... (their server, or else they couldn't charge for it). [1] https://togetherjs.com/docs/#technology-overview

On principle we keep the server simple, echoing messages back and forth between clients. In practice it's quite hard for two browsers to connect directly to each other, and while we want to support that kind of architecture in order to get it working we still need to simulate P2P using a server.
Post reply on HN