Manage MUC server-side
udd
First of all, thank you for this great piece of software. It rocks! :)
Unfortunately I've a problem I can't solve and would really appreciate
some input since I'm a real newbie when it comes to XMPP and Prosody.
I manage a web site which have a bunch of users divided into different
groups. I would like to XMPP enable the site (with Prosody). My plan
is that a user should be able to log in with XMPP and then
automatically get a contact list with the users they are in the same
group(s) as. I think I solved that part with the help of mod_groups.
However, I would also like to create a groupchat for each of these
groups.
"Bookmarking" the groups for the corresponding users seems to be
possible via mod_group_bookmarks. However, I haven't found a way to
manage the actual chat rooms server side. Ideally I would like to be
able to create the rooms and manage who is in which group server-side
(without the user having to accept invitations etcetera ).
Do you have any recommendations regarding this? Is it possible to do
this within Prosody in some way? An alternative I have thought about
is to use an XMPP client library to create a program that is triggered
when a new user is registered. It would log in as an admin and invite
the new user to the correct groups, and then log in as the new user
and accept all invitations. However, it would be a bit cumbersome (and
there might be problems with it I haven't anticipated).
Thank you in advance! All input in this matter is really appreciated.
Best regards,
Niklas
Matthew Wild
On 7 June 2011 22:23, udd <nikla...@gmail.com> wrote:
> Hello!
>
> First of all, thank you for this great piece of software. It rocks! :)
>
Thanks! :)
> I manage a web site which have a bunch of users divided into different
> groups. I would like to XMPP enable the site (with Prosody). My plan
> is that a user should be able to log in with XMPP and then
> automatically get a contact list with the users they are in the same
> group(s) as. I think I solved that part with the help of mod_groups.
> However, I would also like to create a groupchat for each of these
> groups.
>
> Do you have any recommendations regarding this? Is it possible to do
> this within Prosody in some way? An alternative I have thought about
> is to use an XMPP client library to create a program that is triggered
> when a new user is registered. It would log in as an admin and invite
> the new user to the correct groups, and then log in as the new user
> and accept all invitations. However, it would be a bit cumbersome (and
> there might be problems with it I haven't anticipated).
>
It sounds like you're 90% of the way there with mod_groups and
mod_group_bookmarks. I agree that using a client to manage the rooms
would be a bit cumbersome.
I'm not 100% sure what the last problem is that you're trying to solve
exactly is. You mention clients having to accept invites - there are
no invites used by mod_group_bookmarks. It works by inserting the room
into the user's room bookmarks store on the server. This is fetched at
login by most clients to display a list of rooms to join and/or
automatically join them at startup.
For the actual room management (e.g. if you want to limit access to
people in the group) then I think a slightly modified mod_muc would be
the best approach. It would fetch the members list from
mod_group_bookmarks (so you don't have to define the groups again).
Thoughts?
Regards,
Matthew
udd
Thank you for your quick reply!
> You mention clients having to accept invites - there are no invites used
> by mod_group_bookmarks.
invitations appeared when I created a members-only room and invited
another user to become a member of that room (via a client). When I
did that the invited user got a question whether to actually become a
member or not. However, this might be a client quirk or I could have
used it incorrectly.
> For the actual room management (e.g. if you want to limit access to
> people in the group) then I think a slightly modified mod_muc would be
> the best approach. It would fetch the members list from
> mod_group_bookmarks (so you don't have to define the groups again).
the rooms and their members in the mod_group_bookmarks file, which is
basically what I would like to do. Do you from the top of your head
have any ideas for the best approach for doing the modifications? I
have just briefly looked at the code for mod_muc so far.
Best regards,
Niklas
Matthew Wild
> Hi!
>
> Thank you for your quick reply!
>
>> You mention clients having to accept invites - there are no invites used
>> by mod_group_bookmarks.
>
> It is possible that I've misunderstood how it should work. The
> invitations appeared when I created a members-only room and invited
> another user to become a member of that room (via a client). When I
> did that the invited user got a question whether to actually become a
> member or not. However, this might be a client quirk or I could have
> used it incorrectly.
>
Inviting a user to a room is literally just that - sending them a
message suggesting they join, they can ignore it, or accept it and
join.
As a bit of additional cleverness, Prosody detects when you invite
someone to a members-only room who is not on the member list. It
automatically adds them so that if they accept, they can join without
problems.
mod_group_bookmarks replaces just the manual invite part - it gives
the client the list of rooms it can join as bookmarks so that it can
choose join itself, without needing invitations. What
mod_group_bookmarks doesn't do (currently) is the membership thing.
>> For the actual room management (e.g. if you want to limit access to
>> people in the group) then I think a slightly modified mod_muc would be
>> the best approach. It would fetch the members list from
>> mod_group_bookmarks (so you don't have to define the groups again).
>
> This solution sounds really nice. It would allow me to fully define
> the rooms and their members in the mod_group_bookmarks file, which is
> basically what I would like to do. Do you from the top of your head
> have any ideas for the best approach for doing the modifications? I
> have just briefly looked at the code for mod_muc so far.
>
I had a look just now and decided to do it a slightly different (and
much simpler) way. I came up with the following code at the end of
mod_group_bookmarks:
local muc_new_room = module:require("muc").new_room;
prosody.events.add_handler("server-started", function ()
for room, members in pairs(rooms) do
local room_name, room_host = jid.prepped_split(room);
if room_name and hosts[room_host] then
local room_jid = room_name.."@"..room_host;
local muc_module = hosts[room_host].modules.muc;
if muc_module
and not muc_module.rooms[room_jid] then
local room = muc_new_room(room_jid);
for member in pairs(members) do
room._affiliations[member] = "member";
end
muc_module.rooms[room_jid] = room;
end
end
end
end);
But note that this is *completely* untested, I haven't even tried to
run it yet, but it's at least a start. If you can and want to pick
this up from here, feel free. I have a release to get out and some
other stuff to do before I'll have time to test it myself.
If we get this working then I think it would be good to put a config
option around it and add it to mod_group_bookmarks in prosody-modules.
Hope this helps,
Matthew
udd
Thanks a lot for your code! This support is very impressive and I
truly appreciate it. Doing the change completely in
mod_group_bookmarks was clever.
I have experimented a bit with the code now. Unfortunately I didn't
get it working right away because I wasn't able to join the rooms
after they were created. I don't know why, but I noticed that mod_muc
adds more to the room than just the _affiliations after muc_new_room
has been called. Since I'm a total newbie to this I might be way off
but I'm thinking that some of the other variables might be needed too.
However, I tried to create the room "manually" and then just have
mod_group_bookmarks update the room affiliations. That appeared to be
working. I need to test it a bit more to be sure though.
I'll try to look more into the room creation thingy and see if I can
find out why it didn't work (unless you beat me to it).
Best regards,
Niklas
On Jun 9, 10:59 pm, Matthew Wild <mwi...@gmail.com> wrote: