[tor-dev] OFTC-i2p Relay Bot for #tor/#tor-dev

[ihave2p]

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

Hello and greetings,

I was referred to this list by velope at oftc and have spoken directly with 
isis at oftc with regard to administering a relay bot for #tor/#tor-dev 
between Irc2p (i2p) and OFTC. To my joy, isis at 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>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBAgAGBQJT5eR2AAoJEHlp9aX4A0xf/RUQAKCAFSgiXHCI6NPwBL/+TDUp
0dp4R2oqxspcs1x7v2wV4SL2iuwYjWDMAjLtW7qwPFLLlPX+2nS0Jxbye01pLxHy
ftJ0Bj+MY2q+4o4mQ5x1iGRPEukWm6zJgK0kI7BU/0yoennD4+TrBUygFIq0eS9g
muJReWX3iNsFjhkJnE3ZoRA6CFequ+1Aiy5erInZkjqzG7tqlP6qZ3LM5cY4Ig3M
uYWZCLBpSnlEimZX2EdPeFuwbSPGGur0QfIEfw3RHyibDy4XU1E1clAROHv+8bww
x3+06CG4Xbn5UxMOicHBr//8nHFngGMWPZgKDKcPpEqiNPskkMX018xVYeLi7VYY
syNC2Ioq/fY5w0XvIRZ+tQoeizndqurn2Lq5ZT+Rfwjg6irbPlOnR7Cld/SDAjZ0
7/u0pB8X//Eg/wCq+piFe7KFMGh29/QBCa6f0I8T+vQ5ktoLz8TD8Q+OVWmvk4uZ
sGH7OTb6yUjwe3kGZFuHPwQ7tT/0FO4n8IEq0btAfuLU6ve2EAFl5BMie+2W8KhK
zQ/SxX2ihiFaGnp7K/pVhR16n7AVLQbWFk4E5tQZgwByQSev5c+PUIdfjLBGM+lo
rnU5OwEk+ppSMJeizACX9eU+j97lp8kVCAXzBjN8L5lvGTZPkbGEcL1M+KtWRI3+
ggv0IQw2pB76ulg85Dmw
=m6lI
-----END PGP SIGNATURE-----