There is a nice initiative to get some standardisation back into IRC networks at http://www.irc-plus.org
IRC is constantly losing users, and it's not like this initiative can stop it from doing so, but it relieves a lot of pains.
Essentially it produces some standardized interfaces for basic functions, which are slightly different on each IRC network, making it impossible for a client developer to make them just as easy to use like any other chat application.
Thus IRC can become easier to use, even if many problems are not addressed or solved by this.
Nonetheless, lynX has decided to support it in psyced, and working on the draft to be streamlined to minimalistically only do what everyone needs and do it in the smartest possible way. This should maximize acceptance for it.
IRC+ drafts: Overview
First of all, I am seriously pondering if IRC+ services draft should be split up into
- IRC identification (dealing with NickServ and how to resolve an IRC URI)
- IRC conference control (dealing with ChanServ etc.)
- Further IRC services (leaving memos etc..)
- IRC subscriptions (see below)
- IRC uniform network identifications (the IRC URI syntax in a doable specification)
Current drafts are located at http://www.irc-plus.org/specs/
IRC+ drafts: Common issues
Reference: RFC 1459
Maybe mention also the other RFCs and our relation to them. Proposal:
- RFC2810-2813 describe the protocol of an IRC branch, which has not been adopted by the majority of existing IRC technology implementations.
Inspirations from Services Implementations
We are comparing major services implementations and make sure the draft actually reflects a fair common denominator.
For the creation of the drafts we are taking the following IRC service implementations under consideration (see comments about each of these in the sources of the drafts):
ircservices.za (isza)
- Generic SET command for setting variables like language, timezone, homepage etc.
- isza comes with a series of AUTH commands for email-address-authentication
- isza provides several admin extensions which we of course do not take in consideration
- Service-side autojoin list (AJOIN etc).
- Several LISTsomething commands.
- SENDPASS for ChanServ (paranoid?)
- SOP (super-ops), LEVELs and a healthy mess of auto-op/halfop/voice lists.
anope-1.7.18.tar.gz of http://www.anope.org/
- has all those funny SOP AOP HOP and VOP lists, too
atheme-1.2.1.tgz of http://www.atheme.org/
Large, popular and well documented. Similar to isza and anope, but slightly different again.
- E-mail authentication is done with a VERIFY command instead of isza's AUTH
- SET PROPERTY and TAXONOMY (see below)
- Operators can set a VHOST for users
- It doesn't seem to provide the ACCESS command!?
PTlink.Services2.26-eol.1.tar.gz
- Service-side autojoin list (AJOIN etc).
DALnet Services
Not sure which software they use, but by looking at http://www.dal.net/services/ it looks like a common denominator of many other service styles I have seen so far. No surprise, since after the 1991's demise of the original NickServ, DALnet was the first network to re-implement NickServ in 1994, and the original inventors of ChanServ. (whereas MemoServ is similar to 1991's NoteServ and MsgServ). So the DALnet services suite has been the prototype for most following services systems.
Special things:
- /NickServ ACCESS WIPE
- No nickname links
- This is where SOP and AOP come from, but luckily HOP and VOP are missing.
- /MemoServ NEWS
Q on QuakeNet
Since QuakeNet has a registration system totally outside the NickServ tradition, the flow of operations is different at times:
- HELLO sends you an email, you AUTH to it, then change the random password to your own using NEWPASS.
- REQUESTPASSWORD lets you request a remail of the password in case you lose it
- Q is a combined something-serv, and having Q as a bot on your channel seems to be a privilege.
- If you can't have Q, then you can at least have L, whatever that means.
- In fact L seems to be the lightweight variant of Q. Now you know it.
- There is also R to send requests to, whereas S is a channel bot that takes care of spam.
- The CHANLEV etc. commands do all similar things like the ChanServ equivalents, but quite differently (and more rudimentarily).
We can try to make our flow at least a bit Q-friendly, at least concerning registration, by allowing RPL_SUPPORTS_IRCPLUS to say No, we don't accept registration passwords from you. We prefer to generate and email them, so give us an e-mail address only. Still given how Q looks it is to expect that Q will either always remain different, or they are willing to modernize their whole services thing anyhow. I think an IRC+ interface should be able to co-exist with Q, even if using two quite different APIs.
Theia of freenode
- No email delivery
- LINK/UNLINK
- AUTOREM ADD/DEL/LIST (like ACCESS, but for ChanServ) instead of AKICK etc.
Magick-1.4.tar.gz
Pretty similar to Theia.
- AKICK instead of AUTOREM.
hybserv-1.9.3.tar.gz
- REGISTER with password recovery phrase instead of e-mail
- RECOVERPASS
- LINK/UNLINK/DROPLINK/SHOWLINK
- AKICK
- ACCESS for both nickserv and chanserv
srvx-1.3.1.tar.gz
By the first glance I can tell srvx likes to do pretty much everything differently than others. Let's see the details concerning srvx's NickServ:
- REGISTER requires an account name
- UNREGISTER instead of DROP
- ADDMASK/DELMASK instead of ACCESS ADD/DEL
- REGNICK/UNREGNICK instead of LINK/UNLINK
- RECLAIM instead of RECOVER/RELEASE/GHOST
- "Depending on configuration, this may do nothing, may ask the user nicely, may force a nick change on them, or may /KILL (disconnect) the target user."
- MERGE allows to merge accounts, cute.
ChanServ also looks quite different, even if it essentially does a similar job like any ChanServ. Just MemoServ looks rather familiar, but comes with EXPIRE and EXPIRY.
SrSv SurrealServices
http://www.surrealchat.net/wiki/SurrealServices
<tabris> symlynX: I realize it's probably not much on all of this, but
SrSv has been looking at implementing timezones. currently no
work has been done on i18n tho, mostly b/c we don't have any
translators (and the changes required to how we construct
response messages)
- ACC (like STATUS in the draft) comes with an extended set of flags
0 - Nickname Unregistered 1 - Registered, Offline 2 - UnIdentified 3 - Identified via password authentication 4 - Identified via access list 5 - Forbidden Nickname
- NickServ has channel list invitations you can ACCEPT or DECLINE.
- MAINNICK is called CHGROOT (even uglier ;))
- Profile/Settings/Metadata, independently from SET command, like this:
/ns profile set birthday June 9, 1969 /ns profile set mood sassy
- SEEN <nick>
- G/SIDENTIFY - variants of identify that kick old instances of your nickname
I presume these two require some user MODE extension that nickserv can send to your server.. a bit back and forth:
- SILENCE ADD/DEL/LIST - server-side ignore (yeehah.. old friend) ...
- WATCH ADD/DEL/LIST - server-side notify (sigh, yeahyeah WiZ didn't like mine..)
JService
J implements all services functions in a single service bot.
- AUTH instead of IDENTIFY
- AUTOJOIN on auth
- RSS <list|add|del|filter|mute|unmute> [<rssfeed>|<on|off>] ... multiple feeds per channel
- built-in command aliases using SCRIPT
etc.
modserv2x-2.001.tar.bz2 of undernet
... comes with no useful documentation and no obvious NickServ-like commands. Probably wrong file.
gnuworld-cvs-20070326.tar.gz of http://www.gnuworld.org
is a very large distribution containing all sorts of experimental extensions and hilarious language options like christmas and easter-variations of the help messages. I am however unable to find documentation about the actual NickServ etc syntax, neither in the package nor on the website. Strange.
ecks.0.7.tar.gz
Distribution of Java binary classes, no sources, with an MPL license however. No trace of any documentation.
IRC+ on Identification
RPL_SERVICES_NEEDPASS
Can we define an (optional) way to require identity passwords before completing login? In PSYC we don't have people hanging around on somebody else's nickname even for a split second. SASL is cool here.
Identity and IRC URI
I think the nickserv draft should also lead to reliable irc identities with an IRC URI syntax worth mentioning. Not irc://somenetwork,andmaybeyoufindmebythenameofXXX but being able to say i *am* irc://network/~nick - even if i am currently using one of my linked nicknames.
Linked nicknames to an identity
GROUP and GLIST are really bad names for this, LINK, UNLINK and LIST LINKS are much better.
Still the entire concept of having several nicknames connected to an identity should be optional. For simplicity some networks simply do not allow you to switch nicknames (without also changing your identity).
Anope is the only services implementation using "GROUP", the others prefer LINK. Isza also provides UNLINK while none of the others do. I presume DROP is defined to only unlink a nickname, not drop the entire identity, unless the main nickname has been given. I wonder which interface is the best here.
IRC+ on Conference Control
Death the HALFOP
i think the irc user levels should not be hardcoded into the protocol any further. voice/halfop/chop/whatever should be freely choosable strings or numeric values, maybe even bitflags, so that each network and ircd implementation uses whatever it finds suitable.
IRC+ on Subscriptions
Should we get a critical amount of people to support the basic Services Protocol, we can come up with extensions to that and get them accepted, too.
http://www.irc-plus.org/subscriptions-draft.html is a follow-up Internet draft to provide such seriously interesting enhancement to the existing IRC functionality.
It however needs more work:
Metadata Keywords
The meta data list is still very random, lynX suggests to postpone it entirely to a later IRC+ version, even though lynX does like the idea as such!
Most of it however isn't presence data but rather metadata. We could call it "semantic IRC"! :)
Presence is only about being here or not being here, availability, mood etc. I of course am a fan of our own presence model which you may want to have a look at.
- atheme has a metadata command called SET PROPERTY .. the help file suggests properties like URL (homepage), SIGN (horoscope rather than birthday) and other messaging schemes. According to the source the properties can be chosen freely, but you have a limit on the amount and you need a special privilege to use this.
lastfm
Putting one particular commercial social network in here will not scale with the continous growth of social networks. lynX suggest to have a links or URIs or uniforms field which contains any kind of http://xxxx or other urls, then the clients can figure out what to do with each of them.. provide comment-box-links for myspace urls, or music statistic pushing for lastfm. Whatever.
np, away
They look unfinished too
altloc
Absolutely needs to be filled with URIs too, not some clumsy scheme: screenname syntax. In fact URIs look almost the same, just without the space. xmpp:user@host psyc://psyced.org/~lynX etc.
Also altloc is cryptic - why not just put them into links as well?
www
Another special case of links, but if it is the main homepage maybe it should be the first http: link in links.
rss
RSS is stupid because IRC is a much better medium to announce changes to a website in real-time. Why use a polling technique for that? But if you insist on having that, you can put it into links as well, or have some metadata XML format like FOAF point to it.
tag
Tags can be neat, but they are usually used to provide search engine keywords and navigation. What you mean by tag is probably the actual presence. You may want to provide presence availability as a numeric as we do...?
SUBSCRIBE
This doesn't seem to take care of user's privacy requirements at all. Do I get that right?
You need to have a friendship subscription model between users before they can agree on sharing event notifications and presence updates between each others.
I was told that his is intended to be either tagged private (nobody sees the info) or public (anyone can see it, like the web or FOAF). No friends modeling here.
Also I am told notifications are unicast to each recipient one by one. That's a scalability no-no.. That's not nice. I hoped they'd use the multicast backbone.
Factually subscribing presence is technically equivalent to joining a user's presence channel. Shouldn't it be implemented by listen-only channels?
Bad about channels is, they require network broadcasts for their memberships, and since people come and go, you can't just do the channel membership once forever.
I guess then it depends on the popularity of the sender and the amount of events she generates, whether broad unicast is okay, network broadcasts are better or setting up a distribution channel.
I propose to postpone this entire presence and subscription issue to a future IRC+ draft. It is too complex.
Then again we could indeed have a specification for these kind of extensions and leave it open to the implementation to provide any form of privacy or efficiency in routing. But that would probably result in psyced being the only server implementation which uses actual friendship modeling for privacy and uses actual multicasting for the distribution. are you sure you want to do this? ;)
Why not CTCP?
When pushing CTCP to your channel, or the channel of your favorite peer group, you mostly reach the intended audience of your metadata pushes, you have better privacy as you can apply IRC conference control to the channel, you also get better routing as IRC channels are very efficient.
Why wouldn't you want to standardize things like CTCP PLAYING or CTCP LINKS instead of this services-based approach? Just because old clients can't handle new CTCP messages?
Well, it's a mistake they even show unknown CTCP messages! When I did my release of ircII it had CTCPs invisible by default and only /set verbose_ctcp would turn them on. Too late to change that probably, but at least unknown channel CTCPs should be silently dropped so that future extensions have a chance.
Also all clients should be able to filter certain CTCP codes, like CTCP NP (or PLAYING or MUSIC or SONGPLAY, whatever you wanna call it), if you don't want to see them.
So is there any technical problem with CTCP, or is it just a cultural one gone awry?
Alright, I got some answers:
- Server flood control might not even let us submit as many metadata changes as we like.
- Doing it on a channel will trigger CTCP flood provisions (this should only happen on channels not intended for CTCP metadata usage - it should be okay on channels of friends that WANT metadata)
- Channels have metadata to send, too (and CTCP from channels is not defined so far)
What about channel distribution
The idea would be as follows: Channel operators set a MODE on inhabitants to allow them to send metadata. Also the channel itself can send metadata. Metadata is distributed as a numeric to that channel and only delivered to clients that have activated irc+ subscription protocol.
This saves good privacy and routing of channels without running into the CTCP abuse trap.
Persistent metadata
Most metadata should also be available to users entering a channel later on. Unicasting the metadata to these people doesn't scale as well as the IRC network itself: Should 10000 people join a channel because some pop star on TV mentioned it, the network would be overwhelmed by unicasts of information which was supposed to already be there anyway.
The only memory space an ircd has for persistent data of a channel is the TOPIC, and putting metadata in TOPIC is what everybody already does these days - they just don't have a proper format. Here's an example:
*** Topic for #irc+: http://www.irc-plus.org : User-friendly IRC is possible! / http://svn.kvirc.ru/rfc/ircplus-rfc.xml / www now auto-updates on svn commit / Voting: we need a wiki (5) or forum (6) or ML (3) - Who is implementing the RFC ?
This list is a series of untagged homepage / motto / working-document / news / issues metadata elements.
There are two ways to solve this problem:
1. Introduce a new PROPERTY protocol which keeps persistent metadata on each leaf of the IRC network. This requires all IRC servers to implement this and all clients to deal with it.
2. Define a metadata syntax on top of TOPIC. This may require extending the default length of topics in IRC servers to make it useful, but no change of code. Also all clients already know how to display the metadata to the user, later they can learn to parse it and do fancy things with it. Later a finer grained protocol in form of numerics being sent from the services can be introduced, which only changes parts of the metadata without resending an entire TOPIC, and the servers can learn to accept the /topic command from clients in such a way, that it only changes a part of the TOPIC data - not all.
There is a problem with approach #2, it needs an upgrade of the historic 512 byte limit of IRC messages to be useful, but such an upgrade looks like a completely crazy endeavor when looking at any ircd source code. Ouch! Just look at what my first grep in the include directory produced, so funny it's sad:
#define BUFSIZE 512 /* WARNING: *DONT* CHANGE THIS!!!! */