IRC Nicknames

[ChristianGaertner]

Hi,

I think it would be cool to have IRC Nicknames (registered with NickServ) added to the verification list.

I imagine something like an input for the server (or just freenode to begin with?) and the main NickServ account.

KeyBase would need a simple bot to join the server (or in case of freenode only, idle on the server) and query nickserv.

A user can add metadata to their account in simple key=value format.

This would integrate very well with already existing verification systems used on KeyBase (TXT record verification).

What do you think?

Christian (https://keybase.io/dagardner)

[zQueal]

Not sure how this would be implemented, but it would certainly be awesome to see! Especially for official channels.

[thomwiggers]

NickServ bots are very different. Not all support adding metadata. It'd be hard to support all IRC networks.

[craighurley]

On some networks, don't nicks expire if they are inactive for any length of time which means they are available for registration by others?

[grawity]

They do, usually in 2-6 weeks (freenode's 10 weeks might be the longest). (Though the "info" response usually shows the account registration date, and in Atheme 7.1 also the unique "entity ID".)

[rummik]

One option might be using CTCP to check periodically, and make sure they're authed with NickServ when the check happens. The tricky bit is how often, and how to handle users who only use IRC during certain hours of the day

[craighurley]

I for one treat IRC as a place that I don't want information about me leaking to other unknow users/systems, therefore I block all CTCP requests by default and more importantly I use a cloak so users cannot simply do a /whois to see my IP address. There are many other users that take the same approach.

Considering the transient nature of IRC and nicknames, this all sounds very fragile.

[rummik]

@craighurley Hm. True. There's also the users who change their nick to display away status.

[grawity]

I am not sure what good CTCP would even do here. It is not good as an online check, and only some clients allow defining custom replies for using it to store Keybase metadata.

[rummik]

@grawity Good point. Hadn't really thought about the implications of that. At the same time, I'd argue it's a bit like having a server go down

Nothing seems to really beat IRC networks that allow storing metadata with NickServ though.

[katanacrimson]

The only way this could be possible is for those networks which implement CertFP - which is at least freenode, oftc, and rizon to my knowledge. Those use client-side keys (still gpg keys) for authentication and can be validated as such.

Not sure that there's a way to get that user's fingerprint publicly though.

If anything this would be more applicable to XMPP, which is federated, well-standardized and moving towards encrypted-only communications (especially through gpg and otr).

[grawity]

CertFP is X.509 SSL certificates, not PGP. And no, practically all servers hide that information.

[Eremiell]

When NickServ deletes your registration (I hate networks, which does this), all your information simply disappears from NickServ. All you have to do is some periodic /msg nickserv info . You can add the signed verification message as something on nearly all servers. You can start a special channel #keybase-verification and log it. You can do a lot of different stuff. Cloaking is a common sense, but doesn't prevent authentication in any way. Would love to see Freenode, OFTC and possibly Mozilla networks.

[keaston]

Being able to prove a Freenode NickServ account seems like a good addition. Expiring NickServ accounts are really no different to expiring domains.

[kyrias]

I'd imagine something like the following:

1. The user signs a claim containing the IRC network, Account ID, and Account Name. The IRC network should probably point to a domain one can connect to, so that the implementation doesn't need a list of possible servers.
2. The user then sets a NickServ metadata property with the hash, like you do with DNS proofs already.
3. On the backend the keybase server will then connect to the server, (probably with a whitelist of allowed servers,) and query the account username's info, and compare the Account ID and the metadata property to what was claimed by the user.
4. If both matches the claim is valid, else not.

One issue with this is that currently freenode does not show the account ids in the info output. It might be worth asking them about enabling it.

[gene1wood]

You may want to suggest this on the master verification suggestion issue #518

[mfin]

1. You trigger a request for registering a Freenode nickname on keybase.io
2. Keybase gives you a command to execute in your IRC client (something like /msg KeybaseBot verify someverylonghash78234652)
3. KeybaseBot looks up your NickServ info and verifies your nickname

I could see this happening.

[Freso]

Libera.Chat’s NickServ allows freeform taxonomy entries in your account data, so you could do something like /msg nickserv set property keybase-verification freso:445c124895d77b8af62011d67eaaf908e0c07b91826a7881d112ca688dcfb5bb0eb0dd18c775713e0f17db4403d8d7d80470e98670fe2a3c24da311d8f88d84f (or, y’know, whatever hash), which could then easily be queried using /msg nickserv taxonomy Freso.