Skip to content

Releases: Jigsy1/mIRCd

mIRCd[0.10(Rev.2)][2021-2023]

31 Aug 02:18
d09f2f6
Compare
Choose a tag to compare
1. Added /BLOCK which works like /ACCEPT and /SILENCE. Unlike /ACCEPT, this doesn't require any specific user modes
   being set before using it. You just /BLOCK the nick or n!u@h from being able to message you.
   And unlike /SILENCE, you will still see their channel message(s).

sha256 checksums included in zip.

*.zip sha512: 56a75d7b21e917d3f1038271547c8a0165a9a52b2bbdfe4b0ed3c3e42453c9e1b19bab8814d3187e55da882a4f673227960fdb29891541581d950591603457be

mIRCd[0.09hf17(Rev.2)][2021-2023]

25 Aug 07:51
d0063dc
Compare
Choose a tag to compare
1. Discovered /SETHOST has an UNDO command, so added that in.
2. Fixed a bug with /SETHOST and /mode <you> +h where you could continually set your host with the same host.
   Now it'll check to see if the host is different. (Allowing for changes in capitalization of course.)
3. NOTICE, PRIVMSG, WALLCHOPS, WALLHOPS, WALLOPS, WALLUSERS and WALLVOICES now conform to "Input line too long."
4. GLINE, KILL, ZLINE, etc. now truncate the removal message to conform with the maximum length of QUIT messages.
5. SHUN also truncates the reason to the maximum length of a TOPIC.
6. DNS/Ident now tells the connecting user if it failed to obtain that information.
7. INFO now returns "INFO is missing" if the INFO file is missing. (My own non-standard numeric reply.)
8. Fixed a bunch of mIRCd.raws messages.
9. Other cosmetic/minor change(s).

sha256 checksums included in zip.

*.zip sha512: 113597f78e717be357b095998e9a6a87587629f6f73a0b5f992892417ebb85d9874ff93915e0b24a96b32078c22eeb06db3033aef129d7ea86bb63b09b41a73c

mIRCd[0.09hf16(Rev.2)][2021-2023]

11 Aug 23:52
d5b8bf3
Compare
Choose a tag to compare
I would like to point out that I have started work on Rev.3, but totally underestimated just how difficult it would be.

At most - for test purposes - I've managed to get a Python C:line jupe server to connect to me, and then another server
to me/me to another server (yes, both ways work) so they both acknowledge they and the users exist. (Screenshot on page.)

Don't expect it to be completed any time in the next year (or two), but I am determined to do this.

Anyway, there were bugs...

1. Sort of changed the way that invite works due to the fact that an invite would be outstanding if the channel was destroyed,
   meaning that a user could join the channel when they weren't supposed to (new ownership).

   It's roughly the same, but there's now a separate list for a channel. When the channel is destroyed, it cycles through the
   list and expunges it from the socket hash table.
2. Fixed a few bugs with /INVITE. A numeric reply if the channel doesn't exist (duh!), used mIRCd.raw instead of mIRCd.sraw for one reply, and
   +X users can now invite a user to a channel if the channel doesn't exist by forcing it through. (This doesn't appear in the /INVITE list though.)
3. Fixed a bug in /NAMES where the reply wouldn't show up if the channel didn't exist.

sha256 checksums included in zip.

*.zip sha512: 836079471c03606a302d947316365041bfc730a01d5f90e68e2724d71171b64bee4a7c0f99bbf1d3d54175b01c8f8740ce17642033fc824ffdec26e3f35b2bc5

mIRCd[0.09hf15(Rev.2)][2021-2023]

31 Jul 23:07
8621562
Compare
Choose a tag to compare
1. You can now specify DEFAULT_OPERMODES in mIRCd.ini to be set by a user whenever they succesfully /OPER by adding
   DEFAULT_OPERMODES=modestring to [Mechanics] in mIRCd.ini. (Defaults to hardcoded +gsw.)
2. Although this is not a bug (but was changed by UnderNet), you can now hide the /SILENCE list from other users (excluding IRC operators)
   by adding HIDE_SILENCE_LIST=TRUE or HIDE_SILENCE_LIST=FALSE to [Mechanics] in mIRCd.ini. (Defaults to FALSE.)
3. The same applies to /ACCEPT list, but by adding HIDE_ACCEPT_LIST=TRUE or HIDE_ACCEPT_LIST=FALSE to [Mechanics] in mIRCd.ini. (Defaults to FALSE.)

   If you wish to hide both of them at the same time, you can simply abridge this to HIDE_CLIENT_LISTS=TRUE or HIDE_CLIENT_LISTS=FALSE
   to [Mechanics] in mIRCd.ini. (Defaults to FALSE).
4. WALLCHOPS, WALLHOPS and WALLVOICES now count towards time last active. (Assuming a message was successfully sent.)
5. You can now specify if you want those on localhost/LAN to have immunity from restrictions upon connection (see order in notes for hf14)
   by adding LOCAL_IMMUNITY=TRUE or LOCAL_IMMUNITY=FALSE to [Mechanics] in mIRCd.ini. (Defaults to FALSE.)
6. Fixed a bug *with* local immunity. (Used the wrong boolean operator.)
7. localhost (127.0.0.1) isn't subjected to DENY_EXTERNAL_CONNECTIONS=TRUE if LOCAL_IMMUNITY=FALSE, but LAN will be since you
   might be wanting to restrict LAN users from connecting.
8. Other cosmetic/minor change(s).

☆edit☆

Quick fix to something in mIRCd_connHandle.mrc.

sha256 checksums included in zip.

*.zip sha512: 9854115a1adf1d4c6c92fa7ff6fac3548d8cd080260a2f8db577613293ede8904d1458ea494e3dd3d476dce707fbfa1e53a06043c99e3e86e8f3f715c4bfe972

mIRCd[0.09hf14(Rev.2)][2021-2023]

29 Jul 23:13
d8800c7
Compare
Choose a tag to compare
1. Can now allow opers to join (G|K)-lined channels by adding OPER_BYPASS_BADCHAN=TRUE or OPER_BYPASS_BADCHAN=FALSE to
   [Features] in mIRCd.ini. Defaults to FALSE.
   This also extends to /SVSJOIN.
2. mIRCd_confCheck.mrc now checks to see if PING_TIMEOUT_DURATION is at least five seconds higher than PING_DURATION.
3. /WHO now conforms to the amount of replies it should send if include fields are specified. (Which is still a lot even for this IRCd.)
   (2048 / (NUMBER_OF_INCLUDE_FIELDS + 4))
4. You can now limit the amount of users from the same ip address by adding MAXCLONES=<number> to [Mechanics] in mIRCd.ini.
   LAN and localhost user(s) are not subject to this restriction.
   The order is: [NETWORK BANS] -> *local immunity* -> [PASS] -> [NO EXTERNAL CONNECTIONS] -> [MAXCLONES] -> [MAXUSERS]
5. Added pretty rudimentary "Excess flood" support. This can be enabled by adding EXCESS_FLOOD=TRUE or EXCESS_FLOOD=FALSE to
   [Mechanics] in mIRCd.ini.
6. Can specify the FLOOD_LIMIT=<bytes> for use with EXCESS_FLOOD under [Mechanics] in mIRCd.ini. (Needs to be >=1024 bytes.)
   Currently 8192, which should be more than adequate.
7. Fixed a visual bug in /mIRCd.modeTell which involved +k containing ¦. E.g. +k test¦key where the line showing the new modes
   would truncate the key (just the key) to +k test. (The key itself would still be test¦key.)
   Solved by replacing ¦ with a , since keys aren't allowed/supposed to contain commas due to /JOIN.
8. Other cosmetic/minor change(s).

sha256 checksums included in zip.

*.zip sha512: e4d255d2055834fc25d415c489e2e8e48d562b84b10be9f89d9876898ca15c7ea970a62473cef1221fcf0e69ed6211ecf9eb15d3e78a0e1d0d4c1570987fcbfe

mIRCd[0.09hf13(Rev.2)][2021-2023]

28 Jul 03:46
8e89703
Compare
Choose a tag to compare
1.  Fixed an (accidentally discovered) issue where the IRCd would respond to Telnet clients constantly with "Register first"
    or "Unknown command" due to the fact that Telnet sends blank/empty lines to the IRCd when you're inputting commands.
2.  As usermode +h (SETHOST) is a hidden mode, it should not have been visible in the usermodes sent in raw 004 or raw 005
    USERMODES=... reply.
3.  AUTOJOIN_CHANS creation now ignores channels which are K-lined or G-lined. (Though nobody could join them anyway.)
4.  /OPER now informs the user what their default snoMask is if they set +s prior to being an oper.
    This isn't a bug, but it was annoying the hell out of me due to the fact I wasn't seeing HACK(*) notices and forgetting why.
5.  I discovered on bircd (another ircu IRCd) that there doesn't seem to be a limit on the NETWORK_NAME length?
    So I've imposed a restriction of 200 characters. (Which should be adequate enough.)

    If there is a limit (which is probably 512 characters?), let me know by making an issue.
6.  NETWORK_NAME now conforms to naming rules, which the nearest I can gather after testing is the same as ident rules.
7.  NETWORK_INFO is now truncated to the same length as a "real name" as it should have been. (50 characters.)
8.  Fixed a bug in /SVSJOIN where trying to join channels that didn't exist wouldn't work.
    This was actually being caused by $is_on. Now if the first argument of $is_on(<id>,...) is $null, it'll default to $false.

    It was either this or ternary if every single instance of $getChanID(), so this might have unforseen consequences...
9.  Fixed a bug where you could join a K-lined/G-lined channel assuming it still existed because I was operating on the assumption
    that the channel wouldn't exist after banning it. E.g. /MODE #chan +P -> /GLINE #chan -> /JOIN #chan -> "Now talking in..."

    The channel will still remain if +P is set, you just can't join it anymore.
10. The same applies to /SVSJOIN as well. You could /SVSJOIN users into banned channels assuming they still existed because of +P.
11. Changed it so /JOIN #chan1,#chan2,... key1,key2,... now requires the exact key and number of keys for each specific channel
    instead of the half-assed hack I did.
    My mentality for this change 2y later is because if #chan1 had the same key as #chan2, a user would be able to join both
    channels even though they're probably not supposed to join #chan2.
    Though the chances of a channel having the exact same key are pretty small...
12. Other cosmetic/minor change(s).

sha256 checksums included in zip.

*.zip sha512: 1543e671c2e0ec0c51b079fc39fe2ae6583e9c75628f7805fa1b6897c3f63d6a7a5bb00edfb26501d8e7c160e5c90d00a7071f54f70f5bf7dfc1c2462d901b6e

mIRCd[0.09hf12(Rev.2)][2021-2023]

22 Jul 20:10
17b69e3
Compare
Choose a tag to compare
1. /SVSPART now issues a generic part message to indicate that a user has been forcefully removed.
2. Opers are no longer subjected to WHO_THROTTLE.
3. Opers are no longer subjected to CONNECTED_LIST_THROTTLE.
4. Can now /LIST based on last activity (in minutes) in a channel. E.g. /LIST M>5

   As I don't know what classifies as activity, I've covered (for now): CLEARMODE, (SVS)JOIN, KICK, KNOCK, (OP)MODE, NOTICE, (SVS)PART, PRIVMSG and TOPIC

   NICK and QUIT are not specific to channels and thus not included.
5. Other minor changes.

☆edit☆

Correcting three help files, something I forgot in the changelog and added FLAGS.help.

sha256 checksums included in zip.

*.zip sha512: 25f81c973486570aebd2fb053933dad09e2e3a419b409de2a221f57a68129b4defe95cc2df581c199ed97c48b84bf29acd9b190d95bf1ac67a682a91086699a7

mIRCd[0.09hf11(Rev.2)][2021-2023]

18 Jul 23:06
934e718
Compare
Choose a tag to compare

Can you believe it? It's already been two years.

1. /STATS m now counts the data length received.
2. Fixed a bug with +g where users could bypass the gag if they weren't on the channel and +n wasn't set.
3. Fixed a bug where OPLESS_CHANS=1 would still op opers even though it wasn't supposed to.
4. Can now prevent users from having ops in persistant channels if they join and there are no other users by adding
   NOOP_PERSIST=1 or NOOP_PERSIST=2 to [Mechanics] in mIRCd.ini. Meaning: 0 = Disabled, 1 = Everybody, 2 = Non-opers.

   This can work in conjunction with OPLESS_CHANS.
5. Fixed a bug in /WHO where a user wouldn't appear if they themselves are +i under certain conditions.
6. Given the recent SUPERBOWL related spam and based on a discussion with an oper on another ircu based IRC network (Nefarious),
   we were quite surprised to learn that there isn't a way to use /WHO to return users who've been connected to the IRCd
   for a certain duration of time, so I decided to add this in just for test purposes.

   Since /WHO is a powerful tool, and it would be useful to deal with annoying spambots, hopefully it'll become part of WHOX
   "standard" one day.

   Using the j (joined) flag, you can return users - via !=, <, <=, =, >=, > - who've been connected for N seconds. E.g.

   /WHO >3600 j
   /WHO * j%n :<=60

   I've indicated this code with: *** OWN IDEA *** ... *** END ***
7. I've decided to classify this as a bug. If a channel is +H, the modes don't appear in /LIST... however, someone could
   still get the modes by doing /MODE #chan. So now the modes aren't returned if the user isn't on the channel and does
   /MODE #chan. (Excluding opers.)
8. /LIST now works the way it should on other IRCds. (E.g. /LIST >0,C<5,T>0,!*exclude*, etc.)

sha256 checksums included in zip.

*.zip sha512: d7da2e61fa8879e9ed3be6a19456dbd0fd59f476898a6b143713068259a3f9e8f71466ba81c30a06f224b318e3efdd417c69d0c2acca605932d29eb8c78dafd0

mIRCd[0.09hf10(Rev.2)][2021-2023]

26 May 16:06
7742194
Compare
Choose a tag to compare
1. Forgot a /return in $mIRCd.makeDefaultModes in mIRCd_modeHandle.mrc.
2. Commands in /STATS m will not be displayed if the times used is zero. (Like ircu IRCds.)

sha256 checksums included in zip.

*.zip sha512: 3830f4f0af111c5b7ed476785526de2daf968a5849a0be100580a32dbe56d7f282ab95eacc737a465b49aa2aae8a9531c16aaf05ce03b42a1d7b30f6c366d6f5

mIRCd[0.09hf9(Rev.2)][2021-2023]

14 Feb 02:06
eb5b963
Compare
Choose a tag to compare
1.  Sending a /MSG or /NOTICE to nick@server should now work the way it should on an actual IRCd.
2.  Fixed a bug where /CTCP wasn't being blocked by +C, and /action would have been blocked by +C if the former had actually worked.
3.  As I felt this was a bug, ops and hops can no longer bypass channel mode +C (no /CTCP) or +T (no /amsg, etc.).
    The order is now: [OPER +X PASS] -> +n -> +T -> +C -> [OP/HOP PASS] -> +N -> [VOICE PASS] -> +b -> +m -> +g -> +c -> +S
4.  Possible bug. Usermode +X now bypasses +d(eaf) users, being silenced, stripping colors via PM, and chan mode +B.
5.  Fixed a bug with /CLOSE.
6.  Unloading mIRCd should now correctly deal with terminating the IRCd and cleanup operations.
7.  Fixed a reply bug in /INVITE.
8.  Fixed a bug in /NAMES.
9.  NAMESX and UHNAMES are now set for the user upon connection.
10. Joining the channel automatically upon connection is now done after modes being parsed due to a bug involving +x, not
    to mention now has a slightly longer delay.
11. A few other fixes and some optimization.

sha256 checksums included in zip.

*.zip sha512: 848214a231119ad9f411a270738c006713429e20eaf79de3f32f4c96e29871c21d1f9bc9ac80ffa1bf815e028fc4dd8d6b265c89d22fc382964ef424e25d552e