-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Hello and greetings,

I was referred to this list by velope@oftc and have spoken directly with isis@oftc with regard to administering a relay bot for #tor/#tor-dev between Irc2p (i2p) and OFTC. To my joy, isis@oftc has happily granted permission to start a 'testing' phase of the bot pending the final decision from the Tor devs about the bot's #tor/#tor-dev fate. As it stands, the only hiccups the bot has seen were within the first 15-20 minutes of initial deployment but now, after several days, it has proven to be more helpful than not and it has since ran without incident.

The bot is a barebones Limnoria with default plugins (set to private) and LinkRelay from https://github.com/ProgVal/Supybot-plugins. The bot masks hostnames with either 'oftc' or 'i2p' and currently serves no other function than relaying. As it stands, all bot responses are privmsg'd so as not to spam the channels and the bot will not relay non-privmsg relay messages i.e., joins, parts, nicks, quits, modes, etc. to anyone.

I'm writing to clarify how you would like to approach the administration of the bot should things go awry. It will only connect to OFTC via tor as I cannot expose myself to clearnet/i2p identity correlation (I'm well aware of OFTC's temporary blacklistings of Tor exit nodes so I've also taken that into consideration with regard to management).

Listed are my preferred options for your consideration. All comments/suggestions are welcome.

1) Off-topic chatter from i2p can be redirected to #nottor (a general "hey you, go to #nottor" to an i2p user would suffice. Note: #nottor on i2p is *NOT* relayed to OFTC but instead, redirects i2p users to our non-Tor community channels). 2) Currently, the bot will *not* auto-rejoin when kicked. If it is ever kicked, we can discuss why and then take further action if needed. 3) "ChanOp Exchange Initiative": OFTC ChanOps could have the ability to mute or kick users on i2p's side, and vice versa. This could be very useful to both parties once both have considered the other trustworthy. 4) OFTC ChanOps could have the ability to start/stop relaying and/or start/stop nick-specific relaying (tricky, but I believe possible). 5) Worst-case scenario: the bot would relay *all* OFTC users but only +voiced i2p users.

Presently, I'm founder/op (the only op) for #tor/#tor-dev/#tails on Irc2p but if more ops are needed, I'll see who is available. Irc2p has flood protection and I have yet to see any Irc2p abuse outside of the occasional troll or ill-informed user. Let it be known: irc bot management/deployment is not my forte nor do I find it terribly interesting but I'm passionate about facilitating easy/anonymous communications between our two networks - so I'll "take one for the team" and try to make everyone happy with what we're achieving.

For the time being, I'll attend to the bot very regularly and I don't foresee ever leaving it alone for more than a day or two (even after the 'testing' phase is complete). If I'm away for longer than that, I'll make the appropriate notifications/arrangements and, if needed, I'll simply take the relay offline. To reach me if I'm not available on either network, the bot's "real name" has my i2pmail.org (mail.i2p) address and PGP key (FYI, in case you were wondering, the bot has its own SSL cert and is registered on both networks).

Thank you for your time and consideration. For those who aren't familiar with Irc2p, is not nearly as large as OFTC but I feel that strong minds/talents are on both sides and that all would benefit from the relay. I look forward to a growing bond between our communities.

ihave2p 0xF8034C5F <ihave2p [at] mail.i2p>