- 1 Introduction
- 2 I. Going from @irc2p to @clientHASH.b32.i2p
- 3 II. What about my registered nickname(s) and password(s)?
- 4 III. I had some channels on old irc2p. What about them ?
- 5 IV. A few words about memoserv
- 6 V. Final notes
A user's guide to the new Irc2P network
Now, after weeks of preparation we're ready to move the operation of the "official" I2P IRC network to a new home. This results in new IRC daemons and a new services package, which means there will be a number of changes that affect each and every one of you. To avoid any issues related to your nick(s) and channel(s) read this guide. Hopefully It covers all update related changes and allows you to have a smooth migration yourself.
Organizational stuff first.
The network will be moved to new servers on 2014-02-23 between 1:00 P.M. UTC and 4:00 P.M. UTC. Expect the service as a whole being unreachable during that time. We'll need a bit to dump and convert the services database, run some tests with it on the new network and reconfigure tunnels and I2P stuff. Please be patient. If we run into bigger problems the old network will be reinstated as a fallback.
The network will have a new member server. irc.dg.i2p, hosted by I2P community oldtimer dg. Please add irc.dg.i2p to the server list in your IRC client tunnel settings. If the server is not yet in your address book, visit a jump service to add it to your address book. dg himself will then be a fully featured IRCop on the network.
irc.freshcoffee.i2p is planned to have a longer downtime. It will rejoin the network a few days later. To distribute the client load better, once again, make sure to add the new server irc.dg.i2p to your client tunnel settings.
You can add the b32 for this server, too:
The b64 entry for irc.dg.i2p is:
Or with the addresshelper (click on it to add it to your addressbook):
I. Going from @irc2p to @clientHASH.b32.i2p[Bearbeiten]
So what's going to change ?
The new network will bring "real" user hostnames. While the old Irc2P net mangled all user connection hosts to the wellknown @irc2p suffix, clients will now have their client destination hash as userhost. This feature allows for more efficient handling of bans, akills and access lists for IRC operators and channel admins and is one of the crucial changes.
What does it mean for you?
- If you have more than one nick and use them over the same client tunnel, those extra nicks will of course have the same hostname to them. Nick correlation is now very easy. If this is not wanted you have to create extra irc client tunnels for your extra nicks and use them with your IRC clients
- Check that your IRC client tunnel does not run as a shared client. This helps against client destination correlation of your nick and other things you do with your shared client tunnel ( like surfing eepsites ).
- Keep in mind that router restarts mean new b32 hosts if you don't use a static tunnel.
- IRC channel operators will find banning abusive users easier.
So better have a look at your i2ptunnel.config before visiting the new irc2p. Ohh and did we mention that you are advised to add the new IRC server irc.dg.i2p to the server list in your IRC tunnel settings?
II. What about my registered nickname(s) and password(s)?[Bearbeiten]
Don't worry. Your nickname has been transferred to the database of the new services system. You should be able to login with the same password. If this does not work, ask an IRCOp for help.
There are a number of global nickserv settings applied to all accounts:
- All nicks now have enforcement active with a timeout of 60 seconds.
- If you fail to identify after 60 seconds you will no longer be killed. Instead your nick will be renamed to "IRC2PGuest$RANDOMNUMER".
- To change your enforcement setting you can do
- /msg nickserv set ENFORCE ON|OFF /msg nickserv set ENOFRCETIME TIME_IN_SECONDS
The IRC2P operators strongly recommend keeping ENFORCE to ON. This protects your identity. If you are being killed/nick changed frequently, please set your client to automatically identify to NickServ. Almost every client can do this.
- All new registered nicks have enforcement activated by default.
- All new registered nicks now need an email address during registration!
- No valid email address, just something that looks like a valid one. You just have to specify something. If you have a working @mail.i2p address you can use it here. If you lost your nick password a reset password can be sent to the mail address specified. The mail address you type here will not be checked or verified by any means.
Can I be authenticated just by my b32.i2p host?[Bearbeiten]
The services package we use allows some kind of pre-authentication. While you are NOT completely identified, enforcement will be stopped. This means, you'll stay online with your nick. But in order to enjoy your channel rights and other privileges you have to identify.
You can add your user@host combination to the nickserv access list. /msg nickserv access add firstname.lastname@example.org
As long as your host stays the same (no tunnel or router restart ) your nick will stay in this state of unenforcement.
This feature is only useful if you use a 'persistent key' in your I2PTunnel configuration for your IRC tunnel.
What if my old session is stuck. Does GHOST still work?[Bearbeiten]
Yes, the GHOST command does still exist and takes the same arguments
- Release an enforcer:
Sometimes the nickserv will block a nick rename. Most of the times this happens when you want to rename from an IRC2PGuest* nickname to your registered nick. If nickserv denies you a change to your own nickname do a /msg nickserv release yournick password Now you can change your nick back and use it.
- Ask for a nick's status:
In the old network, users and bots alike could query the nickserv about the login status of other nicks like: /msg nickserv status nick Nickserv would then return a line like this:
-nickserv( email@example.com )- STATUS nick 0|1|3 Where 0 is offline, 1 is nick online but not registered and 3 means nick online AND registered. In the new network this function is still there but has another name and different result handling. Check the lines below to learn about the differences: /msg nickserv ACC nick
-NickServ(NickServ@services.irc.postman.i2p)- nick ACC 0 (not online) -NickServ(NickServ@services.irc.postman.i2p)- nick ACC 0 (not registered) -NickServ(NickServ@services.irc.postman.i2p)- nick ACC 3 Note: the stuff in braces is part of the output!! If you operate a bot or a script that checks for user status, you have to change your logic of your script/bot.
III. I had some channels on old irc2p. What about them ?[Bearbeiten]
Good news first: All channels will be transferred to the new network. But there are a number of changes in different parts of channelland. So better have a complete reading through it:
- No more channel/founder passwords. They are gone and will not return. All business you do with a channel is based on your registered nickname and your role assigned in the access list of that channel.
- Access lists and AKICK lists The old level based system for access rights has been replaced by a 'role' based access system.
The new network knows a couple of standard roles that represent:
- FOUNDER: complete admin that can do ALL things with the channel, including its deregistration and full recovery operation in case of a hostile overtake. He can edit the roles and assign all kinds of roles to users. There can be up to 4 users with a founder role in a channel
- SOP: Superop. can do nearly do the same, but cannot edit role definitions and cannot make himself founder.
- AOP AutoOP. This is your usual channel OP. He can op/deop ban, set topics, but cannot edit the Access lists and role definitions of the channel.
- HOP Half OP.
- VOP Voiced regular.
We had a very hard time trying to find a useful mapping between the old and the new databases with regards to the access list. We haven't been able to get really ALL the information and had to settle with a solution that is only quite ok and not brillant.
Since we have not been able to distinguish a Level 100 admin from a channel founder in the old database, we mapped every Level 100 user to the founder role of that channel. The new service packgage allows up to 4 founders.
Every Level 50 user was mapped to the AOP role. Every Level 30 user was mapped to the VOP role. Everything else HAS BEEN IGNORED.
If you are founder/Level100 user of a channel, please check your new access list on chanserv with the command.
/msg chanserv access #channel list
If you need a dedicated special role founders can edit/add roles with the 'role' command in chanserv.
/msg chanserv role #channel help
We hope this will work for 96% of all cases. If you got problems handling the roles, ask an IRCOp for assistance.
We have decided to skip all existing AKICK antries in the chanserv database. Given the fact that we have now have b32 hostnames and a new services package you'll certainly want to create new ones if needed.
What about modes and MLOCK ?[Bearbeiten]
All modes have been reset to a standard of +nt. This is mainly due to the fact that usable export and import of this data was not successful. you can change this if you're a founder / SOP by using
/msg chanserv set mlock #channel +modes
What about channel topics?[Bearbeiten]
Topics will not be transferred to the new network. You have to set a new topic.
IV. A few words about memoserv[Bearbeiten]
Your memos have been transferred to the new services database. You can use memoserv with the same set of commands you're used to.
V. Final notes[Bearbeiten]
We've been working pretty hard to make this transition happen. Yet we're sure there will be the usual bugs, problems and annoyances that always happen when bigger changes are made. Please report any problems with the new network or issues with this guide and we'll try to sort things out. Contact the IRCop team directly by IRC either in #irc2p or private messaging an IRCop. If this does not work, we're all reachable by mail.
Thanks for your patience