Development/IRCdServices
From the makers of InspIRCd.
Contents |
New design (v2)
Channel permissions
Each channel will have a list of ranks. Each user in the channel will have (one or more) ranks.
A rank may be assigned a prefix, in which case it is tied to that prefix - setting the prefix grants the rank, people with the rank get that prefix.
Each rank can be given permissions:
Flags
- MODE-<any valid mode letter> (you can change this mode)
- MODE-* (you can change any mode)
- JOIN (i.e. banwalk or autoinvite)
- KICK
- TOPIC
- ACL (can't change any flag you don't have)
- (any other channel command that asks the right question)
Old design (v1)
Note: This module is in pre-alpha and should not be used except for testing
Implemented using two added commands: NICKSERV and CHANSERV. Use aliases to make them NS/CS.
Nick registration
User interface
REGISTER <password> CHGPASS <oldpass> <newpass> GROUP <target account> <account's password> [identifies you and groups nick] UNGROUP <nick> <account password> [can't ungroup the current nick] DROP <account password> [drops ALL grouped nicks] IDENTIFY [nick] <password> [if you specify a nick, changes your nick & kills the current occupant]
Database (delta) Interface
<ts> GROUP <acctid> <nick> <ts> A_SET <acctid> password <passhash> <ts> UNGROUP <acctid> <nick> <ts> DELETE <acctid>
Record collapse eliminates UNGROUP by removing the corresponding GROUP commands; PASS is moved after the first GROUP or dropped if there's none left.
Password hashing would need to include: algorithm, salt, hash. Algorithms for compatibility w/ existing services, and one as a default for new.
Deletion events will be automatically generated for accounts without any associated nicks.
S2S Interface
Same commands as database interface. To avoid bursting, network-wide checkpoints are taken at intervals (hour? day?) along with a checksum; servers only burst data after the last matching checkpoint.
GROUP/UNGROUP is done by forcing match. Older TS wins, unless there's a matching UNGROUP. An UNGROUP log is kept for some time (or size) to ensure propagagion to all servers.
Notes
Account IDs must have a unique namespace. Need a good way to enforce this - using SID isn't really good enough, but it will work until a better solution is found.
Given unique namespace, PASS is simply merged on the timestamp. Equal timestamps go alphanumeric - the user deserves pain if they do that. And it's quite unlikely to happen.
Channel registration
User interface
REGISTER <channel> [grants you access to the ALL group]
ACCESS <channel> [LIST]
ACCESS <channel> [SET] <nick> <flaglist>
ACCESS <channel> DEL <nick>
GROUP <channel> [LIST]
GROUP <channel> [SET] <flag-group-name> <flaglist>
GROUP <channel> DEL <flag-group-name>
DROP <channel>
SYNC <channel> [ user command, no DB modification ]
SET <channel> <item> <value>
DESCRIPTION
ENTRYMSG
Flags
- AUTO-<any of qaohvV> (you get it when you join)
- MODE-<any valid mode letter> (you can change this mode)
- MODE-* (you can change any mode)
- JOIN (i.e. banwalk or autoinvite)
- KICK
- TOPIC
- ACL (can't change any flag you don't have)
- (any other channel command that asks the right question)
A flag group is a group of flags, made for easier UI. Example config will contain a default set of flag groups for new channels.
The special flag group "LOCK" will be used to prohibit actions normally allowed to users, for example kicks or topic changes by channel ops, or joins, or specific mode changes. This is only for people who don't have an account granting them the permission.
Database (delta) Interface
<ts> CREATE <cid> <channel> <chanTS> <ts> ACL <cid> <acctid> <flags> <ts> G_ACL <cid> <name> <flags> [empty list deletes] <ts> C_SET <cid> <item> <value> <ts> DROP <cid> <chanTS>
S2S Interface
Everything is merged on TS; latest wins for everything except when the full registration is at stake, in which oldest wins. Blank/zero levels and values, along with drops, are pruned on a similar schedule to the nickserv UNGROUP data. Checkpointing is also done in the same way.
Database Snapshots
Rather than needing to replay the entire history of the services database on startup, state snapshots will be saved. These state snapshots will also form the basis of the "miniburst" to reduce bandwidth use on server splits.
Each line will represent a single record (user or channel). Records will be sorted by ID. Within a single record, items will be sorted.
<itemID> <nick> (<nick>)* . (<key> <value>)* .
<itemID> <channame> ((<key> <value>)* .){3}
The values of the channel record will be, in order: properties, groups, members.
The filename of state files will be state-<hash>.db, where <hash> is the SHA-1 of the contents. As such, no timing information will be stored in the file.
State files can be completely recovered using the database log files; they do not need to be backed up, and the files will be pruned automatically as they age.
Other notes
Advantages over fully separate services
- Netsplits don't disable services for anyone
- Connecting with PASS can auto-ghost an existing nick
- (optional) Connect block information can be changed when you identify
- Users can identify using their nickserv password as the server password, even when the server itself requires a password
- (optional) Q:line on all registered nicks so that using a registered nick requires identification
- This would require people to identify to their nick before changing, or to identify via PASS on connect
- Oper class permissions can be used to configure services access
Features that are not yet in-protocol
- Automatic nick and channel expiry (manual is done)
- "Last use" of nick/account/channel is not currently tracked.
- "Founder" and "Successor". Instead, all people with access to the "ALL" group are equal controllers of the channel.
- Might be useful to keep a record of founder as a textual attribute like description.
Deprecated because of duplication
- GHOST - just use the two-parameter version of IDENTIFY
- AOP/SOP/etc
- OP/VOICE/etc
- INVITE, BAN, GETKEY, KICK
- MLOCK, TOPICLOCK, SECURE-BLAH, OPNOTICE
- A few channel modes (+Q, parts of +t and +ik)
Deliberate omissions
- CLEAR <channel> - masskick. I don't think it belongs in services; a module for the command may be useful.
- Autovoice of ALL nicks that enter -- this is pointless. Get a bot.
Database conversion
We need to convert from popular services current database format. This means password hashing has to be quite flexible.
Alternatively, have services authors add support for participating in the distributed database; this will allow people to use features such as BotServ that are best done on a dedicated services server, while still retaining functionality on a netsplit.
Module hook ideas
- Tie in with m_httpd and require a captcha for nick registration
- Tie in with a new m_smtpd for email auth
- Remember voice/devoice of nicks
