Broadcast Chat Proof of Concept

[hallahan]

I wrote a chat application I like to call "Broadcast" with socket.io that I was talking about earlier. I quickly put a SFW in an iframe just for a proof of concept. Anyhow, I'd like to know everyone's opinions with this--if it is a good idea to integrate this as a plugin? Also, One idea for how this can develop is to actually have the broadcast have it's own port and process and integrate on the plug-in, client side. Then, maybe consider integrating it with the server.

I've had it running for about a month without it going down. Maybe we could use this as a communication medium with the project. I really think it would be a great idea to start using our own technologies instead of github/freenode. This could be hosted at the outpost (wiki.theoutpost.io), or Ward could host it on fed.wiki.org

http://theoutpost.io/

[WardCunningham]

An interesting demo for sure. Thanks for putting that together.

Allow me to think crazy for a moment:

Let's say there is a page on your own federated wiki server that is engaged in a chat. That means that the javascript that has rendered items of type==chat might connect to the message reflector captured in the item to look for more content. When content comes up the stream, the plugin makes more items in your page to hold it. When you want to send content, you pick any item and edit it, probably by typing a blank line which will be interpreted as starting a new paragraph.

Some things I like about this is that it isn't strictly chronological. You put your comments in the flow where they belong. You can also edit out the noise and keep the parts of the conversation that you find relevant to the subject: the title of the page. (But what does it mean to drag a chat item to another wiki page with another title?)

[hallahan]

This idea will tread uncharted territory with UI design. Though the idea is crazy, it has occurred to me that this can be done in a fairly short span of time in a sane manner. I have already implemented a NodeJS app that you have seen, and it is fully functional. The code is a bit sloppy, and there is a bug or 2 lurking, but it has been live for about a month and has not crashed.

Still, I think it should be rewritten in coffeescript. The quality of the code does not have the deliberate, zen-like approach that SFW is taking. That being said, I started to muck about with trying to integrate the server code I have written with SFW, and it really is overwhelming. I think a more sane approach in engineering this would be to keep the two projects separate for the time being. Instead, functionality can be implemented as a plug-in for SFW. The real time stuff can stay with The Outpost's Broadcast.

The way that I deal with data is that every keystroke of the user broadcasts the contents of the textarea back to the server via socket.io. Then, the server sends that out to everyone connected except the sender. When the user presses enter, that message is persisted to the server's persistent data store (JSON files similar to SFW's model).

My suggestion is to have Broadcast do a HTTP POST to SFW whenever a message is persisted. I have a feeling that this can be an extremely robust approach. If Broadcast fails, it doesn't matter for SFW. It also walks down the path of using multiple NodeJS processes and possibly separating the interests of real-time and history between two completely separate machines.

The concept of non-linear conversation i think is a very important milestone to get to. Because multiple people may be adding to a conversation in any given location of a view, we would have to think of some new way to bind the identity of the speaker to the message. All chat UI up to this point simply attaches a label to a block of text. This approach doesn't work well with non-linear conversation.

I have been playing around with SFW on my site, and I have a list of issues I have come across in casual usage:

http://theoutpost.io:3000/view/welcome-visitors/view/sfw-issues

[caquilino]

I love this feature. You could have chat revision history too. It'd be like a more granular Wiki "Talk" page.

EtherPad and ApacheWave do real-time web chat and revision history too. I don't know the technical details. But maybe they could provide inspiration for how to do it in SFW. I don't program. I just advocate for Federated Wiki.

Wordpress also has real-time chat and federated features: OStatus and other plugins.

[almereyda]

I believe https://github.com/hallahan/broadcast can still play a role either as operational-transform-real-time-reference-implementation #384 or as a persistent chat #88 (comment) .