Mozilla Labs: TogetherJS(togetherjs.com)
togetherjs.com
Mozilla Labs: TogetherJS
https://togetherjs.com
23 comments
The server is fairly trivial. It's mostly there to make it easy to try. If you want to host the server, go ahead (source is on github).
I gave this a go with a "thick-client-in-browser" app that we are writing here [1]. I had to hack the code a bit (e.g. remove the clickable class check in the event simulator) but I was shocked how well it dealt with this scenario and how little effort I had to put in.
It's still a long way off from supporting this type of web page (e.g. dragging does not work, and would love to submit a PR if I only had the time to dig in more); but the almost-instant success with it was impressive. Good work Mozilla.
[1] http://www.k2.com/displaycontent.aspx?id=5502 / http://www.formsondata.com/
It's still a long way off from supporting this type of web page (e.g. dragging does not work, and would love to submit a PR if I only had the time to dig in more); but the almost-instant success with it was impressive. Good work Mozilla.
[1] http://www.k2.com/displaycontent.aspx?id=5502 / http://www.formsondata.com/
This is fantastic. I put two lines of code in my site designed to teach javascript programming http://reeborg.ca/learn_js_together.html and it appears to just work (based on a quick test which is all I could do for now). Well, except for a bug: when the robot finishes a program, a pop-up window normally appears to indicate if the task was done properly ... and it does not appear when TogetherJS is activated. To compare the version without, just remove "_together" from the URL.
Actually, after testing some more, it does not work. jqueryUI dialogs are prevented to open (for one thing). And, since I change the url hash, it likely messes with the changes introduced by togetherJS ... which, currently, prevents it from working collaboratively. Still, neat idea - especially if I can get it to work.
Another great project from Mozilla, congratulations. I'll definitely give it a try.
Sorry to blow my own horn, but a few months ago we launched a similar project called Quolony https://quolony.com (we are a small startup from Salamanca, Spain). Right now we are working as a free service and we plan to publish it as open-source in the next few months. People can use it individually using a browser extension or in whole sites including our library. We have avatars, synchronized text selection, private and public chats, persistence, cobrowsing, file transfers and a lot more.
Some samples: https://quolony.com/demos/photomess/ (drag and drop) https://quolony.com/demos/quolony/developers/ (shared demo)
At the low level, we extend the browser event model to make it easier to use it in existing applications.
I hope you guys can give it a try and tell me what you think.
Kudos mozilla!
[EDITED: fixed linked]
Sorry to blow my own horn, but a few months ago we launched a similar project called Quolony https://quolony.com (we are a small startup from Salamanca, Spain). Right now we are working as a free service and we plan to publish it as open-source in the next few months. People can use it individually using a browser extension or in whole sites including our library. We have avatars, synchronized text selection, private and public chats, persistence, cobrowsing, file transfers and a lot more.
Some samples: https://quolony.com/demos/photomess/ (drag and drop) https://quolony.com/demos/quolony/developers/ (shared demo)
At the low level, we extend the browser event model to make it easier to use it in existing applications.
I hope you guys can give it a try and tell me what you think.
Kudos mozilla!
[EDITED: fixed linked]
I've been helping test Quolony for a while and the potential for this technology is great. In particular using it as a browser extension with the instant link sharing and cobrowsing gives those otherwise solitary web browsing sessions a certain feel of the metaverse that could be.
As the meme goes, this puts Internet on your Internet.
Tried to enter as "guest"
exception 'Q\Exception' with message 'Invalid auth provider' in /data/quolony/1.1.beta.1785/code/lib/Quolony/q.core.php:2444
Stack trace:
#0 [internal function]: Q\{closure}(Object(Q\Exception))
#1 {main}Still working to solve this, meanwhile you can enter as guest at https://quolony.com and then visit https://quolony.com/demos/photomess/ or https://quolony.com/demos/quolony/developers/
Sorry about that :( we'll look into it
I'm getting pretty tired of people releasing js libraries and not telling you that they depend on jQuery. You don't just add that script to your page, you add that script and jQuery to your page. Stop assuming everyone already has jQuery, guys.
File a bug?
It seems to me that this could be wrapped in a bookmarklet, to be able to use it on any website, no?
Here's a bookmarklet I threw together. You can go to the link given by someone else and then click the bookmarklet to join their session. It messes up if you change pages, though. Maybe there's a way to fix that.
Pretty interesting that it maps reactive UI elements like bootstrap divs which resize properly!
<a href="javascript:( function(){ var%20s=document.createElement('script'); s.setAttribute('src','https://togetherjs.com/togetherjs-min.js'); document.getElementsByTagName('body')[0].appendChild(s); setTimeout(function(){ TogetherJS(this); }, 100); })();">LINK</a>
Pretty interesting that it maps reactive UI elements like bootstrap divs which resize properly!
<a href="javascript:( function(){ var%20s=document.createElement('script'); s.setAttribute('src','https://togetherjs.com/togetherjs-min.js'); document.getElementsByTagName('body')[0].appendChild(s); setTimeout(function(){ TogetherJS(this); }, 100); })();">LINK</a>
We recently built openmic.io to add sound annotation to pictures & websites. This pops up just as we started looking into real-time collaboration. I guess it validates the need for better in-context collaboration tools.
Does anyone know how this would handle an iframe? Could this potentially be 'injected' into a page using bookmarklets?
edit: so, it doesn't handle iframes. Bookmarklets work but are buggy.
edit: so, it doesn't handle iframes. Bookmarklets work but are buggy.
I could see it being used when creating support websites or customer care related websites. Anyone else has any ideas on where else can this be leveraged?
Seems quite similar to GoInstant.
Can someone give me a use case for this?
Was this previously know as towtruck?
yes: https://twitter.com/mozlabs/status/380847329437159424
wonder if they might to add some kind of drawing/annotation tools
wonder if they might to add some kind of drawing/annotation tools
You can try http://eatponies.com for persistent drawing with other people.
Yes. See the name change announcement from earlier today: https://blog.mozilla.org/labs/2013/09/reintroducing-together... . “We wanted a name that reflects the wider scope of how to use the tools.”
Seems similar to ShareJS
The content sync is the really impressive feature here. Basically drop-in multiuser support.
This is very similar to what we do at Firefly (http://usefirefly.com), except we support all the way back to IE 8. Kudos to these guys for putting this together - especially if it works well. It's a lot harder than it looks.
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.
So, I assume this does too, but I haven't seen where I could install it on my server.
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.
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.
[Team member here] We haven't been very focused on the hosting story, in part because lots of people have their own requirements, and we can't predict what they are. And maybe because predicting what they are is boring. I know some hooks for New Relic have been added to the server. It's also a super-simple server that only keeps things in memory, so it's pretty darn easy to handle. Just one file: https://github.com/mozilla/togetherjs/blob/develop/hub/serve... (and only one dependency, for WebSockets).
I think this is what you want: https://github.com/mozilla/togetherjs/wiki/Hosting-the-Hub-S...
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).
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
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
[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.
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.
Is this a free pusher? What's the catch?
[mozilla employee here] There's no catch except an absence of a commitment to keep running it. Mozilla Labs is charged with figuring out how to make the web better. We think this could help make more apps collaborative. You tell us if we're right.
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
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.
> In practice it's quite hard for two browsers to connect directly to each other
Isn't this the problem WebRTC abstracts away? Your server should just be a TURN server (http://en.wikipedia.org/wiki/Traversal_Using_Relays_around_N...), shouldn't it?
Isn't this the problem WebRTC abstracts away? Your server should just be a TURN server (http://en.wikipedia.org/wiki/Traversal_Using_Relays_around_N...), shouldn't it?
WebRTC makes it possible, but not easy, nor abstracted. You still have very long connection strings to establish the connection, and those strings change as you move around, so it's not something we'd want to ask users to send to each other in order to establish a connection. The approach usually used is a server where the two people rendezvous to exchange the connection strings. That server is kind of like what we have – but then once it's in place, changing over to WebRTC just doesn't seem as exciting. (And even then the connections are slower to establish and less reliable than WebSockets.)
AFAIK WebRTC just works with the latest Firefox/Chrome and needs a STUN and/or a TURN server.
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
Does anyone know of something like this, but for Markdown?
So, like a collaborative Markdown document editor, as well as a simple way to store those documents and choose them for reading/editing later.
So, like a collaborative Markdown document editor, as well as a simple way to store those documents and choose them for reading/editing later.
You can actually do that in Plunker right now by having an `index.md` file instead of `index.html` [1].
In the absence of an html index, the plunker preview server will try transpiling to html from different languages. Markdown is currently supported.
Also transpiled are things like less, scss, coffee-script and more. Essentially, your html requests a file with the target suffix (e.g.: .css) and the preview server will search for compatible source files to transpile to that target.
[1] http://plnkr.co/edit/?p=streamer&s=markdown
In the absence of an html index, the plunker preview server will try transpiling to html from different languages. Markdown is currently supported.
Also transpiled are things like less, scss, coffee-script and more. Essentially, your html requests a file with the target suffix (e.g.: .css) and the preview server will search for compatible source files to transpile to that target.
[1] http://plnkr.co/edit/?p=streamer&s=markdown
Wait, that's backwards. The point of Markdown is that you type the formatting quickly, instead of clicking buttons on a toolbar.
That animation seems to be about clicking buttons on a toolbar that will secretly generate Markdown formatting for you.
That animation seems to be about clicking buttons on a toolbar that will secretly generate Markdown formatting for you.
http://socrates.io, built with Firebase.
I agree that it's cool and ambitious, but it seems to have a large intersection with Google Wave.
It integrates with your existing UI, and not as a separate box like Wave or other plugins. I also like that this is free, open source and _from Mozilla_.
All true, but note that the Wave server is free and open source: http://incubator.apache.org/wave/about.html
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).
Both people are accessing the website as themselves. If one person doesn't have permission to see a page, for instance, then they won't see it. And yeah, whoever hits save is the saver ;) Doing something richer than that requires application-specific integration, which we want to support, but we also want to take cues from developers about what that should actually look like. This is one idea we have along these lines: https://github.com/mozilla/togetherjs/issues/372
Used to be called Tow Truck.
NB: unrelated to TogetherJ
I want to implement a real time Collaboration editor like google docs because I want to keep data on my own servers.. Can anyone suggest me architectural points to build that...what should be stack on server side, how to send edit diffs etc..
Have a look at this: http://substance.io/
I'm working on something similar: https://wikidocs.com. Although our's closed source at the moment (can't say whether or not it will remain closed), we will provide a downloadable package you can run yourself.
I'm working on something similar: https://wikidocs.com. Although our's closed source at the moment (can't say whether or not it will remain closed), we will provide a downloadable package you can run yourself.
http://simperium.com/ is exactly what you need. It serves as a real-time data layer; you can push/pull from it from the browser, and pull/push to it from your server too.
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.
give http://etherpad.org/ a shot
Looks like this would be great for customer support, and could be a nice alternative to olark. It can be configured to automatically post the invite url to another dashboard, where one of the CS execs can pick up and walk the user through.
If this was from a startup I would expect a free trial and then a pricing page that told me what happened if I had X # of users or Y # of requests, but without that info, it seems there is a lot of missing information. Does Mozilla just plan to keep it hosted indefinitely? Or how do you plan to handle users of different sizes? Our use case now is small, but in choosing to go with this tool (vs. Firebase or something else), the switching costs down the road are relevant.
I'm planning to try it out in a small test either way, I'm just curious about more details on the mozilla-hosted version.