Prosody in Darknet
669 views
Skip to first unread message
Valent Turkovic
Sep 13, 2012, 5:08:03 PM9/13/12
to Prosody IM Users
Hello everybody,
I'm working on a wifi/darknet opensource project what provides
communication infrastructure but we would also like to provide
communication services.
I had only contact with XMPP servers as a user, but I'm a long time
linux user/sysadmin and quick to learn ;)
Admin in our local wifi community has used OpenFire XMPP server, we
have nothing but trouble with OpenFire because of memory leaks so I
know what I won't use. I would like to see if Prosody can prvide most
in not all features that we need, and maybe we can even contribute
some new features in the future.
Our first priority is to provide communication channel that is
resistand to single point of failure so that person-to-person chat and
MUC services can't be interupted even when multiple XMPP servers and/
or connections to them suffer failure.
My contribution is by testing which XMPP server would be best in
providing communication service to our project.
If you have any experience Prosofy vs ejabbers or Prosody vs OpenFire
please share them or point to older conversations of this type.
We would like to communication based devices preconfigured with XMPP
server that would run on OpenWrt based embedded linux wifi routers and
on ARM based linux servers like RaspberryPi. Has any body tested how
Prosody behaves on OpenWrt?
What, if any, webui and linux terminal admin tools are availabtle to
setup and manage Prosody?
For local wifi community admins nice to have features are:
- user statistics
* how many users are connected now
* how many users have been connected in last XY hours/days
* listing users that have not logged in in last XY days
* monitoring user activity
** how long users have been online/away/offline in last XY hours/
days
- easy user account administration
* list all users and their roles
* change users role
* create new users
* ban user accounts
* delete users accounts
- manage connectiviry to XMPP servers of other communities
* connect with different communities (to their MUC rooms and clients)
* ban connection to some specific community (their xmpp server)
- logging room communication
* output MUC room logs in html and txt format
- manage your communities xmpp server cluser
* info about any specific server
- secure and private communication if needed
* pgp and OTR support
Which of these features are already implemented, which are something
we will see soon and which are not even planned?
Cheers,
Valent.
I'm working on a wifi/darknet opensource project what provides
communication infrastructure but we would also like to provide
communication services.
I had only contact with XMPP servers as a user, but I'm a long time
linux user/sysadmin and quick to learn ;)
Admin in our local wifi community has used OpenFire XMPP server, we
have nothing but trouble with OpenFire because of memory leaks so I
know what I won't use. I would like to see if Prosody can prvide most
in not all features that we need, and maybe we can even contribute
some new features in the future.
Our first priority is to provide communication channel that is
resistand to single point of failure so that person-to-person chat and
MUC services can't be interupted even when multiple XMPP servers and/
or connections to them suffer failure.
My contribution is by testing which XMPP server would be best in
providing communication service to our project.
If you have any experience Prosofy vs ejabbers or Prosody vs OpenFire
please share them or point to older conversations of this type.
We would like to communication based devices preconfigured with XMPP
server that would run on OpenWrt based embedded linux wifi routers and
on ARM based linux servers like RaspberryPi. Has any body tested how
Prosody behaves on OpenWrt?
What, if any, webui and linux terminal admin tools are availabtle to
setup and manage Prosody?
For local wifi community admins nice to have features are:
- user statistics
* how many users are connected now
* how many users have been connected in last XY hours/days
* listing users that have not logged in in last XY days
* monitoring user activity
** how long users have been online/away/offline in last XY hours/
days
- easy user account administration
* list all users and their roles
* change users role
* create new users
* ban user accounts
* delete users accounts
- manage connectiviry to XMPP servers of other communities
* connect with different communities (to their MUC rooms and clients)
* ban connection to some specific community (their xmpp server)
- logging room communication
* output MUC room logs in html and txt format
- manage your communities xmpp server cluser
* info about any specific server
- secure and private communication if needed
* pgp and OTR support
Which of these features are already implemented, which are something
we will see soon and which are not even planned?
Cheers,
Valent.
viq
Sep 14, 2012, 5:05:09 AM9/14/12
to prosod...@googlegroups.com
On Thu, Sep 13, 2012 at 11:08 PM, Valent Turkovic
<valent....@gmail.com> wrote:
> Hello everybody,
> I'm working on a wifi/darknet opensource project what provides
> communication infrastructure but we would also like to provide
> communication services.
>
> I had only contact with XMPP servers as a user, but I'm a long time
> linux user/sysadmin and quick to learn ;)
> Admin in our local wifi community has used OpenFire XMPP server, we
> have nothing but trouble with OpenFire because of memory leaks so I
> know what I won't use. I would like to see if Prosody can prvide most
> in not all features that we need, and maybe we can even contribute
> some new features in the future.
>
> Our first priority is to provide communication channel that is
> resistand to single point of failure so that person-to-person chat and
> MUC services can't be interupted even when multiple XMPP servers and/
> or connections to them suffer failure.
If you mean "people connected to this server still can talk to each
<valent....@gmail.com> wrote:
> Hello everybody,
> I'm working on a wifi/darknet opensource project what provides
> communication infrastructure but we would also like to provide
> communication services.
>
> I had only contact with XMPP servers as a user, but I'm a long time
> linux user/sysadmin and quick to learn ;)
> Admin in our local wifi community has used OpenFire XMPP server, we
> have nothing but trouble with OpenFire because of memory leaks so I
> know what I won't use. I would like to see if Prosody can prvide most
> in not all features that we need, and maybe we can even contribute
> some new features in the future.
>
> Our first priority is to provide communication channel that is
> resistand to single point of failure so that person-to-person chat and
> MUC services can't be interupted even when multiple XMPP servers and/
> or connections to them suffer failure.
other even if some other server is not reachable" then sure, it's just
like email. If you mean to provide multiple "points of presence" to
connect to for the same domain, and in case of disconnects to create
"islands", then I think the only option currently is clustered
ejabberd.
> My contribution is by testing which XMPP server would be best in
> providing communication service to our project.
> If you have any experience Prosofy vs ejabbers or Prosody vs OpenFire
> please share them or point to older conversations of this type.
and ran ejabberd an prosody in some tiny installations. OpenFire
indeed is rather heavy, for medium sizes (tens, maybe to a bit over a
hundred users) ejabberd and prosody I believe should behave
comparably, resource-wise (I think, correct me if I'm wrong). Though I
guess ejabberd will have still larger memory footprint.
> We would like to communication based devices preconfigured with XMPP
> server that would run on OpenWrt based embedded linux wifi routers and
> on ARM based linux servers like RaspberryPi. Has any body tested how
> Prosody behaves on OpenWrt?
requisite libraries. Once you have that, I don't see any reason why
you wouldn't be able to have couple tens of users, larger amount could
possibly run into some resource problems on such underpowered
hardware, mostly I think memory-wise.
> What, if any, webui and linux terminal admin tools are availabtle to
> setup and manage Prosody?
prosody-modules, I haven't really looked.
> For local wifi community admins nice to have features are:
:P Well, no such luck, though I will provide some things I know about,
and let others tell more. Some possible hits are
https://code.google.com/p/prosody-modules/wiki/mod_adhoc_cmd_admin and
https://code.google.com/p/prosody-modules/wiki/mod_admin_web
> - user statistics
> * how many users are connected now
> * how many users have been connected in last XY hours/days
> * listing users that have not logged in in last XY days
munin that allow you to gather this info.
> * monitoring user activity
> ** how long users have been online/away/offline in last XY hours/
> days
> - easy user account administration
> * list all users and their roles
> * change users role
> * create new users
prosodyctl (cli)
> * ban user accounts
Uhm, just change their password to something only you know?
> * delete users accounts
prosodyctl (cli)
> - manage connectiviry to XMPP servers of other communities
> * connect with different communities (to their MUC rooms and clients)
> * ban connection to some specific community (their xmpp server)
https://code.google.com/p/prosody-modules/wiki/mod_host_guard
> - logging room communication
> * output MUC room logs in html and txt format
https://code.google.com/p/prosody-modules/wiki/mod_muc_log_http
> - manage your communities xmpp server cluser
> * info about any specific server
> - secure and private communication if needed
> * pgp and OTR support
> Which of these features are already implemented, which are something
> we will see soon and which are not even planned?
>
> Cheers,
> Valent.
viq
Matthew Wild
Sep 14, 2012, 6:40:31 AM9/14/12
to prosod...@googlegroups.com
Hi Valent,
On 13 September 2012 22:08, Valent Turkovic <valent....@gmail.com> wrote:
> Admin in our local wifi community has used OpenFire XMPP server, we
> have nothing but trouble with OpenFire because of memory leaks so I
> know what I won't use.
You wouldn't be the first to migrate from Openfire to Prosody because
of such issues!
> Our first priority is to provide communication channel that is
> resistand to single point of failure so that person-to-person chat and
> MUC services can't be interupted even when multiple XMPP servers and/
> or connections to them suffer failure.
How familiar are you with XMPP's architecture? As viq mentioned in his
email, XMPP is already decentralized. But a server going down will
obviously prevent users with accounts on that server from joining the
network. Email is usually a good comparison with XMPP - when gmail.com
goes down, hotmail.com users can still email aol.com users, etc.
> My contribution is by testing which XMPP server would be best in
> providing communication service to our project.
> If you have any experience Prosofy vs ejabbers or Prosody vs OpenFire
> please share them or point to older conversations of this type.
I began developing Prosody 4 years ago after finding problems with all
the other servers for my own projects. I tried jabberd2, Openfire,
ejabberd and Tigase. jabberd2 lacked features I needed (i.e. PEP) and
isn't incredibly active. Openfire - well, you know about that.
ejabberd was fine feature-wise, but I had similar resource usage
problems with it... both for my personal use and when helping to
manage it on jabber.org. I have heard conflicting reports over whether
the major memory usage bugs have been fixed now, and I no longer run
ejabberd anywhere I have access to. Some people have clearly made it
work, mind.
Tigase is another Java server. It's faster than Openfire, I don't know
about memory usage in real-world usage (they publish lots of
benchmarks, but they are generally synthetic and do not emulate a real
IM user [which is quite hard to do]). My main complaints with Tigase
are that (at least back when I tried it) it was very hard to use, and
the developers choose performance over standards compliance (possibly
fine for internal servers).
> We would like to communication based devices preconfigured with XMPP
> server that would run on OpenWrt based embedded linux wifi routers and
> on ARM based linux servers like RaspberryPi. Has any body tested how
> Prosody behaves on OpenWrt?
I've run Prosody on OpenWrt before (I got an OpenWrt compatible router
especially to try it!). It also runs fine on the Raspberry Pi and ARM
Linux in general. The main resources you will struggle for on small
devices is RAM, and sometimes disk space. Prosody depends on OpenSSL
for encryption and hashing, which is many times larger than Prosody
itself! OpenSSL can also cause high RAM usage, but that is thankfully
much better with OpenSSL 1.0 (
http://ayena.de/files/prosody_memory-0.8rc1.png for the unbelievable
graph!).
Packaging for OpenWrt isn't good - as far as I know it's still an old
version packaged, and I have not had time to work on updating it.
Contributions here (from anyone) would be very much appreciated, and I
can help however possible.
> What, if any, webui and linux terminal admin tools are availabtle to
> setup and manage Prosody?
We have:
- prosodyctl (command-line utility): http://prosody.im/doc/prosodyctl
- mod_admin_telnet: http://prosody.im/doc/console
- mod_admin_adhoc (admins can command over XMPP):
http://prosody.im/doc/modules/mod_admin_adhoc
- mod_admin_web (basics working, but not finished yet):
https://code.google.com/p/prosody-modules/wiki/mod_admin_web
> For local wifi community admins nice to have features are:
> - user statistics
Statistics are definitely possible, and will be even better with the
0.9 release. There is a Munin plugin for Prosody, for example:
http://www3.hot-chilli.net/munin/hot-chilli.net/despina.hot-chilli.net/prosody_c2s.html
> * how many users are connected now
Yep, possible already (see above).
> * how many users have been connected in last XY hours/days
This is not possible out of the box, but can be made to work via
mod_lastlog or something similar:
https://code.google.com/p/prosody-modules/wiki/mod_lastlog
> * listing users that have not logged in in last XY days
Could be done with a script the same as above.
> * monitoring user activity
All our live admin interfaces (adhoc, telnet, web interface) support
listing users and showing various details about their sessions. The
next Prosody version will also be compatible with an (until now)
secret project I have been working on:
http://matthewwild.co.uk/uploads/prosodytop.png
> ** how long users have been online/away/offline in last XY hours/
> days
Again, mod_lastlog or similar can help you do this.
> - easy user account administration
> * list all users and their roles
By default Prosody stores all information as human-readable files on
the filesystem. Listing users can be as simple as `ls`. You can also
use a database if you prefer.
If you use the filesystem storage, prosodyctl can list users in a
pretty format with this small module:
http://prosody.im/files/mod_listusers.lua
If you choose to use a database you would have to list users manually
through that until the next Prosody version where we have native
listing of user accounts.
> * change users role
Prosody doesn't have the concept of "roles". You can specify which
JIDs are admins in the config file.
> * create new users
prosodyctl adduser user...@example.org
> * ban user accounts
To prevent access to an account you can change the password, or remove
Prosody's read permission from the file on the filesystem. Banning an
IP is best done through a firewall.
> * delete users accounts
prosodyctl deluser user...@example.org
> - manage connectiviry to XMPP servers of other communities
> * connect with different communities (to their MUC rooms and clients)
> * ban connection to some specific community (their xmpp server)
Like practically all XMPP servers, Prosody supports server-to-server
communication out of the box. You can configure rules on which servers
you do or don't want to connect with through various modules. I'd
currently recommend mod_host_guard as it's available for both 0.8 and
0.9: https://code.google.com/p/prosody-modules/wiki/mod_host_guard
> - logging room communication
mod_muc_log is available in prosody-modules:
https://code.google.com/p/prosody-modules/wiki/mod_muc_log
> * output MUC room logs in html and txt format
You can view the logs through Prosody's internal HTTP server:
https://code.google.com/p/prosody-modules/wiki/mod_muc_log_http
It would also be easy to make a module that adds a prosodyctl command
to generate static HTML and text versions. Just let us know if you
need this.
> - manage your communities xmpp server cluser
> * info about any specific server
Prosody doesn't support clustering, and won't until 1.0 at the
earliest. Many people who think they need clustering can actually do
fine without it, by splitting users between domains (the way XMPP was
designed to work). For people whom this is not adequate, clustering
will come, but it's not going to be in the next few months at least.
A warning (since viq mentioned ejabberd's clustering in his email)...
ejabberd doesn't handle physically distributed clusters very well. It
functions best when all cluster nodes are close to each other. Lots of
data can be exchanged between ejabberd cluster nodes, so having
high-bandwidth and low-latency links between them is best. Also I
don't know if it is solved now (I haven't heard any news that it is) -
ejabberd often doesn't like nodes becoming unreachable, and it's
possible for nodes to get out of sync with each other. As far as I
know the only way to fix a cluster broken this way is a reboot of all
nodes or magical erlang incantations.
ejabberd clustering is not simple! Part of the reason we haven't
jumped into clustering in Prosody is to make sure we do it right,
learning from ejabberd's problems. I would very much like our
clustering easy to use, and support any kind of network link between
nodes. I don't complain too much about ejabberd's inability to do this
well - it's very hard!
> - secure and private communication if needed
> * pgp and OTR support
These are client things, and will work with Prosody and any server.
> Which of these features are already implemented, which are something
> we will see soon and which are not even planned?
We generally implement things based on what people want. If you
haven't noticed already Prosody is very modular - our goal from the
beginning has been to make writing modules really easy. This is why
many of our features are in modules. It also means unwanted features
can be easily disabled and removed to save resources when necessary.
Hope all this helps! Good luck with your project.
Regards,
Matthew
On 13 September 2012 22:08, Valent Turkovic <valent....@gmail.com> wrote:
> Admin in our local wifi community has used OpenFire XMPP server, we
> have nothing but trouble with OpenFire because of memory leaks so I
> know what I won't use.
of such issues!
> Our first priority is to provide communication channel that is
> resistand to single point of failure so that person-to-person chat and
> MUC services can't be interupted even when multiple XMPP servers and/
> or connections to them suffer failure.
email, XMPP is already decentralized. But a server going down will
obviously prevent users with accounts on that server from joining the
network. Email is usually a good comparison with XMPP - when gmail.com
goes down, hotmail.com users can still email aol.com users, etc.
> My contribution is by testing which XMPP server would be best in
> providing communication service to our project.
> If you have any experience Prosofy vs ejabbers or Prosody vs OpenFire
> please share them or point to older conversations of this type.
the other servers for my own projects. I tried jabberd2, Openfire,
ejabberd and Tigase. jabberd2 lacked features I needed (i.e. PEP) and
isn't incredibly active. Openfire - well, you know about that.
ejabberd was fine feature-wise, but I had similar resource usage
problems with it... both for my personal use and when helping to
manage it on jabber.org. I have heard conflicting reports over whether
the major memory usage bugs have been fixed now, and I no longer run
ejabberd anywhere I have access to. Some people have clearly made it
work, mind.
Tigase is another Java server. It's faster than Openfire, I don't know
about memory usage in real-world usage (they publish lots of
benchmarks, but they are generally synthetic and do not emulate a real
IM user [which is quite hard to do]). My main complaints with Tigase
are that (at least back when I tried it) it was very hard to use, and
the developers choose performance over standards compliance (possibly
fine for internal servers).
> We would like to communication based devices preconfigured with XMPP
> server that would run on OpenWrt based embedded linux wifi routers and
> on ARM based linux servers like RaspberryPi. Has any body tested how
> Prosody behaves on OpenWrt?
especially to try it!). It also runs fine on the Raspberry Pi and ARM
Linux in general. The main resources you will struggle for on small
devices is RAM, and sometimes disk space. Prosody depends on OpenSSL
for encryption and hashing, which is many times larger than Prosody
itself! OpenSSL can also cause high RAM usage, but that is thankfully
much better with OpenSSL 1.0 (
http://ayena.de/files/prosody_memory-0.8rc1.png for the unbelievable
graph!).
Packaging for OpenWrt isn't good - as far as I know it's still an old
version packaged, and I have not had time to work on updating it.
Contributions here (from anyone) would be very much appreciated, and I
can help however possible.
> What, if any, webui and linux terminal admin tools are availabtle to
> setup and manage Prosody?
- prosodyctl (command-line utility): http://prosody.im/doc/prosodyctl
- mod_admin_telnet: http://prosody.im/doc/console
- mod_admin_adhoc (admins can command over XMPP):
http://prosody.im/doc/modules/mod_admin_adhoc
- mod_admin_web (basics working, but not finished yet):
https://code.google.com/p/prosody-modules/wiki/mod_admin_web
> For local wifi community admins nice to have features are:
> - user statistics
0.9 release. There is a Munin plugin for Prosody, for example:
http://www3.hot-chilli.net/munin/hot-chilli.net/despina.hot-chilli.net/prosody_c2s.html
> * how many users are connected now
> * how many users have been connected in last XY hours/days
mod_lastlog or something similar:
https://code.google.com/p/prosody-modules/wiki/mod_lastlog
> * listing users that have not logged in in last XY days
> * monitoring user activity
All our live admin interfaces (adhoc, telnet, web interface) support
listing users and showing various details about their sessions. The
next Prosody version will also be compatible with an (until now)
secret project I have been working on:
http://matthewwild.co.uk/uploads/prosodytop.png
> ** how long users have been online/away/offline in last XY hours/
> days
> - easy user account administration
> * list all users and their roles
the filesystem. Listing users can be as simple as `ls`. You can also
use a database if you prefer.
If you use the filesystem storage, prosodyctl can list users in a
pretty format with this small module:
http://prosody.im/files/mod_listusers.lua
If you choose to use a database you would have to list users manually
through that until the next Prosody version where we have native
listing of user accounts.
> * change users role
Prosody doesn't have the concept of "roles". You can specify which
JIDs are admins in the config file.
> * create new users
prosodyctl adduser user...@example.org
> * ban user accounts
To prevent access to an account you can change the password, or remove
Prosody's read permission from the file on the filesystem. Banning an
IP is best done through a firewall.
> * delete users accounts
prosodyctl deluser user...@example.org
> - manage connectiviry to XMPP servers of other communities
> * connect with different communities (to their MUC rooms and clients)
> * ban connection to some specific community (their xmpp server)
communication out of the box. You can configure rules on which servers
you do or don't want to connect with through various modules. I'd
currently recommend mod_host_guard as it's available for both 0.8 and
0.9: https://code.google.com/p/prosody-modules/wiki/mod_host_guard
> - logging room communication
mod_muc_log is available in prosody-modules:
https://code.google.com/p/prosody-modules/wiki/mod_muc_log
> * output MUC room logs in html and txt format
https://code.google.com/p/prosody-modules/wiki/mod_muc_log_http
It would also be easy to make a module that adds a prosodyctl command
to generate static HTML and text versions. Just let us know if you
need this.
> - manage your communities xmpp server cluser
> * info about any specific server
earliest. Many people who think they need clustering can actually do
fine without it, by splitting users between domains (the way XMPP was
designed to work). For people whom this is not adequate, clustering
will come, but it's not going to be in the next few months at least.
A warning (since viq mentioned ejabberd's clustering in his email)...
ejabberd doesn't handle physically distributed clusters very well. It
functions best when all cluster nodes are close to each other. Lots of
data can be exchanged between ejabberd cluster nodes, so having
high-bandwidth and low-latency links between them is best. Also I
don't know if it is solved now (I haven't heard any news that it is) -
ejabberd often doesn't like nodes becoming unreachable, and it's
possible for nodes to get out of sync with each other. As far as I
know the only way to fix a cluster broken this way is a reboot of all
nodes or magical erlang incantations.
ejabberd clustering is not simple! Part of the reason we haven't
jumped into clustering in Prosody is to make sure we do it right,
learning from ejabberd's problems. I would very much like our
clustering easy to use, and support any kind of network link between
nodes. I don't complain too much about ejabberd's inability to do this
well - it's very hard!
> - secure and private communication if needed
> * pgp and OTR support
> Which of these features are already implemented, which are something
> we will see soon and which are not even planned?
haven't noticed already Prosody is very modular - our goal from the
beginning has been to make writing modules really easy. This is why
many of our features are in modules. It also means unwanted features
can be easily disabled and removed to save resources when necessary.
Hope all this helps! Good luck with your project.
Regards,
Matthew
Valent Turkovic
Sep 18, 2012, 4:10:55 AM9/18/12
to prosod...@googlegroups.com
Thanks for awesome answers! I'm really thankful for both great answers.
I'll definitely then try to use latest version of prosody on openwrt and on Raspberry Pi and report back how it works. I'll also help (if I have the skills needed) to package latest prosody for openwrt.
I would also like to help and edit prosody wiki if needed, but from what I have seen documentation is really great already.
Only thing I really regret is that prosody can't be used in clusers like ejabberd, but that is ok for local cummunities but not for projects that would take something like PirateBox[1] and extend it with robust communication platform on top of a mesh wifi network.
Cheers,
Valent.
[1] http://wiki.daviddarts.com/PirateBox
I'll definitely then try to use latest version of prosody on openwrt and on Raspberry Pi and report back how it works. I'll also help (if I have the skills needed) to package latest prosody for openwrt.
I would also like to help and edit prosody wiki if needed, but from what I have seen documentation is really great already.
Only thing I really regret is that prosody can't be used in clusers like ejabberd, but that is ok for local cummunities but not for projects that would take something like PirateBox[1] and extend it with robust communication platform on top of a mesh wifi network.
Cheers,
Valent.
[1] http://wiki.daviddarts.com/PirateBox
Matthew Wild
Sep 18, 2012, 5:47:18 AM9/18/12
to prosod...@googlegroups.com
On 18 September 2012 09:10, Valent Turkovic <valent....@gmail.com> wrote:
> Thanks for awesome answers! I'm really thankful for both great answers.
>
> I'll definitely then try to use latest version of prosody on openwrt and on
> Raspberry Pi and report back how it works. I'll also help (if I have the
> skills needed) to package latest prosody for openwrt.
Thanks!
> Thanks for awesome answers! I'm really thankful for both great answers.
>
> I'll definitely then try to use latest version of prosody on openwrt and on
> Raspberry Pi and report back how it works. I'll also help (if I have the
> skills needed) to package latest prosody for openwrt.
> I would also like to help and edit prosody wiki if needed, but from what I
> have seen documentation is really great already.
just let us know if you see anything that could be improved, we're
generally quick about incorporating feedback on the documentation.
> Only thing I really regret is that prosody can't be used in clusers like
> ejabberd, but that is ok for local cummunities but not for projects that
> would take something like PirateBox[1] and extend it with robust
> communication platform on top of a mesh wifi network.
projects! But as I mentioned, transparent mesh networking for
something like IM isn't an easy thing to solve (but certainly it's
possible). I really don't think you would have much joy trying to use
an ejabberd cluster for it either - ejabberd's clustering protocol is
just not designed for that kind of usage.
Regards,
Matthew
Phi H
Nov 11, 2013, 2:38:28 AM11/11/13
to prosod...@googlegroups.com
How did this project work out? I am involved in a nearly identical effort, but have been using openfire thus far but it is eating too many of my resources. I am very interested in putting prosody on an embed with openwrt. Could someone please get back with me in regards to whether this went anywhere? I'd hate to waste the effort doing something that you guys have already worked out. Thanks - P
Reply all
Reply to author
Forward
0 new messages