Sorry for my first post being a new thread

A few days ago me and a ingame friend started to work on a new relay system that uses a third bots privategroup to relay the chat from five guilds. All orgbots join that privategroup and send their chat there while copying what other bots say to their own guildchat.
With five bots sharing chat this works much better and faster than using tells (sending the same tell to all other bots) and it does not introduce as many problems like a IRC solution.

We use our own bots. No Bebot, Buda or IGN. However, some of the other guilds we want to relay with use these, so we started to make plugins for those bots... Bebot gives some serious trouble there, because it doesn't offer the ability to join another privategroup at all. Here is what I had to modify to make it work. Maybe this (or something like this) can make it into a later release of Bebot.
It is imho a important core change.

Main.php
Find the line "default:" "in function callback($type, $args)" and add the following before "default:"
<?php
case AOCP_PRIVGRP_INVITE:
$bot -> inc_pginvite($args);
break;
?>
Bot.php
Somewhere in the file add:
<?php
function inc_pginvite($args)
{
$group = $this -> aoc -> get_uname($args[0]);
if (!empty($this -> commands["pginvite"]))
{
$keys = array_keys($this -> commands["pginvite"]);
foreach ($keys as $key)
$this -> commands["pginvite"][$key] -> pginvite($group);
}
}
?>
Now in every plugin you can register $commands["pginvite"][] = &$class to catch incoming privategroup invitations.

<?php
$example = new Example($bot);
$commands["pginvite"][] = &$example;
class Example
{
function Example(&$bot)
{
$this -> bot = &$bot;
}

function pginvite($group)
{
$this -> bot -> aoc -> privategroup_join($group);
}
}
?>
Now there is another problem with "inc_pgjoin", "inc_pgleave" and "inc_pgmsg" in Bot.php. Those functions always assume it is the bots own privategroup that invoked those functions, which is no longer the case.
$args[0] in all three of these functions contains the UID of the privategroup owner that invoked the function. Right now it is completely ignored. Here is how I modified "inc_pgjoin" in Bot.php:

<?php
function inc_pgjoin($args)
{
$pgname = $this -> aoc -> get_uname($args[0]);
$user = $this -> aoc -> get_uname($args[1]);
$this -> log("PGRP", "JOIN", $user . " joined privategroup ".$pgname.".");
if (!empty($this -> commands["pgjoin"]))
{
$keys = array_keys($this -> commands["pgjoin"]);
foreach ($keys as $key)
$this -> commands["pgjoin"][$key] -> pgjoin($user, $pgname);
}
}
?>
"inc_pgleave" and "inc_gmsg" need to be altered in the same way.

<?php
function inc_pgleave($args)
{
$pgname = $this -> aoc -> get_uname($args[0]);
//snip
$this -> commands["pgleave"][$key] -> pgleave($user, $pgname);
//snip
}
?>
<?php
function inc_pgmsg($args)
{
$pgname = $this -> aoc -> get_uname($args[0]);
//snip
$this -> commands["pgmsg"][$comms[$i]] -> pgmsg ($user, $args[2], $pgname);
//snip
$this -> commands["privgroupall"][$comms[$i]] -> privgroupall($user, $args[2], $pgname);
//snip
}
?>
Now all guestchannel functions that use these three need to make sure that $pgname == $this -> bot -> botname before they react. If $pgname is not the botname, the function was invoked from another privategroup (someone joined or left another privategroup or the message comes from another privategroup).
Since the $group variable is given last, no alterations need to be made to any module UNLESS you really want to use other bots/players privategroups with your bot.
If you're not using other privategroups you can keep ignoring $pgname.

Last, send_pgroup in Bot.php needs to be altered so we can send chat to other privategroups.

<?php
function send_pgroup($msg, $group = NULL)
{
if ($group == NULL)
$group = $this -> botname;
$gid = $this -> aoc -> get_uid($group);
$send = true;
if (preg_match("/<a href=\"(.+)\">/isU", $msg, $info))
{
if (strlen($info[1]) > $this -> maxsize)
{
$this -> cut_size($msg, "pgroup");
$send = false;
}
}
if ($send)
{
$msg = str_replace("<botname>", $this -> botname, $msg);
$msg = str_replace("<pre>", str_replace("\\", "", $this -> commpre), $msg);
$msg = utf8_encode($msg);
$this -> aoc -> send_privgroup($gid, "<font color=" . $this -> group_color . ">" . $msg . "</font>");
}
}
?>
That's it. Now the bot is ready to interact with other privategroups than his own.

Well this is a nice concept. My concern would be people mass-inviting the bot to private groups all around so it would need some concideration as for security.

I am thinking setting an access level requirement on this, but that would give the relay bot some access to the guild/raid bot and I'm not sure that it would be appropriate.

A better alternative might be a special configuration directive/setting that gives only approved relay bots access to the command.

Also it would need conciderations as to set up filters for what's relayed and the overhead caused by such a filter needs to be evaluated.

Lastly conciderations need to be put into wether or not this should be a replacement for the existing guild relay. I don't think that's fesable as the relaying bot is not bebot and thus this would most likely remain a custom module as we have got no control over which bot is used as a relay bot and implementing filters would be hard concidering that we cannot dictate how messages are relayed or presented by the relay bot. I might be wrong on this tho.

Also setting up a dedicated relay bot for a two-guild relay might be concidered overkill.

This would need more research before being put into SVN and with the current development rate I am thinking 0.5 is most likely target for this.

I like the concept, and yes, bebot is missing this. So I may get around to add it soon to SVN.

Just got to get a handle on the security side as Blueeagle said.

As for security, why can't it be something as simple as adding a list of approved private groups it can join?  If it gets an invite from an approved person/bot/etc, it joins, else it ignores it.

Nothing wrong with this, that's the idea I favor too.

Looks perfectly fine. If (!empty($this -> commands["pginvite"])) comes up false it means it is really not defined. Add a debug echo to the very beginning of your module php file and to your classes constructor.
Only reason I can see for it not to work is that the bot does not load the module php file and the line "$commands["pginvite"][] = &$relay;" is never processed.

You running that bot in raid mode? Wouldn't load then, Main.php loads GUILD modules only in guild mode, as RAID modes are only loaded in raid mode.

Changes to Main.php and Bot.php commited to SVN (with just slight visual changes).

I don't like the double use of access rights for pgmsg, best would be to add extpgmsg as a dedicated new channel to right management.

I don't really care for it either, but adding a second way of handling private groups smacks of the same thing as tell and tell2.

A private group is a private group in a lot of ways, but whats really needed is a way of controlling if it responds to commands outside of it's own privategroup.  (For example you may want it to join private groups to monitor whats going on, but not actually respond to commands there.)

I think it's something different then tell and tell2, as we are dividing the handlers for those commands based on the channel of origin, not on any membership of the caller.

Though I'm not sure we want to add any central access control for commands in those external chat groups, instead of handling valid channels to join and callers for commands inside any module using external chat groups.

As long as we got no default modules supporting any external chat groups I don't see much point in implementing any centralized security.