Our development team's valiant development efforts present to you: W!
Now, you may be wondering "Why change services? Didn't you just say you were working on a new fork from srvx?" and the answer is... sort of long.
As mentioned in a few blog posts, which are over a year old by now, we had been working on a srvx fork. Now, that's all fine and dandy, but somewhere down the road, we realized that the codebase is just unmaintainable. we have no modularity, "modules" follow a strange approach in the sense that they are only compile time options. Furthermore, srvx comes with many historical decisions that simply make no sense today: Why does O have a default level of 100 for cmode +o override, but 300 for cmode +v override? Why do we still have no NoSQL support for going full web-scale?
It all began with a little comment from me, culex: "Can't we change uset to something less idiotic?" After multiple rounds of talking to the higher-ups, I managed to get permission to rewrite services from scratch to make them more consistent, user-friendly and maintainable.
If you remember how painful it was to find commands amongst the entire selection of services then you know how I felt: Spending minutes digging in the help files, then going source digging, only to be told that srvx uses non-standard terminology or separates C uset from N set where it makes the least sense. Thus I took it upon myself to write verbose help files to aid newcomers.
In case you didn't notice, near the end of May 2014, we switched our IRCd to ircd-darenet2. This was necessary to make W work reliably, as it uses fairly complex server-to-server communication mechanisms to save bandwidth that required shifting a lot of code around and introduced incompatible changes that simply couldn't be emulated.
Unfortunately, this has the side-effect that support for multiple languages has been lost, but we are actively working on it. Translators are welcome to contact me on IRC.
W is state-of-the-art software, the likes of which haven't been seen in a long time. Highly configurable flood protection, wildcard-based access list searching, verbose logging of oper overrides, a NoSQL database customized for speed, a modern web panel to control your channel from, blazingly fast lookups and properly packed structs, efficient commands, useful help files, scrypt password hashing, sane default behavior and familiar 500-level design will make your experience on DareNET faster, safer and easier than ever before. For reasons of simplicity, for example, we have abandoned the old and dusty account system in favor of a channel-based account system, which also gives more safety in allowing you to lock down every account with a separate password.
Unfortunately, cue bad timing, the services databases have been deleted due to hardware failure, right as we were writing a database converter. That means that all channel and user data has been completely lost. Users wishing to re-register channel must have ops to use /msg W REGISTER #channel. Please take your time to study the help files, usage should feel familiar to most users who have been active on IRC since around 1997 or so. Should you have any questions, please do not hesitate to contact #help. A web panel can be found at http://cservice.darenet.org/.
Please keep in mind that, while W has been extensively tested by our staff before deployment, there is always a chance of bugs and unforeseen issues; do not hesitate to contact us if you are unsure whether certain behavior is to be interpreted as a bug or a feature.
Our current network setup allows other users to see your IP address when you join channels. While this is standard practice for IRC, we feel it doesn't fully reflect our commitment to privacy. We believe it's important such information be hidden, and that's why we'll soon be enabling host hiding for all users.
Keep on on eye on this space for updates.
In the meantime, we'll answer some of the most frequently asked questions.
What will the hidden host look like?
For non-authenticated users, the hidden host will be in the form of <uniqueid>.guest.darenet.
Joins: JohnDoe (firstname.lastname@example.org)
Authenticated users will continue to receive their custom group host or title.
Will I need to apply umode +x to take advantage of the new feature?
No, the "guest hidden host" will automatically be applied when you connect to the network.
I have a custom title on my account, will I still be able to use it?
Yes! Authenticated users will continue to receive their custom group hosts and titles.
What if I don't like the new feature? Will I be able to disable it?
Yes, but you will need to disable autohide for your account and use login-on-connect.
Over the course of the next week we'll be rolling out a new release of our ircd to each server, which will lay the foundation for some new features we currently have in the works. Each server should only be down for a moment once restarted. We'll send out announcements on IRC once we get closer to performing the restarts.
Thank you for your patience!
Edit1: Updates have started. We'll continue to update and restart servers as their loads drop. To avoid interruption, use irc.darenet.org to ensure you end up on a server that has been updated.
Edit2: All servers have now been updated to the new release!
We just recently updated our network services (evo) to version 1.2.0, which contains some small changes and fixes. Here are the highlights:
Server-side mode locks are now fully supported by C. This means that the server will prevent channel operators from setting modes that would violate the channel's SET MODES setting. Users with access in the channel greater or equal to what is set for the SET ENFMODES setting may still use C's MODE command to change modes freely.
If you want to prevent any mode changes, from anyone, that would violate the channel's SET MODES setting, change SET ENFMODES to 501.
In the past, you had to be using a host that matched an entry on your account's mask list to authenticate to it, or use the AUTHCOOKIE command. A lot of users found this confusing and/or annoying; therefore, we have removed this requirement.
Users who did like this extra bit of security may re-enable it by using N's SET TRUSTED option. See /msg N HELP SET TRUSTED for more information.
While we've offered CertFP authentication for quite sometime, we figured we'd talk about it some again, since most users don't even know it exists.
CertFP allows users connected via SSL with a client certificate to authenticate to N using the SHA1 fingerprint of their client certificate. You may be asking yourself what that gets you. Well, you can get rid of any auth scripts or auto-perform commands you've been using. Since you're authenticated with your certificate fingerprint you don't need them anymore. That also means no longer having to store your password in them! And by using SSL, your connection to the IRC server is encrypted.
For more information on setting up CertFP for your account and using it with login-on-connect, check out our CertFP Authentication guide.
As always, if you have questions or need asisstance, stop by #help.