What is Reddit's opinion of Prosody?

From 3.5 billion Reddit comments

At a small company, I used prosody as a jabber server, that I think used around 20MB of ram. took about 15 min to setup... and was an absolute dream compared to the openfire server I had setup before.

We used pidgin as a chat client, and it worked very, very well.

IRC's really not the way to go. You can certainly log activity, but there's no clean/easy/in-client way for your users to see it when they log in.

I've got experience setting up XMPP, and it works well in a team environment. I don't have personal experience with audio calls, but Jingle is a XMPP protocol extension designed to handle that.

Prosody is a lightweight XMPP server coded in Lua that apparently has Jingle support. http://prosody.im/doc/jingle other servers might, as well. You'd want a client like Pidgin that handles the Jingle extension.

It absolutely can be used as a standalone application. The Prosody XMPP server is a great example of that.

The main thing against it is, as Ubertekk stated, the fact that there aren't as many readily available high quality libraries for lua as there are for perl or python or ruby (or whatever) so there is likely to be a cost associated to going this route that there might not be going with other languages or embedding lua.

One other point, many things that "embed" lua are actually just getting things set up to the point that lua can take over and then most of the application/etc. happens once lua has been brought into play.

Hi, author of converse.js here.

I use and recommend Prosody. It's written in Lua, which is a very fast scripting language which looks similar to Python.

It's easy to set up, has a good selection of plugins and a great community.

http://prosody.im/

Edit: The conversejs.org XMPP server runs on Prosody.

Some client with OTR and a inhouse server?

Conversations (XMPP client) - https://f-droid.org/app/eu.siacs.conversations

xmpp server - http://prosody.im/

or hipchat server, if you do not want to support it your self. Works with xmpp clients.

I'd recommend http://prosody.im/ over openfire, but I guess it is swings and roundabouts really.

Add a couple of bots to your chatrooms for alerting - e.g. if your service monitoring detects an outage it should announce it to a "noc-room", as well as emailing/paging on-call folk.

Other suggestions I'd have include OpenVPN, nginx/apache, backuppc, and git/mercurial for source-serving. (Perhaps redmine for hosting projects publicly.)

The open source alternatives:

http://friendica.com/ also a federated social network alternative

http://identi.ca/ the real alternative to the twitter, run a federated service yourself.

http://prosody.im/ an alternative to google chat, run a service yourself. or pick a different jabber server if it will fit better

But your post would fit better under /r/privacy .

I used openfire with spark. It was nice because it can do a lot but if you need something simple that's very, very small, check out prosody. Just because its lightweight doesn't mean it won't work for you!

XMPP server and you can federate it with services like google chat if you have clients that want to write your employees directly, just add a srv record. With prosody, I use pidgen.

http://prosody.im/

If you want to abstract the game into chat rooms, then definitely take a look into XMPP. Pick an xmpp server, write modules/components/bots to extend the core chat functionality, and then take a look at some xmpp libraries like Strophe (http://strophe.im/) to create the browser client. So for example, if a chat room represented a blackjack table, you could create a plugin/bot that acts as a dealer for that particular room, and then users can interact with this bot (and the bot can then save information to the database, or whatever). Just one way to think about it.

XMPP is a protocol that already has standards in place for multi-user chat, and xmpp also supports BOSH (another type of long-polling technique, like COMET), which handles the need for a persistent connection.

More mature xmpp servers support server clustering if you worried about scalability (ejabberd, openfire). I'd recommend that you look into Prosody though (http://prosody.im/).

Lastly, I don't see how you can avoid using a database. You need to store the game assets somewhere (room descriptions, player attributes, and so on).

You can look at building your own chat server from scratching using node.js, or twisted, or ruby eventmachine, but I myself would just go with a tried and tested chat server (hence the xmpp love), and then build off that.

Although, I think I'd be far too tempted myself to give this a shot with Node.js. Seems like the perfect project to really learn something new with.

Well, my use of XMPP is simple, it replaces Whatsapp, each user have an account in the way of doogalbear@server ip or domain name. You can create groups and as the admin, you can send messages at all your users (thats the way that fit your needs). Images, audio can be attached too.
I have a nas and easily installed OpenFire which might be too resources consuming for your rpi but Prosody is said to be light and easy to manage (used on a VPS along with Jitsi).
For your users, it just downloading an xmpp app (I use Conversation) enter their username and password (you can create all your users and password or let them create their u&pwd by opening your xmpp server to free registration). No ads, no cost, everithing mentioned (except the VPS!) is open-source and free. If needed I can provide you help to install all mentioned.

Interoperability is apparently bad for business because every single one of these chat services requires that you use their client, mainly by not creating an API and frustrating reverse engineering attempts through technical and legal means. Unfortunately most people don't know better and just nag their contacts to use iMessage, Facebook Messenger, Whatsapp, Skype, WeChat, Instagram, Snapchat, Google Hangouts, etc. There are no multi-service clients (e.g. AIM/ICQ/MSN) so if you want to talk to everyone you end up saddling your phone with multiple bloated apps that bleed off battery charge and probably sell your (fragmentated) contact list and transcripts to the highest bidding marketing firm.

The technology for one Internet chat service to rule them all already exists: it's called XMPP. Unfortunately it probably won't take off without a huge marketing bonanza and default status on at least one OS. That doesn't prevent you from setting up your immediate circle with chat that's not crippled by vendor lock-in. Then you'll be able to use a desktop client, use OTR encryption, use first names as usernames (they're usually taken on public mass market services), and/or even host the server yourself for full control.

http://en.wikipedia.org/wiki/XMPP with something like https://www.process-one.net/en/ejabberd/ or http://prosody.im/download/start?

Setting it up might be a little bit too difficult, though. Wanted to mention it, nevertheless.

we ran into tons of problems with S2S with openfire 3.6.0. Not to mention found we were rebooting the server about once a week or more, because it was out of memory (it had 2G)...

Seriously take a look at prosody I run twice as many accounts now, using 20MB of ram, and its been up for months...

We had this thread a few weeks ago so it may be helpful to look back as well.

I recommend prosody for XMPP communication.

Openfire is nice but a little too bloated and can be complicated.

Prosody is lightweight and easy to install. Federation with gmail and other xmpp is simple.

http://prosody.im/

• http://prosody.im/ (backend)
• All xmpp servers implement multi-user chat
• I'm basically hooking up a custom module to regular old chatrooms to achieve what I need. So, if someone sends a song, they are in fact sending a special kind of chat message containing song information.
• My custom module intercepts these messages and handles syncing on the backend.
• The pub/sub stuff you see on the frontend is really just to help with loose-coupling. The different models/views ultimately need to communicate with the Connection object, and I chose a pub/sub approach to achieve that.
• Lastly, xmpp supports pub/sub as well. So, you should definitely still investigate if that is what you are looking for: http://xmpp.org/extensions/xep-0060.html