IRCv2 Chat Log
Posted by Anonymous on Tue 26th Apr 2011 14:24
raw | new post

[02:44] <+Polynomial> heh, actually when I think about it an IRCd is probably more simple than an IRC client
[02:44] <@T3ch> oh i see how it is. im so uncool no one notices
[02:44] <+Polynomial> all you have to do is keep track of who is on what channel
[02:44] <@bluechill> Polynomial, which is what I do
[02:44] <+Polynomial> everything else is services
[02:44] <@bluechill> :P
[02:45] <@bluechill> I'm thinking about reimplementing plugin support
[02:45] <@bluechill> not sure if thats such a good idea
[02:45] <+Polynomial> I'd really like to see IRCv2
[02:45] <@bluechill> IRCv2?
[02:45] <+Polynomial> modern reimplementation of the IRC standard
[02:45] <+Polynomial> as a new RFC
[02:45] <@bluechill> where link?
[02:46] <+Polynomial> it doesn't exist
[02:46] <+Polynomial> a lot of people have discussed it though
[02:46] <@bluechill> ah
[02:46] <+Polynomial> IRC is designed based on the days of dialup and direct connections (no NAT)
[02:46] <@bluechill> so? whats the difference with IRC v2?
[02:46] <@bluechill> it gets around NAT?
[02:46] <@bluechill> and allows servers through firewalls?
[02:47] <+Polynomial> not really
[02:47] <@bluechill> er routers
[02:47] <@bluechill> :P
[02:47] <@bluechill> then whats the difference?
[02:47] <+Polynomial> better designed server-to-server communications
[02:47] <+Polynomial> more capabilities related to user interaction
[02:47] <+Polynomial> integrated and standardized services
[02:47] <+Polynomial> improved channel control
[02:47] <@bluechill> how hard would that be to implement?
[02:47] <+Polynomial> not very
[02:47] <@bluechill> hmmm
[02:47] <@bluechill> I might do that then
[02:48] <@bluechill> lol
[02:48] <@bluechill> just for a fun weekend project
[02:48] <+Polynomial> you'd need a custom client though
[02:48] <@bluechill> yeah
[02:48] <@bluechill> I know
[02:48] <@bluechill> I could just use telnet though
[02:48] <+Polynomial> true
[02:48] <+Polynomial> you could even include PGP in the protocol
[02:49] <@bluechill> that would be nice
[02:49] <+Polynomial> as a message authentication protocol
[02:49] <@bluechill> interesting
[02:49] <@bluechill> I mean, encryption could also be the defacto standard for privmsg too
[02:49] <+Polynomial> just use SSL
[02:49] <@bluechill> eh
[02:49] <@bluechill> SSL + blowfish
[02:49] <@bluechill> or something like that
[02:49] <+Polynomial> erm
[02:50] <+Polynomial> SSL covers both crypto and authentication
[02:50] <@bluechill> lol
[02:50] <@bluechill> so?
[02:50] <+Polynomial> so why blowfish if SSL includes AES?
[02:50] <@bluechill> blowfish is one more layer
[02:50] <+Polynomial> it's just extra bloat for no reason
[02:50] <+Polynomial> with SSL you've already got a fully standardized and tested protocol
[02:51] <@bluechill> yeah
[02:51] * CrashOverron (Crash@hide-1C4A3969.cfl.res.rr.com) has joined #securityoverride
[02:51] * ChanServ sets mode: +ao CrashOverron CrashOverron
[02:51] <+Polynomial> plus you can treat the server as a CA
[02:51] <@BBot> Welcome CrashOverron
[02:51] * BBot sets mode: +v CrashOverron
[02:51] <@bluechill> yeah
[02:51] <&CrashOverron> yup
[02:51] <@bluechill> Hello CrashOverron
[02:51] <&CrashOverron> Hello bluechill
[02:51] <@T3ch> hey CrashOverron
[02:51] <+Polynomial> so all privmsg would be secure
[02:51] <@bluechill> yeah
[02:51] <+Polynomial> you could also have a channel mode for that
[02:51] <+Polynomial> like +S
[02:51] <@bluechill> mmm
[02:51] <@bluechill> mhmmm
[02:52] <+Polynomial> forces all messages that go in and out of the channel to be sent over SSL
[02:52] <@bluechill> although that could cause problems but thats why it would be irc v2
[02:52] <@bluechill> all clients have to support SSL
[02:52] <+Polynomial> exactly
[02:52] <@bluechill> and by default the server's cert is trusted
[02:52] <@bluechill> that may be a bad thing though :P
[02:52] <@bluechill> although just for that IRC connection wouldn't be so bad
[02:53] <+Polynomial> you could make it configurable
[02:53] <+Polynomial> either make it trusted by default
[02:53] <@bluechill> true
[02:53] <+Polynomial> or make it use a CA
[02:53] <@bluechill> true
[02:53] <+Polynomial> so you could sign the server cert with VeriSign or whatever
[02:53] <@bluechill> That would be nice
[02:53] <@bluechill> although, induvidual channel signing would be interesting
[02:53] <@bluechill> wonder if that would be possible to create
[02:53] <+Polynomial> yeah
[02:54] <+Polynomial> hmm
[02:54] <@bluechill> I mean, depending on how you implemented the server
[02:54] <+Polynomial> you could base64 encode the cert
[02:54] <@bluechill> in theory I would think yes
[02:54] <+Polynomial> and have a command to upload it
[02:54] <@bluechill> that might work
[02:54] <+Polynomial> or just have the client do it
[02:55] <+Polynomial> I'd probably use bencode or something for the protocol
[02:55] <+Polynomial> since it's lightweight
[02:55] <@bluechill> true
[02:55] <@bluechill> as for server to server communication
[02:55] <+Polynomial> and supports multiple datatypes
[02:55] <+Polynomial> for server to server you'd have to force external CA
[02:55] <@bluechill> yeah however
[02:55] <+Polynomial> actually
[02:55] <+Polynomial> do one better
[02:56] <@bluechill> I think server to server communication could just be treated as special client communication
[02:56] <@bluechill> with pgp key
[02:56] <+Polynomial> exchange each other's certificates explicitly
[02:56] <+Polynomial> external to the protocol
[02:56] <+Polynomial> i.e. send each other it via email, or physical copy
[02:56] <@T3ch> bbiab
[02:56] <+Polynomial> both servers need each others certs installed
[02:56] <@bluechill> why not just pgp sign a connection then send it?
[02:57] <+Polynomial> because it needs to be authenticated and encrypted
[02:57] <+Polynomial> all channel messages get duplicated across servers
[02:57] <@bluechill> yeah :P
[02:57] <+Polynomial> server to server needs to be 100% authenticated and encrypted
[02:57] * @T3ch (T3ch@The.65536th.Port) Quit (Quit: bbl)
[02:57] <+Polynomial> hence absolute trust
[02:57] <@bluechill> yeah
[02:58] <@bluechill> hmmm
[02:58] <+Polynomial> physical copy or email copy certificates, pre-installed
[02:58] <@bluechill> like you said, why not make it explicit.  So I mean, you have to locally add the cert to connect the servers
[02:58] <@bluechill> that would deal with connection security
[02:58] <+Polynomial> exactly, but only for server-server
[02:58] <+Polynomial> not client-server
[02:59] <+Polynomial> because for client-server that'd be way too much hassle
[02:59] <@bluechill> yeah
[02:59] <+Polynomial> it needs to be easy
[02:59] <@bluechill> server to server should be 100% secure though
[02:59] <+Polynomial> yup
[02:59] <@bluechill> or at least 99.999999
[02:59] <+Polynomial> it needs both certificate verification and password verification
[02:59] <+Polynomial> something you have, something you know
[02:59] <+Polynomial> two factor verification :)
[02:59] <@bluechill> why not IP verification?
[02:59] <@bluechill> as well
[02:59] <+Polynomial> that too
[02:59] <+Polynomial> 3 factor
[02:59] <+Polynomial> but it can be spoofed
[03:00] <@bluechill> all 3 not easily
[03:00] <+Polynomial> exactly
[03:00] <@bluechill> if one fails the connection is dropped
[03:00] <+Polynomial> cert can't be spoofed without rooting one box or snooping the email
[03:00] <@bluechill> even if other are valid
[03:00] <+Polynomial> password can't be cracked easily
[03:00] <+Polynomial> easy to fail2ban bruteforce
[03:00] <@bluechill> and I mean, I think the password should have some minimum character and length requirements
[03:00] <+Polynomial> yeah
[03:00] <+Polynomial> minimum entropy
[03:00] <@bluechill> like 512 min length.
[03:00] <+Polynomial> nah
[03:01] <@bluechill> ":P
[03:01] <@bluechill> why entropy?
[03:01] <@bluechill> thats thermodynamics :P
[03:01] <+Polynomial> because entropy is a direct measure of password complexity
[03:01] <@bluechill> this is software
[03:01] <+Polynomial> shannon entropy
[03:01] <@bluechill> eh
[03:01] <@bluechill> oh
[03:02] <@bluechill> yeah that sounds good
[03:02] <@bluechill> I'll be right back.  Think of some more ideas.  This intrigues me.  IRC v2 would be rather interesting to implement
[03:03] <@bluechill> 100% secure, easy to use
[03:03] <@bluechill> etc.
[03:03] <@bluechill> modern too
[03:03] <+Polynomial> something like 2.5x10^12 minimum keyspace
[03:03] <+Polynomial> 8 characters a-z 0-9 will cover that
[03:04] <+Polynomial> I think more user information would be nice
[03:04] <+Polynomial> like easily accessible stats
[03:05] <+Polynomial> and info about when the user last spoke
[03:05] <+Polynomial> maybe a small profile (name, website, email, etc)
[03:06] <+Polynomial> one thing it'd need is full IPv6 compatibility
[03:07] <+Polynomial> and configurable host masking (like how we have hide-11223344.server1.host.net)
[03:09] <+Polynomial> except in this case probably make it a lot more configurable
[03:09] <+Polynomial> better inbuilt ban management
[03:09] <+Polynomial> like the ability to auto-remove after a while
[03:10] <+Polynomial> also have registered channels cache their modes and configuration, unlike current IRC
[03:11] <+Polynomial> there also needs to be a way to make a channel that can only be joined by a user list
[03:12] <+Polynomial> like +b *!*@*, +e Polynomial!*@*
[03:12] <+Polynomial> but configured in a better way
[03:18] <@bluechill> yeah
[03:18] <@bluechill> I mean, I think the mode system should be overhauled to a certain extent
[03:18] <+Polynomial> yeah
[03:18] <+Polynomial> I think the single character mode system is fine
[03:18] <+Polynomial> it just needs overhauling with nicer formats
[03:19] <+Polynomial> and a whole set of properly defined modes
[03:19] <@bluechill> thats what I meant
[03:19] <+Polynomial> possibly more mode options too
[03:19] <+Polynomial> like private/secret are basically the same mode
[03:19] <+Polynomial> the only difference is that one of them doesn't appear in the user channel list
[03:19] <@bluechill> although channel modes should be easily distinguishable from user modes.
[03:20] <@bluechill> and then there is the thing like
[03:20] <@bluechill> /mode #channel +ooo BBot bluechill Polynomial
[03:20] <@BBot> Hello, bluechill
[03:20] <@bluechill> you should only have to do //mode #channel +o BBot bluechill Polynomial
[03:20] <@BBot> Hello, bluechill
[03:20] <@bluechill> and other stuff like
[03:21] <@bluechill> /mode #channel +ov bluechill
[03:21] <@bluechill> instead of /mode #channel +ov bluechill bluechill
[03:21] <@bluechill> make management a little easier
[03:22] <+Polynomial> hmm
[03:22] <+Polynomial> yeah
[03:22] <+Polynomial> if there's one user, apply all modes to that user
[03:22] <@bluechill> yeah
[03:22] <+Polynomial> if there's multiple users, require one user per mode
[03:23] <+Polynomial> (like current)
[03:23] <@bluechill> eh
[03:23] <@bluechill> :P
[03:23] <@bluechill> if it is all the same then no
[03:23] <@bluechill> like +ooo
[03:23] <@bluechill> only have to have +o
[03:23] <@bluechill> however
[03:23] <@bluechill> +ovv would be different
[03:23] <@bluechill> make it a little simplier
[03:23] <+Polynomial> yeah that too
[03:24] <@bluechill> also, the symbles for denoting modes I think should be made clearer somehow :P
[03:24] <+Polynomial> one mode, one user = set that mode on that user
[03:24] <@bluechill> &, @, +, not clear :P
[03:24] <@bluechill> etc.
[03:24] <+Polynomial> one mode, multiple users = set that mode on those users
[03:24] <@bluechill> yeah
[03:24] <+Polynomial> multiple modes, one user = set those modes on that user
[03:24] <@bluechill> I mean I think it should be more like this
[03:24] <@bluechill> instead of @bluechill, bluechill +ov
[03:25] <+Polynomial> multiple modes, multiple users = set those modes to those users in that order, requiring the same number of modes and users
[03:25] <@bluechill> so the modes follow the user
[03:25] <+Polynomial> hmm
[03:25] <+Polynomial> I think the user prefix is fine
[03:25] <+Polynomial> and well known
[03:25] <@bluechill> well it's unclear :P
[03:25] <@bluechill> I mean,
[03:25] <+Polynomial> but I think we need better granularity
[03:26] <@bluechill> /mode #channel +o bluechill <-- clear bluechill has operator.  @bluechill <-- not so much.  bluechill +ov <-- clearer
[03:26] <+Polynomial> huh?
[03:26] <+Polynomial> that makes no sense
[03:26] <@bluechill> as in
[03:26] <@bluechill> currently I have +o
[03:26] <+Polynomial> the prefix is just to signify the usermode
[03:26] <@bluechill> so my name has a an @ in front of it
[03:26] <+Polynomial> yes
[03:26] <@bluechill> however
[03:27] * bluechill sets mode: -o bluechill
[03:27] <+bluechill> now it has a +
[03:27] * ChanServ sets mode: +o bluechill
[03:27] <+Polynomial> yes, because you have +v set under it
[03:27] <@bluechill> yeah
[03:27] <@bluechill> well
[03:27] <+Polynomial> I don't think that's an issue
[03:27] <+Polynomial> I think it should be detectable
[03:27] <@bluechill> I guess the current system is fine, because it shows the highest usermode
[03:27] <@bluechill> :P
[03:27] <+Polynomial> like if you select the nick and view info
[03:27] <@bluechill> yeah
[03:27] <+Polynomial> it should show all mdoes
[03:28] <+Polynomial> but I think we need clearer privilege levels
[03:28] <@bluechill> currently whois doesn't do that
[03:28] <@bluechill> :P
[03:28] <@bluechill> yeah
[03:28] <@bluechill> also, I think there should be a destintion for bots
[03:28] <+Polynomial> yeah, a bot prefix
[03:28] <@bluechill> there currently isn't one
[03:28] <+Polynomial> like $
[03:28] <+Polynomial> $bot
[03:28] <@bluechill> or something like that
[03:28] <+Polynomial> or ^
[03:28] <+Polynomial> ^ might be better, it looks kinda robotic
[03:28] <+Polynomial> and it's lightweight
[03:28] <@bluechill> lol
[03:28] <+Polynomial> ^botname
[03:28] <@bluechill> $ is in form with more usermodes though
[03:29] <+Polynomial> yes, but it looks kinda like an S
[03:29] <@bluechill> ^ is easy to miss whereas $ isn't
[03:29] <@bluechill> eh
[03:29] <@bluechill> ok
[03:29] <+Polynomial> so it might be awkward
[03:29] <@bluechill> howabout
[03:29] <@bluechill> #
[03:29] <@bluechill> oh wait
[03:29] <+Polynomial> channel is #
[03:29] <@bluechill> thats channel :P
[03:29] <+Polynomial> * maybe
[03:29] <@bluechill> * would be better
[03:29] <@bluechill> ^ is easy to miss
[03:29] <@bluechill> * not as much
[03:29] <+Polynomial> yeah
[03:30] <@bluechill> also, I think messages should be clearer
[03:30] <@bluechill> so the servers shouldn't play ping-pong with the clients
[03:30] <@bluechill> the clients should send a keep-alive message like in ftp
[03:31] <@bluechill> and if they don't send one every 5 minutes or something then the server has to drop them
[03:31] <+Polynomial> I think we should have fully granular channel control privileges for super-op level users
[03:31] <@bluechill> elaborate, what do you mean?
[03:31] <@bluechill> I have an idea
[03:31] <+Polynomial> so ~ is owner/admin, which is forced to have all privileges
[03:32] <@bluechill> but I want to know what your thinking for that
[03:32] <@bluechill> Ya
[03:32] <@bluechill> Ah
[03:32] <@bluechill> ok
[03:32] <+Polynomial> & is super-op, which is like an op but it has access to channel settings (like chanserv)
[03:32] <+Polynomial> but those settings are entirely granular
[03:32] <@bluechill> ok
[03:32] <+Polynomial> grantable and such by admin
[03:32] <+Polynomial> like how IPB does it
[03:33] * bluevoid (bluechill@88E18C6B.8F1F0E24.E33B6120.IP) has joined #securityoverride
[03:33] * ChanServ sets mode: +v bluevoid
[03:33] <+bluevoid> Eg :P
[03:33] * @bluechill (bluechill@bluechill.fbi.gov) Quit (NickServ (GHOST command used by bluevoid))
[03:33] * bluevoid is now known as bluechill
[03:33] <+Polynomial> lol
[03:33] <+Polynomial> wb
[03:33] <+bluechill> there
[03:33] <+bluechill> iPhone now
[03:33] <+bluechill> My Internet just died :P
[03:33] <+bluechill> Damn comcast
[03:34] <+Polynomial> like /grant #channel privilege_name user
[03:34] <+Polynomial> /revoke #channel privilege_name user
[03:34] * @BBot (BBot@hide-D8E8F540.hsd1.mi.comcast.net) Quit (Ping timeout)
[03:34] <+bluechill> Anyways, yeah I mean granularity sounds fine however there should be a certain minimum distinction between usermodes.  +a can't have less privs than +o for example
[03:35] <+bluechill> Like some minimum required permissions for usermodes
[03:35] <+Polynomial> of course
[03:35] <+bluechill> So not totally granular ;)
[03:35] <+Polynomial> basically & would mean +o with grantable permissions for chanserv
[03:35] <+bluechill> Yeah.  That works
[03:36] <+bluechill> So minimum usermode below it in terms of permissions
[03:36] <+Polynomial> and ~ means admin, which has all permissions
[03:36] <+bluechill> And cannot be changed
[03:36] <+bluechill> Has to have all
[03:36] <+Polynomial> different & users could have different permissions
[03:36] <+Polynomial> but there wouldn't be a need for anyone to see those differences publically
[03:36] <+Polynomial> it's all internal
[03:37] <+bluechill> yup.  Also, your logging this right? I'll want a copy of this later because I'm too lazy to rip the logs from colloquy off
[03:37] <+bluechill> My iPhone
[03:37] <+Polynomial> yes
[03:37] <+Polynomial> I also think +v needs an overhaul
[03:37] <+bluechill> Ok good and that sounds good.
[03:37] <+bluechill> Yeah voice isn't so clear :P
[03:37] <+Polynomial> right now it's only used to signify that the user isn't just a random user
[03:37] <+Polynomial> and that it can get past +m
[03:37] <+Polynomial> but that's not really that useful
[03:37] <+bluechill> How about +r registered?
[03:37] <+Polynomial> how do you mean?
[03:38] <+Polynomial> I think +r on users is good, and +R for channel should mean "require user to be registered with NickServ"
[03:38] <+bluechill> So if the user is registered then they have +r however that doesn't grant them voice in +m.  +v should still exist but only for being able to get around muted channels
[03:38] <+Polynomial> just like it does now
[03:39] <+bluechill> Separate voice from registered
[03:39] <+Polynomial> ah, that should be configurable
[03:39] <+bluechill> Yeah
[03:39] <+bluechill> But minimum is just a thing to say "I'm registered"
[03:39] <+Polynomial> so basically
[03:39] <+Polynomial> +r means you're registered
[03:40] <+Polynomial> I think when you set +m, it should (by default) give +v to any +r user
[03:41] * bluevoid (bluechill@B8D629DD.11ED827A.E33B6120.IP) has joined #securityoverride
[03:41] * ChanServ sets mode: +v bluevoid
[03:41] <+Polynomial> wb again
[03:41] <+bluevoid> This is why I don't like colloqy
[03:41] <+bluevoid> It's unstable
[03:41] <+bluevoid> What did you say after my last message?
[03:41] <+Polynomial> I think there should be a channel option (not a mode) to have +v given to +r users when +m is enabled
[03:42] <+bluevoid> Yeah
[03:42] <+bluevoid> Although then there should be a mute mode for users
[03:42] * +bluechill (bluechill@bluechill.fbi.gov) Quit (Ping timeout)
[03:42] <+Polynomial> yes
[03:42] <+Polynomial> definitely
[03:42] * bluevoid is now known as bluechill
[03:43] <+Polynomial> I think +q should be quiet
[03:43] <+Polynomial> not channel owner
[03:43] <+bluechill> Yeah.  That would work.
[03:43] <+bluechill> +f? Channel owner?
[03:43] <+bluechill> Founder
[03:43] <+bluechill> Logical no?
[03:43] <+Polynomial> I was thinking +a for admin, +s for super-op, +o for op, +h for half-op
[03:43] <+bluechill> Ah
[03:43] <+bluechill> That works
[03:43] <+Polynomial> +v for voice, obviously
[03:44] <+bluechill> ofc but that's a channel mode now
[03:44] <+Polynomial> probably
[03:44] <+Polynomial> but we'd redo channel modes
[03:44] <+bluechill> +r for registered
[03:44] <+Polynomial> like perhaps have lowercase for users
[03:44] <+Polynomial> uppercase for channels
[03:44] <+bluechill> Easy distinction
[03:44] <+Polynomial> yup
[03:44] <+bluechill> I like it
[03:45] <+bluechill> Although, how about server modes?
[03:45] <+Polynomial> I think we should gut those completely
[03:45] <+Polynomial> and replace them with readable config flag names
[03:46] <+bluechill> yeah
[03:46] <+bluechill> That would be better
[03:47] <+Polynomial> and lots of config for the server globally
[03:47] <+bluechill> That's true
[03:47] <+Polynomial> like a directive that says "you can only join channels if you're registered"
[03:47] <+bluechill> Would be nice too
[03:47] <+bluechill> Yeah.  Stuff like that would be nice
[03:48] <+bluechill> Compared to what we currently have
[03:48] <+Polynomial> yeah
[03:48] <+bluechill> What else to change
[03:51] <+bluechill> Oh services
[03:51] <+bluechill> We could change those a little
[03:51] <+Polynomial> I was thinking we should still have services in the traditional sense, but have them as modules of the IRCd
[03:51] <+bluechill> Yeah
[03:52] * VvCMDvV (webchat@hide-6621C7D6.rn.hr.cox.net) has joined #securityoverride
[03:52] <+bluechill> Also they shouldnt be just like ChanServ and NickServ but like more General
[03:52] * VvCMDvV (webchat@hide-6621C7D6.rn.hr.cox.net) has left #securityoverride
[03:52] * VvCMDvV (webchat@hide-6621C7D6.rn.hr.cox.net) has joined #securityoverride
[03:52] * ChanServ sets mode: +v VvCMDvV
[03:52] <+Polynomial> I think they should still be ChanServ/NickServ
[03:53] <+Polynomial> but we should probably have more functionality
[03:53] <+Polynomial> and perhaps additional services
[03:53] <+bluechill> I mean, that's what I meant
[03:53] <+bluechill> More functionality
[03:53] <+bluechill> And more true to their purpose
[03:53] <+bluechill> So like NickServ becomes UserServ and would grant user modes instead of ChanServ
[03:54] <+bluechill> And chanserv more channel stuff
[03:54] <+Polynomial> hmm
[03:54] <+Polynomial> possibly
[03:54] <+Polynomial> they'd need some thought
[03:54] <+bluechill> Yeah
[03:54] <+Polynomial> UserServ makes more sense than NickServ though, yeah
[03:54] <+bluechill> Their current form is good but could be improved
[03:55] <+Polynomial> yeah
[03:55] <+bluechill> I mean, another service could be BotServ which deals with bots and provides information about bots and deals with bots.  So they aren't treated as users
[03:56] <+bluechill> But not as services either
[03:56] <+Polynomial> perhaps even have CopServ for certain security things
[03:56] <+bluechill> Yeah
[03:57] <+bluechill> I mean, more functionality and more
[03:57] <+bluechill> Sensical services
[03:57] <+Polynomial> heh
[03:58] <+bluechill> That would make the most sense
[03:58] <+bluechill> Also, virtual hosts should be standard
[03:58] <+bluechill> But
[03:59] <+bluechill> Admins should have access to their real hostname and bans ban their real hostname however that should be customizable
[03:59] <+Polynomial> of course
[03:59] <+Polynomial> actually
[03:59] <+bluechill> Hrmm
[03:59] <+Polynomial> I think there should be a way to ban people with vhosts by their IP
[04:00] <+Polynomial> in channels
[04:00] <+bluechill> Yeah
[04:00] <+Polynomial> but without seeing their hostname
[04:00] <+bluechill> The server could handle that
[04:00] <+Polynomial> yup
[04:01] <+Polynomial> the command would be interesting though
[04:01] <+bluechill> Eh
[04:01] <+bluechill> From a servers perspective yes, client ni
[04:03] <+bluechill> what else?
[04:03] <+bluechill> I'm sure there's more
[04:03] <+bluechill> Also, do you agree with me on the ping vs keep alive tjjing
[04:04] <+bluechill> We could just have something of a modern game lol
[04:04] <+bluechill> Instead of pong
[04:04] <+bluechill> Lol
[04:04] <+Polynomial> heh
[04:04] <+Polynomial> well ping/pong is fine
[04:05] <+Polynomial> the current system is PING :token / PONG :token
[04:05] <+bluechill> Lol
[04:05] <+bluechill> Yeah
[04:05] <+bluechill> But keep alive makes more sense
[04:05] <+bluechill> :P
[04:05] <+Polynomial> howso?
[04:05] <+Polynomial> ping/pong works fine
[04:05] <+Polynomial> it does the job
[04:05] <+bluechill> It does what it is intended to in a clear way
[04:05] <+bluechill> And less work for the server
[04:06] <+Polynomial> eh, ping/pong works fine
[04:06] <+bluechill> Ping pong not so clear unless you understand irc protocol :P
[04:06] <+Polynomial> notrly
[04:06] <+Polynomial> it's used in loads of protocols
[04:06] <+bluechill> Well
[04:06] <+bluechill> Ok true
[04:06] <+bluechill> :P
[04:06] <+Polynomial> I think ping/pong doesn't need any more engineering
[04:06] <+bluechill> You win there
[04:07] <+bluechill> Maybe the server plays a board game with the client though?
[04:07] <+bluechill> Lol
[04:07] <+Polynomial> heh
[04:07] <+bluechill> Monopoly?
[04:07] <+Polynomial> the less CPU cycles the better
[04:07] <+bluechill> I was joking lol
[04:07] <+Polynomial> hehe
[04:08] <+bluechill> You didnt think I was serious did you? :eye roll: ;)
[04:08] <+Polynomial> hehe
[04:09] <+Polynomial> automated spam and DoS mitigation should be a critical subsystem
[04:09] <+bluechill> Yeah
[04:09] <+bluechill> That is a need in this day and we
[04:09] <+Polynomial> yup
[04:09] <+bluechill> Era*
[04:09] <+Polynomial> age*
[04:09] <+Polynomial> :P
[04:10] <+bluechill> Damn iPhone :P
[04:10] <+Polynomial> ^.^
[04:10] <+bluechill> Auto correct sucks on it
[04:10] <+Polynomial> I know
[04:10] <+Polynomial> but yeah anti-ddos and anti-spam
[04:10] <+bluechill> Although, I mean, we should a system for how users are stored
[04:10] <+bluechill> Like in an XML file
[04:10] <+bluechill> Or something
[04:10] <+Polynomial> nah, it needs to be indexed so it's scalable
[04:11] <+bluechill> Something standardized
[04:11] <+bluechill> Hm
[04:11] <+Polynomial> could have it linked to MySQL?
[04:11] <+bluechill> Yeah
[04:11] <+bluechill> That might work
[04:11] <+bluechill> Or SQL database
[04:11] <+bluechill> So like most apps already do
[04:11] <+bluechill> They have a minisql database for storage
[04:11] <+Polynomial> or even better we could make it cross-endpoint compatible
[04:12] <+Polynomial> use the standard DataTable interfaces
[04:12] <+bluechill> That sounds nice
[04:12] <+bluechill> Sounds nice
[04:12] <+Polynomial> and have plugins so you can use MSSQL/MySQL/PosgreSQL
[04:12] <+Polynomial> *postgresql
[04:12] <+bluechill> That would work
[04:12] <+Polynomial> part of the issue is replication
[04:12] <+bluechill> True
[04:12] <+Polynomial> especially if you're doing multi-server stuff
[04:13] <+bluechill> Another issue though would be legacy clients :P
[04:13] <+Polynomial> no
[04:13] <+bluechill> Just drop them?
[04:13] <+Polynomial> yes
[04:13] <+Polynomial> drop
[04:13] <+Polynomial> or rather show a message
[04:13] <+Polynomial> and then dc
[04:13] <+bluechill> Currently is there even a standard drop for irc?
[04:13] <+Polynomial> yes
[04:13] <+bluechill> I meant
[04:14] <+Polynomial> you just send a server MOTD message and host disconnect
[04:14] <+bluechill> Like k lining but the instance they connect
[04:14] <+Polynomial> yeah, you just cut the connection
[04:14] <+Polynomial> .Close();
[04:14] <+Polynomial> :P
[04:14] <+bluechill> Also, how to specify irc protocol version for servers :P just have it first thing or something?
[04:14] <+bluechill> Lol
[04:14] <+bluechill> True
[04:14] <+Polynomial> protocol version?
[04:14] <+Polynomial> oh
[04:15] <+Polynomial> wouldn't matter
[04:15] <+bluechill> Eh
[04:15] <+bluechill> Might eventually
[04:15] <+Polynomial> you could have a magic number
[04:15] <+Polynomial> like how SSH does
[04:15] <+Polynomial> so the first message would be "IRCv2 <ircd name> <ircd version>"
[04:15] <+bluechill> 0xBADBEEF?
[04:16] <+bluechill> Makes sense
[04:16] <+Polynomial> IRCv2 as ASCII is a good enough magic number
[04:16] <+bluechill> Although negotiating ssl though
[04:16] <+Polynomial> SSL negotiation is transparent
[04:16] <+bluechill> Before or after irc protocol?
[04:16] <+Polynomial> before
[04:16] <+bluechill> Ok
[04:16] <+Polynomial> entire protocol should be encrypted
[04:16] <+bluechill> Yeah
[04:16] <+bluechill> Makes most sense
[04:17] <+bluechill> Also
[04:17] <+bluechill> Ddc should be updated
[04:17] <+Polynomial> DCC*
[04:17] <+bluechill> iPhone ;)
[04:17] <+Polynomial> I think it should be removed
[04:17] <+bluechill> Hard enough to type on this
[04:17] <+bluechill> Eh
[04:17] <+bluechill> Yeah
[04:17] <+Polynomial> NAT makes it break
[04:17] <+bluechill> Tre
[04:17] <+Polynomial> it's only ever used for bots on file sharing IRCs
[04:18] <+Polynomial> these days people just upload to sendspace
[04:18] <+bluechill> And really the only point of it is to get around the server if the server dies but because nat breaks it it means you would have to go through the server which is the exact opposite you want
[04:18] <+Polynomial> exactly
[04:18] <+bluechill> Besides file sharing
[04:19] <+bluechill> So yeah
[04:19] <+Polynomial> though then again if we're going IPv6 enabled
[04:19] <+bluechill> DDC gone
[04:19] <+Polynomial> we should have an option for DCC
[04:19] <+bluechill> Why?
[04:19] <+Polynomial> NAT wouldn't be used for IPv6
[04:19] <+bluechill> So?
[04:19] <+Polynomial> everyone gets their own IP
[04:19] <+bluechill> Do we even need it
[04:19] <+Polynomial> DCC would be useful
[04:19] <+bluechill> Eh ok
[04:19] <+Polynomial> no, but why remove it if it's useful?
[04:20] <+bluechill> However
[04:20] <+Polynomial> all it has to do is swap IPs
[04:20] <+bluechill> We aren't just ipv4
[04:20] <+bluechill> 6*
[04:20] <+Polynomial> ofc
[04:20] <+bluechill> It's ipv4 too
[04:20] <+Polynomial> indeed
[04:20] <+bluechill> Which means it's still broken for that
[04:20] <+Polynomial> obviously
[04:20] <+Polynomial> I think it should be something the client has to advertise
[04:20] <+bluechill> So would it just go through the server then or just not be attempted?
[04:21] <+Polynomial> so like a CAPS command
[04:21] <+bluechill> Ah ok
[04:21] <+Polynomial> to tell the server your client capabilities
[04:21] <+bluechill> That's probably best
[04:21] <+bluechill> On initial connection it states capabilities
[04:21] <+Polynomial> yes, or it can change caps over time
[04:21] <+bluechill> True
[04:21] <+Polynomial> so when you modify your config it updates via CAPS
[04:22] <+bluechill> Ok
[04:22] <+bluechill> Sounds good
[04:22] <+Polynomial> caps can be stuff like DCC, GPG, SSL flags (does the user have a client certificate?)
[04:23] <+bluechill> Ah
[04:23] <+bluechill> Right
[04:23] <+bluechill> That would work nicely
[04:23] <+Polynomial> I also think MemoServ needs to be overhauled
[04:23] <+bluechill> I forgot about MemoServ
[04:23] <+Polynomial> so that there's an explicit memo inbox
[04:23] <+bluechill> Yeah
[04:23] <+bluechill> I mean
[04:23] <+Polynomial> as a core part of the protocol
[04:24] <+bluechill> Either that or it's handles by UserServ then
[04:24] <+Polynomial> instead of the whole "one server window" paradigm
[04:24] <+Polynomial> no, memos should be separate
[04:24] <+Polynomial> userserv handles user account management
[04:24] <+bluechill> Ok yeah
[04:24] <+Polynomial> chanserv handles channel registration and management
[04:24] <+Polynomial> memoserv handles memos (mail)
[04:25] <+Polynomial> perhaps have CopServ as a background service that is configured only by ircops
[04:25] <+bluechill> Hidden from public view?
[04:25] <+Polynomial> so it can detect DDoS, floods, joinfloods, badwords, etc
[04:25] <+Polynomial> no, it'd be visible
[04:25] <+bluechill> Yeah
[04:25] <+Polynomial> just no user commands
[04:25] <+bluechill> Ok
[04:26] <+Polynomial> only admin commands
[04:26] <+Polynomial> so it would be responsible for bans
[04:26] <+bluechill> Or it can atleast have a what is this command
[04:26] <+Polynomial> as in automatic anti-abuse bans
[04:26] <+bluechill> Yeah
[04:26] <+Polynomial> maybe have copserv handle abuse reports
[04:27] <+Polynomial> and appeals
[04:27] <+bluechill> That works
[04:28] <+bluechill> Also
[04:28] <+Polynomial> oh, whois/whowas should be better too
[04:28] <+bluechill> It should handle channel based encryption, encryption for a channel separetefrom ssl
[04:28] <+bluechill> Right.  More detailed?
[04:29] <+Polynomial> encryption is a core part of the IRCd, not handled by a service
[04:29] <+bluechill> No
[04:29] <+bluechill> I mean
[04:29] <+bluechill> Like channel based encryption, encryption on an individual channel basis
[04:29] <+Polynomial> whois should be able to see which nicks were used by a host
[04:29] <+bluechill> That would be useful
[04:29] <+Polynomial> yes, the encryption would be a channel mode set via ChanServ
[04:29] <+Polynomial> and then the encryption would be performed by the IRCd core
[04:30] <+bluechill> Ah ok
[04:30] <+Polynomial> though tbh I think we should just enable SSL across the board
[04:30] <+bluechill> I was thinking copserv would handle negociarions
[04:30] <+bluechill> Yeah
[04:30] <+Polynomial> there's no downside to it
[04:30] <+Polynomial> messages are short
[04:30] <+Polynomial> it's transparent and zero config
[04:30] <+Polynomial> very little CPU overhead
[04:31] <+bluechill> But we could add another layer of encryption on a per channel basis
[04:31] <+Polynomial> why?
[04:31] <+Polynomial> if it's covered by SSL already, there's no need
[04:31] <+Polynomial> any further encryption would just be bloat
[04:31] <+bluechill> True however, then we should add at least the possibility for per channel ssl veers
[04:32] <+Polynomial> veers?
[04:32] <+bluechill> Certs*
[04:32] <+Polynomial> again, no need
[04:32] <+Polynomial> if the server's cert is trusted, you've got the max security possible
[04:32] <+Polynomial> having people manage individual certificates for channels becomes awkward and unwieldy
[04:32] <+Polynomial> not to mention annoying for clients
[04:33] <+bluechill> Eh righty
[04:33] <+bluechill> Right*
[04:33] <+Polynomial> I think SSL should be a 100% requirement though
[04:33] <+bluechill> Yeah, IRCD is also already handling all other server certs too
[04:33] <+bluechill> IFC
[04:33] <+bluechill> Of course*
[04:34] <+bluechill> I mean, there is practically no overhead so why not?  Doesn't hurt
[04:34] <+bluechill> And just makes everything more secure
[04:34] <+Polynomial> exactly
[04:35] <+Polynomial> that way you can also explicitly provide a client certificate
[04:35] <+bluechill> Big gain for little effort
[04:35] <+bluechill> That works
[04:36] <+Polynomial> so if you want to authenticate to UserServ or to the server as an ircop, you can do so based on a client certificate as well as or in leiu of a password
[04:37] <+bluechill> How about the cert is used for authentication instead of passwords in general?
[04:37] <+bluechill> Makes it practically impossible for cracking it
[04:38] <+Polynomial> complex to set up for the client
[04:38] <+Polynomial> for regular users a password is a better method
[04:38] <+Polynomial> it's familiar, requires no extra knowledge or research
[04:38] <+Polynomial> it should be something clients offer
[04:38] <+Polynomial> I'm thinking bencode for each message, preceded by 2 bytes (ushort) to signify the length of the message
[04:38] <+bluechill> Ok yeah but for authentication for things like server functions certs are a must
[04:38] <+Polynomial> obviously
[04:39] <+bluechill> Including authentication to op
[04:39] <+bluechill> And above
[04:39] <+bluechill> A little harder on the client but more secure
[04:40] * ev0 (40861b40@hide-D2318732.mibbit.com) has joined #securityoverride
[04:40] <+bluechill> However, there should also be a password for nick authentication not just one cert.  Cert only used for server level authentication
[04:40] <+Polynomial> so like for bencode of privmsg it'd be \x00\x1atype:s7privmsgdata:s5Hello
[04:41] <+bluechill> Something like that
[04:41] <+Polynomial> I forget the exact bencode spec
[04:41] <+bluechill> :P I'll google it tomorrow
[04:41] <+Polynomial> hehe
[04:42] <+Polynomial> or even something like...
[04:42] <+bluechill> I think though that this will be something interesting to implement
[04:42] <+bluechill> and very useful
[04:42] <+Polynomial> ushort msgsize; entry[] entries;
[04:42] <+bluechill> Although
[04:43] <+Polynomial> where entry is struct { char datatype; ushort length; char* data }
[04:43] <+bluechill> I think the ability to send priv msgs to users currently offline if you hVe permission would be useful
[04:43] <+bluechill> Like admin to admin
[04:43] <+bluechill> Or something
[04:43] <+bluechill> And yeah
[04:43] <+Polynomial> that's what MemoServ is for
[04:43] <+Polynomial> if a user isn't on, you memo them
[04:43] <+bluechill> No I mean
[04:44] <+bluechill> I though memo serv was global?
[04:44] <+Polynomial> no
[04:44] <+Polynomial> memoserv is user to user
[04:44] <+bluechill> Oh my bad
[04:44] <+Polynomial> it's like email :P
[04:44] <+bluechill> Right
[04:44] <+Polynomial> when you +r it logs you into memoserv
[04:44] <+bluechill> Anyways
[04:44] <+Polynomial> and tells you what memos you have
[04:44] <+bluechill> Yeah that would be a nice thing built into the protocol
[04:45] <+Polynomial> well that's what memoserv does atm
[04:45] <+Polynomial> but I'd want to make it more integrated
[04:45] <+bluechill> ^ what I meant
[04:45] <+Polynomial> so clients would be expected to have a dedicated memo window
[04:45] <+bluechill> More integrated
[04:45] <+Polynomial> instead of having them viewed directly by user command
[04:46] <+bluechill> Yeah.  That would probably work
[04:46] <+Polynomial> anyway
[04:46] <+Polynomial> really late here
[04:46] <+Polynomial> imma hit the hay
[04:46] <+Polynomial> night .o/~
[04:46] <+bluechill> Ok
[04:46] <+bluechill> Night
[04:46] <+Polynomial> I'll think more about this overnight
[04:46] <+bluechill> \o
[04:46] <+bluechill> Yeah same
[04:46] <+bluechill> I do want to code this eventually though
[04:47] <+bluechill> And isn't it like 5am there?
[04:48] <+Polynomial> yup