computertech/techircd
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Added all of the existing code

Browse Source
This commit is contained in:
Colby Lipsett
2025-09-27 14:43:52 +01:00
commit 6772bfd842
58 changed files with 19587 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

32
docs/CHANGELOG.md Normal file
View File

@@ -0,0 +1,32 @@
# Changelog
All notable changes to TechIRCd will be documented in this file.
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
## [1.0.0] - 2025-07-30
### Added
- Initial release of TechIRCd
- Full IRC protocol implementation (RFC 2812 compliant)
- Advanced channel management with operator hierarchy
- Extended ban system with quiet mode support (~q:mask)
- Comprehensive operator features and SNOmasks
- User modes system with SSL detection
- Enhanced stability with panic recovery
- Real-time health monitoring and metrics
- Configuration validation and sanitization
- Graceful shutdown capabilities
- Flood protection with operator exemption
### Features
- Channel modes: +m +n +t +i +s +p +k +l +b
- User modes: +i +w +s +o +x +B +z +r
- Operator commands: KILL, GLOBALNOTICE, OPERWALL, WALLOPS, REHASH, TRACE
- SNOmasks: +c +k +o +x +f +n +s +d
- Extended ban types with quiet mode support
- Health monitoring with memory and goroutine tracking
- Comprehensive error handling and recovery systems
[1.0.0]: https://github.com/ComputerTech312/TechIRCd/releases/tag/v1.0.0

165
docs/CONNECTION_HANDLING.md Normal file
View File

@@ -0,0 +1,165 @@
# TechIRCd Connection Handling Improvements
## Overview
TechIRCd now features **robust connection handling** designed to handle real-world network conditions, client behaviors, and edge cases gracefully.
## Key Improvements
### 🛡️ **Robust Client Connection Handling**
#### **1. Comprehensive Error Recovery**
- **Panic Recovery**: All client handlers have panic recovery with detailed logging
- **Graceful Cleanup**: Proper resource cleanup even when connections fail
- **Connection Validation**: Validates connections and server state before processing
#### **2. Smart Timeout Management**
- **Registration Timeout**: 60 seconds for initial registration (configurable)
- **Read Timeouts**: 5 minutes for registered clients, 30 seconds during registration
- **Progressive Timeouts**: More lenient timeouts for new connections
#### **3. Enhanced Message Processing**
- **Binary Data Detection**: Detects and rejects non-text data
- **Size Limits**: Truncates oversized messages (512 bytes max)
- **Empty Line Handling**: Gracefully ignores empty lines
- **Encoding Validation**: Checks for valid IRC characters
#### **4. Intelligent Flood Protection**
- **Registration Leniency**: More generous limits during connection setup
- **Sliding Window**: Proper flood detection with time windows
- **Configurable Limits**: Respects server configuration settings
### 🔧 **Server Connection Management**
#### **1. Connection Limits**
- **Max Client Enforcement**: Rejects connections when server is full
- **Resource Protection**: Prevents server overload
- **Graceful Rejection**: Sends proper error message before closing
#### **2. Accept Error Handling**
- **Temporary Error Recovery**: Handles temporary network errors
- **Retry Logic**: Continues accepting after temporary failures
- **Error Classification**: Different handling for different error types
#### **3. Client State Tracking**
- **Connection Counting**: Real-time client count tracking
- **State Validation**: Ensures clients are properly initialized
- **Resource Monitoring**: Tracks and logs connection statistics
### 📊 **Enhanced Logging and Debugging**
#### **1. Detailed Connection Logging**
```
2025/09/03 19:02:44 New client connected from 46.24.193.29:60237 (total: 1)
2025/09/03 19:02:44 Starting robust client handler for 46.24.193.29:60237
2025/09/03 19:02:44 Client 46.24.193.29:60237: CAP LS 302
2025/09/03 19:02:44 Client 46.24.193.29:60237: NICK TestUser
2025/09/03 19:02:44 Client registration completed: TestUser (testuser) from 46.24.193.29:60237
```
#### **2. Error Context**
- **Connection Source**: Always logs client IP/port
- **Error Details**: Specific error messages for troubleshooting
- **State Information**: Logs registration status and timing
#### **3. Performance Metrics**
- **Connection Duration**: Tracks how long connections last
- **Message Counts**: Monitors message frequency
- **Registration Time**: Measures time to complete registration
### 🔒 **Security Enhancements**
#### **1. Protocol Validation**
- **Command Validation**: Ensures only valid IRC commands are processed
- **Data Sanitization**: Removes dangerous or malformed input
- **Buffer Management**: Prevents buffer overflow attacks
#### **2. Connection Security**
- **Rate Limiting**: Prevents rapid connection attempts
- **Resource Limits**: Protects against resource exhaustion
- **Input Validation**: Validates all client input before processing
### 🚀 **Real-World Compatibility**
#### **1. IRC Client Support**
- **HexChat Compatible**: Tested with popular IRC clients
- **IRCv3 Support**: Handles capability negotiation properly
- **Standard Compliance**: Follows RFC 2812 standards
#### **2. Network Conditions**
- **Slow Connections**: Handles high-latency connections
- **Unstable Networks**: Recovers from temporary network issues
- **Mobile Clients**: Optimized for mobile network conditions
#### **3. Edge Cases**
- **Partial Messages**: Handles incomplete message transmission
- **Connection Drops**: Graceful handling of sudden disconnections
- **Server Restarts**: Proper cleanup during server shutdown
## Configuration Options
### **Timeout Settings**
```json
{
"limits": {
"registration_timeout": 60,
"ping_timeout": 300,
"flood_lines": 10,
"flood_seconds": 60
}
}
```
### **Connection Limits**
```json
{
"limits": {
"max_clients": 1000,
"max_channels": 100
}
}
```
## Benefits
### **For Users**
- ✅ **Reliable Connections**: Less likely to drop due to network issues
- ✅ **Faster Registration**: Optimized registration process
- ✅ **Better Error Messages**: Clear feedback when issues occur
- ✅ **Mobile Friendly**: Works well on mobile networks
### **For Administrators**
- ✅ **Detailed Logging**: Easy troubleshooting with comprehensive logs
- ✅ **Resource Protection**: Server stays stable under load
- ✅ **Security**: Protection against malformed data and attacks
- ✅ **Monitoring**: Real-time connection statistics
### **For Developers**
- ✅ **Code Clarity**: Well-structured connection handling code
- ✅ **Error Recovery**: Robust error handling prevents crashes
- ✅ **Debugging**: Extensive logging for issue resolution
- ✅ **Maintainability**: Clean separation of concerns
## Testing Recommendations
### **Basic Connection Test**
```bash
# Test with telnet
telnet your-server.com 6667
# Send IRC commands
NICK TestUser
USER testuser 0 * :Test User
```
### **HexChat Configuration**
- **Server**: your-server.com
- **Port**: 6667 (or 6697 for SSL)
- **SSL**: Disabled (unless you have SSL configured)
- **Character Set**: UTF-8
### **Load Testing**
- Test with multiple simultaneous connections
- Try rapid connect/disconnect cycles
- Test with slow network conditions
TechIRCd now provides **enterprise-grade connection handling** suitable for production IRC networks!

65
docs/CONTRIBUTING.md Normal file
View File

@@ -0,0 +1,65 @@
# Contributing to TechIRCd
We love your input! We want to make contributing to TechIRCd as easy and transparent as possible.
## Development Process
We use GitHub to host code, to track issues and feature requests, as well as accept pull requests.
## Pull Requests
1. Fork the repo and create your branch from `main`.
2. If you've added code that should be tested, add tests.
3. If you've changed APIs, update the documentation.
4. Ensure the test suite passes.
5. Make sure your code lints.
6. Issue that pull request!
## Code Style
- Follow standard Go formatting (`gofmt`)
- Use meaningful variable and function names
- Add comments for exported functions and complex logic
- Keep functions focused and single-purpose
## Testing
```bash
# Run all tests
go test ./...
# Run tests with coverage
go test -cover ./...
# Run tests with race detection
go test -race ./...
```
## Commit Messages
- Use the present tense ("Add feature" not "Added feature")
- Use the imperative mood ("Move cursor to..." not "Moves cursor to...")
- Limit the first line to 72 characters or less
- Reference issues and pull requests liberally after the first line
## Bug Reports
**Great Bug Reports** tend to have:
- A quick summary and/or background
- Steps to reproduce
- What you expected would happen
- What actually happens
- Notes (possibly including why you think this might be happening)
## Feature Requests
We welcome feature requests! Please provide:
- Clear description of the feature
- Use case or motivation
- Possible implementation approach (if you have ideas)
## License
By contributing, you agree that your contributions will be licensed under the MIT License.

174
docs/ENHANCEMENT_ROADMAP.md Normal file
View File

@@ -0,0 +1,174 @@
# TechIRCd Enhancement Roadmap
## 🚀 Phase 1: Core Improvements (High Priority)
### 1.1 Missing IRC Commands (2-3 weeks)
- [ ] USERHOST command
- [ ] ISON command
- [ ] STATS command with detailed server statistics
- [ ] TIME command
- [ ] VERSION command
- [ ] ADMIN command
- [ ] INFO command
- [ ] LUSERS command
- [ ] Enhanced LIST with pattern matching
- [ ] SILENCE command for user-level blocking
### 1.2 Channel Mode Enhancements (1-2 weeks)
- [ ] Ban exceptions (+e mode)
- [ ] Invite exceptions (+I mode)
- [ ] Permanent channels (+P mode)
- [ ] Registered-only channels (+r mode)
- [ ] SSL-only channels (+z mode)
- [ ] Channel forwarding (+f mode)
- [ ] Founder protection mode (~q)
- [ ] Admin protection mode (&a)
### 1.3 Security & Authentication (2-3 weeks)
- [ ] SASL authentication support
- [ ] Certificate-based authentication
- [ ] Rate limiting per IP/user
- [ ] GeoIP blocking capabilities
- [ ] DDoS protection mechanisms
- [ ] Enhanced flood protection
- [ ] Connection throttling
## 🌐 Phase 2: Network & Scaling (Medium Priority)
### 2.1 Enhanced Server Linking (3-4 weeks)
- [ ] Burst optimization for large networks
- [ ] Network topology visualization
- [ ] Automatic failover and recovery
- [ ] Load balancing across servers
- [ ] Network-wide channel/user sync
- [ ] Cluster management interface
- [ ] Health monitoring between servers
### 2.2 Database Integration (2-3 weeks)
- [ ] SQLite/MySQL/PostgreSQL support
- [ ] User account persistence
- [ ] Channel registration system
- [ ] Network-wide ban storage
- [ ] Statistics logging
- [ ] Audit trail logging
- [ ] Data migration tools
### 2.3 Services Framework (4-5 weeks)
- [ ] NickServ implementation
- [ ] ChanServ implementation
- [ ] OperServ implementation
- [ ] MemoServ implementation
- [ ] BotServ implementation
- [ ] Services API framework
- [ ] Plugin system for custom services
## 📊 Phase 3: Advanced Features (Lower Priority)
### 3.1 Monitoring & Analytics (3-4 weeks)
- [ ] Prometheus metrics integration
- [ ] Grafana dashboard templates
- [ ] Real-time performance monitoring
- [ ] User activity analytics
- [ ] Channel analytics
- [ ] Alert system with notifications
- [ ] Performance profiling tools
- [ ] Capacity planning metrics
### 3.2 Web Interface (4-5 weeks)
- [ ] Administrative web panel
- [ ] REST API endpoints
- [ ] GraphQL query interface
- [ ] Real-time dashboard with WebSockets
- [ ] Mobile-responsive design
- [ ] User management interface
- [ ] Channel management interface
- [ ] Network topology viewer
- [ ] Log viewer and search
### 3.3 Modern Protocol Support (3-4 weeks)
- [ ] IRCv3 capabilities
- [ ] Message tags support
- [ ] Account tracking
- [ ] MONITOR command
- [ ] Extended JOIN
- [ ] CHGHOST support
- [ ] Batch processing
- [ ] Server-time capability
## 🎨 Phase 4: Quality of Life (Ongoing)
### 4.1 Developer Experience
- [ ] Comprehensive test suite (>80% coverage)
- [ ] CI/CD pipeline setup
- [ ] Automated security scanning
- [ ] Performance benchmarking
- [ ] Documentation improvements
- [ ] Code quality tools integration
- [ ] Dependency management
### 4.2 Deployment & Operations
- [ ] Docker containerization
- [ ] Kubernetes manifests
- [ ] Helm charts
- [ ] Configuration management
- [ ] Backup and restore tools
- [ ] Migration utilities
- [ ] Health check endpoints
### 4.3 Community Features
- [ ] Plugin architecture
- [ ] Extension API
- [ ] Custom command framework
- [ ] Event system
- [ ] Webhook integrations
- [ ] Third-party service connectors
## 🔧 Technical Debt & Improvements
### Code Structure
- [ ] Proper package structure (remove `package main` everywhere)
- [ ] Interface definitions for better testing
- [ ] Dependency injection framework
- [ ] Configuration validation improvements
- [ ] Error handling standardization
- [ ] Logging framework upgrade
### Performance Optimizations
- [ ] Connection pooling
- [ ] Message batching
- [ ] Memory optimization
- [ ] CPU profiling and optimization
- [ ] Network I/O improvements
- [ ] Concurrent processing enhancements
### Security Hardening
- [ ] Input validation improvements
- [ ] Buffer overflow protection
- [ ] Memory safety audits
- [ ] Cryptographic improvements
- [ ] Secure defaults
- [ ] Vulnerability scanning
## 📈 Implementation Timeline
**Total Estimated Time: 6-8 months**
- **Month 1-2**: Phase 1 (Core Improvements)
- **Month 3-4**: Phase 2 (Network & Scaling)
- **Month 5-6**: Phase 3 (Advanced Features)
- **Month 7-8**: Phase 4 (Quality of Life) + Polish
## 🎯 Quick Wins (Can implement immediately)
1. **USERHOST command** (1 day)
2. **ISON command** (1 day)
3. **TIME command** (1 day)
4. **VERSION command** (1 day)
5. **Enhanced LIST filtering** (2-3 days)
6. **Ban exceptions (+e mode)** (2-3 days)
7. **Invite exceptions (+I mode)** (2-3 days)
8. **Basic SASL PLAIN** (3-4 days)
9. **Prometheus metrics** (3-4 days)
10. **Basic web stats API** (2-3 days)
These improvements would make TechIRCd one of the most feature-complete and modern IRC servers available!

176
docs/GOD_MODE_STEALTH.md Normal file
View File

@@ -0,0 +1,176 @@
# God Mode and Stealth Mode
TechIRCd supports two advanced operator features via user modes:
## God Mode (+G)
God Mode gives operators ultimate channel override capabilities.
### Usage
```
/mode nickname +G # Enable God Mode
/mode nickname -G # Disable God Mode
```
### Capabilities
- **Channel Access**: Can join any channel regardless of bans, limits, keys, or invite-only status
- **Kick Immunity**: Cannot be kicked from channels by anyone, including other operators
- **Ban Immunity**: Can join and remain in channels even when banned
- **Invite Override**: Can join invite-only channels without being invited
- **Limit Override**: Can join channels that have reached their user limit
- **Key Override**: Can join channels with passwords/keys without providing them
### Requirements
- Must be an IRC operator (`/oper`)
- Must have `god_mode` permission in operator class configuration
- Only the user themselves can set/unset their God Mode
### Security Notes
- God Mode actions are logged to operator snomasks (`+o`)
- Use responsibly - this bypasses all normal channel protections
- Intended for emergency situations and network administration
## Stealth Mode (+S)
Stealth Mode makes operators invisible to regular users while remaining visible to other operators.
### Usage
```
/mode nickname +S # Enable Stealth Mode
/mode nickname -S # Disable Stealth Mode
```
### Effects
- **WHO Command**: Stealth users don't appear in `/who` results for regular users
- **NAMES Command**: Stealth users don't appear in channel user lists for regular users
- **Channel Lists**: Regular users can't see stealth operators in channels
- **Operator Visibility**: Other operators can always see stealth users
### Requirements
- Must be an IRC operator (`/oper`)
- Must have `stealth_mode` permission in operator class configuration
- Only the user themselves can set/unset their Stealth Mode
### Use Cases
- Undercover moderation and monitoring
- Reduced operator visibility during investigations
- Network administration without user awareness
## Configuration
Add permissions to operator classes in `configs/opers.conf`:
```json
{
"classes": [
{
"name": "admin",
"rank": 4,
"description": "Administrator with special powers",
"permissions": [
"*",
"god_mode",
"stealth_mode"
]
}
]
}
```
## Examples
### Basic Usage
```
# As an operator with god_mode permission:
/mode mynick +G
# *** GOD MODE enabled - You have ultimate power!
# Join a banned/invite-only channel:
/join #private-channel
# Successfully joins despite restrictions
# Disable God Mode:
/mode mynick -G
# *** GOD MODE disabled
# Enable Stealth Mode:
/mode mynick +S
# *** STEALTH MODE enabled - You are now invisible to users
# Regular users won't see you in:
/who #channel
/names #channel
# Other operators will still see you
```
### Combined Usage
```
# Enable both modes simultaneously:
/mode mynick +GS
# *** GOD MODE enabled - You have ultimate power!
# *** STEALTH MODE enabled - You are now invisible to users
# Now you can:
# - Join any channel (God Mode)
# - Remain invisible to regular users (Stealth Mode)
# - Be visible to other operators
```
### Permission Checking
```
# Attempting without proper permissions:
/mode mynick +G
# :server 481 mynick :Permission Denied - You need god_mode permission
# Must be oper first:
/mode mynick +S
# :server 481 mynick :Permission Denied- You're not an IRC operator
```
## Technical Implementation
### God Mode
- Stored as user mode `+G`
- Checked via `HasGodMode()` method
- Bypasses channel restrictions in:
- `JOIN` command (bans, limits, keys, invite-only)
- `KICK` command (cannot be kicked)
- Channel access validation
### Stealth Mode
- Stored as user mode `+S`
- Checked via `HasStealthMode()` method
- Filtered in:
- `WHO` command responses
- `NAMES` command responses
- Channel member visibility
### Mode Persistence
- User modes are stored per-client session
- Lost on disconnect/reconnect
- Must be re-enabled after each connection
## Security Considerations
1. **Audit Trail**: All God Mode and Stealth Mode activations are logged
2. **Permission Based**: Requires explicit operator class permissions
3. **Self-Only**: Users can only set modes on themselves
4. **Operator Level**: Requires existing operator privileges
5. **Reversible**: Can be disabled at any time
## Troubleshooting
### Mode Not Setting
- Verify you are opered (`/oper`)
- Check operator class has required permissions
- Ensure using correct syntax (`/mode nickname +G`)
### Not Working as Expected
- God Mode only affects channel restrictions, not other commands
- Stealth Mode only hides from regular users, not operators
- Modes are case-sensitive (`+G` not `+g`)
### Permission Denied
- Contact network administrator to add permissions to your operator class
- Verify operator class configuration in `configs/opers.conf`

122
docs/IRCV3_FEATURES.md Normal file
View File

@@ -0,0 +1,122 @@
# TechIRCd IRCv3 Features
## ✅ Implemented IRCv3 Features
### Core Capability Negotiation
- **CAP LS** - List available capabilities
- **CAP LIST** - List enabled capabilities
- **CAP REQ** - Request capabilities
- **CAP ACK/NAK** - Acknowledge/reject capability requests
- **CAP END** - End capability negotiation
### Supported Capabilities
#### IRCv3.1 Base
- ✅ **sasl** - SASL authentication (PLAIN mechanism)
- ✅ **multi-prefix** - Multiple channel prefixes (~@%+)
- ✅ **away-notify** - Away state change notifications
- ✅ **account-notify** - Account login/logout notifications
- ✅ **extended-join** - JOIN with account and real name
#### IRCv3.2 Extensions
- ✅ **server-time** - Timestamp tags on messages
- ✅ **userhost-in-names** - Full hostmasks in NAMES
- ✅ **monitor-notify** - MONITOR command for presence
- ✅ **account-tag** - Account tags on messages
- ✅ **message-tags** - IRCv3 message tag framework
#### IRCv3.3 Features
- ✅ **echo-message** - Echo sent messages back to sender
- ✅ **chghost** - Host change notifications
- ✅ **invite-notify** - Channel invite notifications
- ✅ **batch** - Message batching support
## 🚀 Usage Examples
### Basic Capability Negotiation
```
Client: CAP LS 302
Server: :server CAP * LS :account-notify away-notify extended-join multi-prefix sasl server-time userhost-in-names account-tag message-tags echo-message batch chghost invite-notify monitor-notify
Client: CAP REQ :server-time message-tags sasl
Server: :server CAP * ACK :server-time message-tags sasl
Client: CAP END
```
### SASL Authentication
```
Client: CAP REQ :sasl
Server: :server CAP * ACK :sasl
Client: AUTHENTICATE PLAIN
Server: AUTHENTICATE +
Client: AUTHENTICATE dXNlcm5hbWU6cGFzc3dvcmQ=
Server: :server 903 * :SASL authentication successful
Client: CAP END
```
### Server-Time Tags
```
@time=2025-08-28T17:01:49.123Z :nick!user@host PRIVMSG #channel :Hello!
```
### Account Tags
```
@account=alice;time=2025-08-28T17:01:49.123Z :alice!user@host PRIVMSG #channel :Hello!
```
### Extended JOIN
```
:nick!user@host JOIN #channel alice :Real Name
```
### MONITOR Command
```
Client: MONITOR + alice,bob,charlie
Server: :server 730 nick :alice,bob
Server: :server 731 nick :charlie
Client: MONITOR L
Server: :server 732 nick :alice,bob,charlie
Server: :server 733 nick :End of MONITOR list
```
## 🔧 Configuration
IRCv3 features are automatically available when clients request them through CAP negotiation. No special server configuration required.
### SASL Accounts
Currently supports simple username/password authentication. Edit the `authenticateUser()` function in `commands.go` to integrate with your authentication system.
## 🎯 Advanced Features
### Message Tags
TechIRCd automatically adds appropriate tags based on client capabilities:
- `time` - Server timestamp (if server-time enabled)
- `account` - User account name (if logged in and account-tag enabled)
### Multi-Prefix Support
Shows all user channel modes: `~@%+nick` for Owner/Op/Halfop/Voice
### Echo Message
When enabled, clients receive copies of their own messages, useful for multi-device synchronization.
## 🔮 Future IRCv3 Extensions
Planned for future releases:
- **draft/chathistory** - Message history replay
- **draft/resume** - Connection state resumption
- **labeled-response** - Request/response correlation
- **standard-replies** - Standardized error responses
## 💡 Client Compatibility
TechIRCd's IRCv3 implementation is compatible with:
- **HexChat** - Full feature support
- **IRCCloud** - Full feature support
- **Textual** - Full feature support
- **WeeChat** - Full feature support
- **KiwiIRC** - Full feature support
- **IRCv3-compliant bots** - Full API support
Legacy IRC clients without IRCv3 support continue to work normally without any IRCv3 features.

290
docs/LINKING.md Normal file
View File

@@ -0,0 +1,290 @@
# TechIRCd Server Linking
TechIRCd now supports IRC server linking, allowing multiple IRC servers to form a network. This enables users on different servers to communicate with each other seamlessly.
## Features
- **Server-to-Server Communication**: Full IRC protocol compliance for server linking
- **Hub and Leaf Configuration**: Support for hub/leaf network topologies
- **Auto-Connect**: Automatic connection to configured servers on startup
- **Operator Commands**: Manual connection and disconnection controls
- **Security**: Password-based authentication for server connections
- **Network Transparency**: Users can see and communicate across the entire network
## Configuration
Server linking is configured in the `config.json` file under the `linking` section:
```json
{
"linking": {
"enable": true,
"server_port": 6697,
"password": "linkpassword123",
"hub": false,
"auto_connect": false,
"links": [
{
"name": "hub.technet.org",
"host": "127.0.0.1",
"port": 6697,
"password": "linkpassword123",
"auto_connect": false,
"hub": true,
"description": "TechNet Hub Server"
}
]
}
}
```
### Configuration Options
- **enable**: Enable or disable server linking functionality
- **server_port**: Port to listen on for incoming server connections
- **password**: Default password for server authentication
- **hub**: Whether this server acts as a hub (can connect to multiple servers)
- **auto_connect**: Automatically attempt to connect to configured links on startup
- **links**: Array of server configurations to link with
### Link Configuration
Each link in the `links` array supports:
- **name**: Unique server name (should match the remote server's configured name)
- **host**: Hostname or IP address of the remote server
- **port**: Port number the remote server is listening on for server connections
- **password**: Authentication password (must match on both servers)
- **auto_connect**: Whether to automatically connect to this server
- **hub**: Whether the remote server is a hub server
- **description**: Human-readable description of the server
## Operator Commands
Operators can manually control server links using these commands:
### CONNECT
Connect to a configured server:
```
/CONNECT <servername> <port> [host]
```
Examples:
```
/CONNECT hub.technet.org 6697
/CONNECT hub.technet.org 6697 192.168.1.100
```
### SQUIT
Disconnect from a linked server:
```
/SQUIT <servername> [reason]
```
Examples:
```
/SQUIT hub.technet.org
/SQUIT hub.technet.org :Maintenance required
```
### LINKS
Show all connected servers:
```
/LINKS
```
This displays the network topology showing all connected servers.
## Network Topology
TechIRCd supports both hub-and-leaf and mesh network topologies:
### Hub-and-Leaf
```
[Hub Server]
/ | \
[Leaf1] [Leaf2] [Leaf3]
```
In this configuration:
- The hub server (`hub: true`) connects to multiple leaf servers
- Leaf servers (`hub: false`) only connect to the hub
- All inter-server communication routes through the hub
### Mesh Network
```
[Server1] --- [Server2]
| \ / |
| \ / |
[Server3] --- [Server4]
```
In this configuration:
- All servers can connect to multiple other servers
- Provides redundancy and multiple communication paths
- More complex but more resilient
## Server-to-Server Protocol
TechIRCd implements standard IRC server-to-server protocol commands:
- **PASS**: Authentication password
- **SERVER**: Server introduction and information
- **PING/PONG**: Keep-alive and lag detection
- **SQUIT**: Server quit/disconnect
- **NICK**: User nickname propagation
- **USER**: User information propagation
- **JOIN/PART**: Channel membership changes
- **PRIVMSG/NOTICE**: Message routing between servers
- **QUIT**: User disconnection notifications
## Message Routing
When servers are linked, messages are automatically routed across the network:
1. **User Messages**: Private messages and notices are routed to the correct server
2. **Channel Messages**: Broadcast to all servers with users in the channel
3. **User Lists**: WHO, WHOIS, and NAMES commands work across the network
4. **Channel Lists**: LIST shows channels from all linked servers
## Security Considerations
- **Passwords**: Always use strong, unique passwords for server links
- **Network Access**: Restrict server linking ports to trusted networks
- **Operator Permissions**: Only trusted operators should have CONNECT/SQUIT privileges
- **Link Validation**: Server names and passwords are validated before connection
## Troubleshooting
### Connection Issues
1. **Check Configuration**: Ensure server names, hosts, ports, and passwords match
2. **Network Connectivity**: Verify network connectivity between servers
3. **Firewall**: Ensure server linking ports are open
4. **Logs**: Check server logs for connection errors and authentication failures
### Common Error Messages
- `No link configuration found`: Server not configured in links array
- `Server already connected`: Attempted to connect to already linked server
- `Authentication failed`: Password mismatch between servers
- `Connection refused`: Network connectivity or firewall issues
### Debugging
Enable debug logging to see detailed server linking information:
```json
{
"logging": {
"level": "debug"
}
}
```
## Example Network Setup
Here's an example of setting up a 3-server network:
### Hub Server (hub.technet.org)
```json
{
"server": {
"name": "hub.technet.org"
},
"linking": {
"enable": true,
"server_port": 6697,
"hub": true,
"links": [
{
"name": "leaf1.technet.org",
"host": "192.168.1.101",
"port": 6697,
"password": "linkpass123",
"auto_connect": true,
"hub": false
},
{
"name": "leaf2.technet.org",
"host": "192.168.1.102",
"port": 6697,
"password": "linkpass123",
"auto_connect": true,
"hub": false
}
]
}
}
```
### Leaf Server 1 (leaf1.technet.org)
```json
{
"server": {
"name": "leaf1.technet.org"
},
"linking": {
"enable": true,
"server_port": 6697,
"hub": false,
"links": [
{
"name": "hub.technet.org",
"host": "192.168.1.100",
"port": 6697,
"password": "linkpass123",
"auto_connect": true,
"hub": true
}
]
}
}
```
### Leaf Server 2 (leaf2.technet.org)
```json
{
"server": {
"name": "leaf2.technet.org"
},
"linking": {
"enable": true,
"server_port": 6697,
"hub": false,
"links": [
{
"name": "hub.technet.org",
"host": "192.168.1.100",
"port": 6697,
"password": "linkpass123",
"auto_connect": true,
"hub": true
}
]
}
}
```
This creates a hub-and-leaf network where:
- The hub automatically connects to both leaf servers
- Leaf servers connect only to the hub
- Users on any server can communicate with users on other servers
- Channels span across all servers in the network
## Performance Considerations
- **Network Latency**: High latency between servers may affect user experience
- **Bandwidth**: Server linking uses additional bandwidth for message propagation
- **CPU Usage**: Message routing and protocol handling requires CPU resources
- **Memory Usage**: Additional memory is needed to track remote users and channels
## Future Enhancements
Planned improvements for server linking include:
- **Services Integration**: Support for network services (NickServ, ChanServ, etc.)
- **Channel Bursting**: Optimized channel synchronization
- **Network Statistics**: Detailed network topology and performance metrics
- **Load Balancing**: Intelligent routing for optimal performance
- **Redundancy**: Automatic failover and connection recovery

355
docs/OPERATOR_SYSTEM.md Normal file
View File

@@ -0,0 +1,355 @@
# Operator Configuration Guide
TechIRCd features a sophisticated hierarchical operator system with separate configuration files and granular permission control.
## Overview
The operator system consists of:
- **Operator Classes**: Define ranks, permissions, and inheritance
- **Individual Operators**: Specific users with assigned classes
- **Permission System**: Granular control over what operators can do
- **Rank Hierarchy**: Higher ranks can operate on lower ranks
## Configuration Files
### Main Config (`config.json`)
```json
"oper_config": {
"config_file": "configs/opers.conf",
"enable": true
}
```
### Operator Config (`configs/opers.conf`)
Contains the complete operator hierarchy and individual operator definitions.
## Operator Classes
### Customizable Rank Names
TechIRCd allows you to completely customize the names of operator ranks. Instead of using the standard Helper/Moderator/Operator names, you can create themed naming schemes:
```json
"rank_names": {
"rank_1": "Cadet", // Instead of "Helper"
"rank_2": "Sergeant", // Instead of "Moderator"
"rank_3": "Lieutenant", // Instead of "Operator"
"rank_4": "Captain", // Instead of "Administrator"
"rank_5": "General", // Instead of "Owner"
"custom_ranks": {
"Field Marshal": 6, // Custom ranks beyond 5
"Supreme Commander": 10
}
}
```
### Popular Naming Themes
#### Gaming/Military Theme
- Rank 1: `Cadet`, `Recruit`, `Private`
- Rank 2: `Sergeant`, `Corporal`, `Specialist`
- Rank 3: `Lieutenant`, `Captain`, `Major`
- Rank 4: `Colonel`, `General`, `Commander`
- Rank 5: `Admiral`, `Marshal`, `Supreme Commander`
#### Corporate/Business Theme
- Rank 1: `Intern`, `Assistant`, `Associate`
- Rank 2: `Specialist`, `Senior Associate`, `Team Lead`
- Rank 3: `Manager`, `Senior Manager`, `Department Head`
- Rank 4: `Director`, `VP`, `Executive`
- Rank 5: `CEO`, `President`, `Chairman`
#### Fantasy/Medieval Theme
- Rank 1: `Apprentice`, `Squire`, `Page`
- Rank 2: `Guardian`, `Warrior`, `Mage`
- Rank 3: `Knight`, `Paladin`, `Wizard`
- Rank 4: `Lord`, `Baron`, `Archmage`
- Rank 5: `King`, `Emperor`, `Divine Ruler`
#### Sci-Fi Theme
- Rank 1: `Ensign`, `Technician`, `Cadet`
- Rank 2: `Engineer`, `Pilot`, `Specialist`
- Rank 3: `Commander`, `Captain`, `Leader`
- Rank 4: `Admiral`, `Fleet Commander`, `Director`
- Rank 5: `Supreme Admiral`, `Galactic Emperor`, `AI Overlord`
### Built-in Classes (Default Names)
#### Helper (Rank 1)
- **Symbol**: `%`
- **Color**: Green
- **Permissions**: Basic moderation
- `kick` - Kick users from channels
- `topic` - Change channel topics
- `mode_channel` - Change channel modes
#### Moderator (Rank 2)
- **Symbol**: `@`
- **Color**: Blue
- **Inherits**: Helper permissions
- **Additional Permissions**:
- `ban` / `unban` - Manage channel bans
- `mute` - Mute users
- `mode_user` - Change user modes
- `who_override` - See hidden users in WHO
#### Operator (Rank 3)
- **Symbol**: `*`
- **Color**: Red
- **Inherits**: Moderator permissions
- **Additional Permissions**:
- `kill` - Kill user connections
- `gline` - Global bans
- `rehash` - Reload configuration
- `connect` / `squit` - Server linking
- `wallops` / `operwall` - Send operator messages
#### Administrator (Rank 4)
- **Symbol**: `&`
- **Color**: Purple
- **Permissions**: `*` (All permissions)
#### Owner (Rank 5)
- **Symbol**: `~`
- **Color**: Gold
- **Special Permissions**:
- `*` - All permissions
- `override_rank` - Can operate on same/higher ranks
- `shutdown` / `restart` - Server control
### Custom Classes
Create your own operator classes:
```json
{
"name": "security",
"rank": 3,
"description": "Security Officer - Network protection",
"permissions": [
"kill",
"gline",
"scan_network",
"access_logs"
],
"inherits": "moderator",
"color": "orange",
"symbol": "!"
}
```
## Individual Operators
### Basic Operator Definition
```json
{
"name": "alice",
"password": "secure_password_here",
"host": "*@trusted.example.com",
"class": "moderator",
"flags": ["extra_channels"],
"max_clients": 500,
"contact": "alice@example.com"
}
```
### Advanced Features
```json
{
"name": "bob",
"password": "another_secure_password",
"host": "admin@192.168.1.*",
"class": "admin",
"flags": ["debug_access", "special_channels"],
"max_clients": 1000,
"expires": "2025-12-31",
"contact": "bob@company.com",
"last_seen": "2025-07-30T10:30:00Z"
}
```
## Permission System
### Standard Permissions
#### Channel Management
- `kick` - Kick users from channels
- `ban` / `unban` - Manage channel bans
- `topic` - Change channel topics
- `mode_channel` - Change channel modes
- `mode_user` - Change user modes
#### User Management
- `kill` - Disconnect users
- `gline` - Global network bans
- `mute` - Silence users
- `who_override` - See hidden information
#### Server Management
- `rehash` - Reload configuration
- `connect` / `squit` - Server linking
- `wallops` / `operwall` - Operator communications
- `shutdown` / `restart` - Server control
#### Special Permissions
- `*` - All permissions (wildcard)
- `override_rank` - Ignore rank restrictions
- `debug_access` - Debug commands
- `log_access` - View server logs
### Custom Permissions
Add your own permissions for custom commands:
```json
"permissions": [
"custom_report",
"special_database_access",
"network_monitoring"
]
```
## Security Features
### Settings Configuration
```json
"settings": {
"require_ssl": true,
"max_failed_attempts": 3,
"lockout_duration_minutes": 30,
"log_oper_actions": true,
"notify_on_oper_up": true,
"auto_expire_inactive_days": 365,
"require_two_factor": false
}
```
### Security Options
- **SSL Requirement**: Force SSL for operator authentication
- **Failed Attempt Tracking**: Lock accounts after failed attempts
- **Action Logging**: Log all operator actions
- **Auto-Expiration**: Remove inactive operators
- **Two-Factor Authentication**: (Future feature)
## Rank System
### How Ranks Work
- **Higher numbers = Higher authority**
- **Same rank cannot operate on each other**
- **Override permission bypasses rank restrictions**
### Example Hierarchy
```
Owner (5) -> Can do anything to anyone
Admin (4) -> Can operate on Operator (3) and below
Operator (3) -> Can operate on Moderator (2) and below
Moderator (2) -> Can operate on Helper (1) and below
Helper (1) -> Can only operate on regular users
```
## WHOIS Integration
The operator system integrates with WHOIS to show:
- Operator status with custom symbols
- Class names and descriptions
- **Custom rank names** based on your configuration
- Permission levels
Example WHOIS output with custom rank names:
```
[313] alice is an IRC operator (moderator - Channel and user management) [Sergeant]
[313] bob is an IRC operator (captain - Senior officer with full authority) [Captain]
```
With fantasy theme:
```
[313] merlin is an IRC operator (lord - Ruler of vast territories) [Lord]
```
## Configuration Examples
### Quick Setup - Gaming Theme
```json
{
"rank_names": {
"rank_1": "Cadet",
"rank_2": "Sergeant",
"rank_3": "Lieutenant",
"rank_4": "Captain",
"rank_5": "General"
},
"classes": [
{
"name": "cadet",
"rank": 1,
"description": "New recruit with basic training",
"permissions": ["kick", "topic"],
"symbol": "+",
"color": "green"
}
]
}
```
See `/configs/examples/` for complete themed configurations:
- `opers-gaming-theme.conf` - Military/Gaming ranks
- `opers-corporate-theme.conf` - Business hierarchy
- `opers-fantasy-theme.conf` - Medieval/Fantasy theme
## Migration from Legacy
TechIRCd automatically falls back to the legacy operator system if:
- `oper_config.enable` is `false`
- The opers.conf file cannot be loaded
- No matching operator is found in the new system
Legacy operators get basic permissions and rank 1.
## Commands for Operators
### Checking Permissions
```
/WHOIS operator_name # See operator class and rank
/OPERLIST # List all operators (future)
/OPERHELP # Show operator commands (future)
```
### Management Commands
```
/OPER name password # Become an operator
/OPERWALL message # Send message to all operators
/REHASH # Reload configuration
```
## Best Practices
### Security
1. Use strong passwords for all operators
2. Restrict host masks to trusted IPs
3. Enable SSL requirement for sensitive ranks
4. Regularly audit operator lists
5. Set expiration dates for temporary operators
### Organization
1. Create classes that match your network structure
2. Use inheritance to avoid permission duplication
3. Document custom permissions clearly
4. Use descriptive class names and descriptions
5. Assign appropriate symbols and colors
### Maintenance
1. Review operator activity regularly
2. Remove inactive operators
3. Update permissions as needed
4. Monitor operator actions through logs
5. Keep opers.conf in version control
This operator system makes TechIRCd extremely flexible for networks of any size, from small communities to large networks with complex hierarchies!

161
docs/PROJECT_STRUCTURE.md Normal file
View File

@@ -0,0 +1,161 @@
# TechIRCd Enhanced Project Structure
## Current Structure Issues
- All packages use `package main` instead of proper names
- Missing comprehensive test coverage
- No CI/CD pipeline
- Limited documentation
- No deployment configurations
## Proposed Enhanced Structure
```
```
TechIRCd/
├── .github/ # GitHub-specific files
│ ├── workflows/ # GitHub Actions CI/CD
│ │ ├── ci.yml # Continuous Integration
│ │ ├── release.yml # Automated releases
│ │ └── security.yml # Security scanning
│ ├── ISSUE_TEMPLATE/ # Issue templates
│ │ ├── bug_report.md
│ │ ├── feature_request.md
│ │ └── question.md
│ └── PULL_REQUEST_TEMPLATE.md
├── api/ # API definitions (if adding REST API)
│ └── v1/
│ └── openapi.yaml
├── build/ # Build configurations
│ └── ci/
│ └── scripts/
├── cmd/ # Main applications
│ ├── techircd/ # Main server
│ │ └── main.go
│ ├── techircd-admin/ # Admin tool
│ │ └── main.go
│ └── techircd-client/ # Test client
│ └── main.go
├── configs/ # Configuration files
│ ├── config.json # Default config
│ ├── config.prod.json # Production config
│ └── config.dev.json # Development config
├── deployments/ # Deployment configurations
│ ├── kubernetes/
│ │ ├── namespace.yaml
│ │ ├── deployment.yaml
│ │ └── service.yaml
│ └── systemd/
│ └── techircd.service
```
├── docs/ # Documentation
│ ├── api/ # API documentation
│ ├── admin/ # Administrator guide
│ ├── user/ # User guide
│ ├── development/ # Development guide
│ └── examples/ # Usage examples
├── examples/ # Example configurations
│ ├── simple/
│ ├── production/
│ └── cluster/
├── internal/ # Private application code
│ ├── channel/
│ │ ├── channel.go
│ │ ├── channel_test.go
│ │ ├── modes.go
│ │ └── permissions.go
│ ├── client/
│ │ ├── client.go
│ │ ├── client_test.go
│ │ ├── auth.go
│ │ └── connection.go
│ ├── commands/
│ │ ├── commands.go
│ │ ├── commands_test.go
│ │ ├── irc.go
│ │ └── operator.go
│ ├── config/
│ │ ├── config.go
│ │ ├── config_test.go
│ │ └── validation.go
│ ├── database/ # Database layer (future)
│ │ ├── models/
│ │ └── migrations/
│ ├── health/
│ │ ├── health.go
│ │ ├── health_test.go
│ │ └── metrics.go
│ ├── protocol/ # IRC protocol handling
│ │ ├── parser.go
│ │ ├── parser_test.go
│ │ └── numerics.go
│ ├── security/ # Security features
│ │ ├── auth.go
│ │ ├── ratelimit.go
│ │ └── validation.go
│ └── server/
│ ├── server.go
│ ├── server_test.go
│ └── handlers.go
├── pkg/ # Public library code
│ └── irc/ # IRC utilities for external use
│ ├── client/
│ │ └── client.go
│ └── protocol/
│ └── constants.go
├── scripts/ # Build and utility scripts
│ ├── build.sh
│ ├── test.sh
│ ├── lint.sh
│ └── release.sh
├── test/ # Test data and utilities
│ ├── fixtures/ # Test data
│ ├── integration/ # Integration tests
│ │ └── server_test.go
│ ├── e2e/ # End-to-end tests
│ └── performance/ # Performance tests
├── tools/ # Supporting tools
│ └── migrate/ # Database migration tool
├── web/ # Web interface (future)
│ ├── static/
│ └── templates/
├── .editorconfig
├── .golangci.yml # Linter configuration
├── CHANGELOG.md
├── CODE_OF_CONDUCT.md
├── CONTRIBUTING.md
├── go.mod
├── go.sum
├── LICENSE
├── Makefile
├── README.md
└── SECURITY.md
```
## Implementation Priority
### Phase 1: Core Structure
1. Fix package declarations
2. Add proper test files
3. Create CI/CD pipeline
4. Add linting configuration
### Phase 2: Enhanced Features
1. Create admin tools
2. Add API endpoints
3. Implement database layer
4. Add monitoring tools
### Phase 3: Production Ready
1. Add monitoring
2. Create deployment configs
3. Add security scanning
4. Performance optimization
## Benefits of This Structure
1. **Professional**: Follows Go and open-source best practices
2. **Scalable**: Easy to add new features and maintain
3. **Testable**: Comprehensive testing at all levels
4. **Deployable**: Ready for production environments
5. **Maintainable**: Clear separation of concerns
6. **Community-friendly**: Easy for contributors to understand

58
docs/SECURITY.md Normal file
View File

@@ -0,0 +1,58 @@
# Security Policy
## Supported Versions
We currently support the following versions with security updates:
| Version | Supported |
| ------- | ------------------ |
| 1.0.x | :white_check_mark: |
## Reporting a Vulnerability
We take the security of TechIRCd seriously. If you believe you have found a security vulnerability, please report it to us as described below.
**Please do not report security vulnerabilities through public GitHub issues.**
Instead, please report them via email to: security@techircd.org (or the maintainer's email)
Please include the following information (as much as you can provide) to help us better understand the nature and scope of the possible issue:
- Type of issue (e.g. buffer overflow, SQL injection, cross-site scripting, etc.)
- Full paths of source file(s) related to the manifestation of the issue
- The location of the affected source code (tag/branch/commit or direct URL)
- Any special configuration required to reproduce the issue
- Step-by-step instructions to reproduce the issue
- Proof-of-concept or exploit code (if possible)
- Impact of the issue, including how an attacker might exploit the issue
This information will help us triage your report more quickly.
## Preferred Languages
We prefer all communications to be in English.
## Response Time
We will respond to your report within 48 hours and provide regular updates at least every 72 hours.
## Security Measures
TechIRCd implements several security measures:
- Input validation and sanitization
- Flood protection and rate limiting
- Connection timeout management
- Panic recovery mechanisms
- Memory usage monitoring
- Secure configuration validation
## Responsible Disclosure
We follow responsible disclosure practices:
1. **Report**: Submit vulnerability report privately
2. **Acknowledge**: We acknowledge receipt within 48 hours
3. **Investigate**: We investigate and develop a fix
4. **Coordinate**: We coordinate disclosure timeline with reporter
5. **Release**: We release security update and public disclosure

218
docs/SERVICES_INTEGRATION.md Normal file
View File

@@ -0,0 +1,218 @@
# Services Integration Guide
TechIRCd is designed to work with external IRC services packages like Anope, Atheme, or IRCServices. This document explains how to set up services integration.
## Supported Services Packages
### Recommended: Anope Services
- **Website**: https://www.anope.org/
- **Features**: NickServ, ChanServ, OperServ, MemoServ, BotServ, HostServ
- **Database**: MySQL, PostgreSQL, SQLite
- **Protocol**: Full IRCd linking support
### Alternative: Atheme Services
- **Website**: https://atheme.github.io/
- **Features**: NickServ, ChanServ, OperServ, MemoServ
- **Database**: Multiple backend support
- **Protocol**: Standard IRC linking
## TechIRCd Services Integration Features
### 1. Standard IRC Protocol Support
TechIRCd implements the standard IRC protocol that services packages expect:
- **Server-to-Server linking** (`linking.json` configuration)
- **Standard IRC commands** (NICK, JOIN, PART, PRIVMSG, etc.)
- **Operator commands** (KILL, SQUIT, STATS, etc.)
- **User and channel modes**
- **IRCv3 capabilities** for enhanced features
### 2. Services Connection Methods
#### Method A: Services as Linked Server (Recommended)
Configure services to connect as a linked server using the linking configuration:
```json
{
"linking": {
"enable": true,
"links": [
{
"name": "services.yourdomain.com",
"host": "127.0.0.1",
"port": 6697,
"password": "services-link-password",
"auto_connect": true,
"hub": false,
"class": "services"
}
],
"classes": {
"services": {
"recvq": 16384,
"sendq": 16384,
"max_links": 1
}
}
}
}
```
#### Method B: Services as Local Client
Services can also connect as regular IRC clients with special privileges.
### 3. Services User Modes
TechIRCd supports standard services user modes:
- `+S` - Service mode (identifies services bots)
- `+o` - IRC Operator mode
- `+B` - Bot mode
- `+r` - Registered user mode
### 4. Channel Modes for Services
- `+r` - Registered channel
- `+R` - Registered users only
- `+M` - Registered/voiced users only speak
- `+S` - Services bots only
## Anope Configuration Example
### anope.conf snippet:
```
uplink
{
host = "127.0.0.1"
port = 6667
password = "link-password"
}
serverinfo
{
name = "services.yourdomain.com"
description = "Services for TechNet"
}
networkinfo
{
networkname = "TechNet"
ircd = "techircd"
}
```
### TechIRCd linking.json for Anope:
```json
{
"linking": {
"enable": true,
"server_port": 6697,
"password": "link-password",
"links": [
{
"name": "services.yourdomain.com",
"host": "127.0.0.1",
"port": 6697,
"password": "link-password",
"auto_connect": false,
"hub": false,
"class": "services"
}
]
}
}
```
## Setup Instructions
### 1. Configure TechIRCd
1. Edit `configs/linking.json` to add services link
2. Set up linking passwords
3. Configure operator access for services management
### 2. Install Anope Services
```bash
# Download and compile Anope
wget https://github.com/anope/anope/releases/latest
tar -xzf anope-*.tar.gz
cd anope-*
./configure --prefix=/opt/anope
make && make install
```
### 3. Configure Anope
1. Edit `/opt/anope/conf/services.conf`
2. Set TechIRCd as the uplink server
3. Configure database settings
4. Set up services nicknames and channels
### 4. Start Services
```bash
# Start TechIRCd first
./techircd start
# Then start Anope services
/opt/anope/bin/anoperc start
```
## Services Protocol Support
TechIRCd supports the standard IRC server protocol features needed by services:
### User Management
- `NICK` - Nickname changes
- `USER` - User registration
- `QUIT` - User disconnection
- `KILL` - Force disconnect users
### Channel Management
- `JOIN/PART` - Channel membership
- `MODE` - Channel and user modes
- `TOPIC` - Channel topics
- `KICK/BAN` - Channel moderation
### Network Management
- `SQUIT` - Server disconnection
- `SERVER` - Server introduction
- `BURST` - Network state synchronization
- `STATS` - Server statistics
### Services-Specific
- `SVSNICK` - Services nickname enforcement
- `SVSMODE` - Services mode changes
- `SVSJOIN` - Services-forced joins
- `SVSPART` - Services-forced parts
## Troubleshooting
### Services Won't Connect
1. Check linking password in both configs
2. Verify port configuration
3. Check TechIRCd logs for connection attempts
4. Ensure services hostname resolves
### Services Commands Not Working
1. Verify services have operator status
2. Check services user modes (+S +o)
3. Review channel access levels
4. Check services configuration
### Database Issues
Services handle their own database - TechIRCd doesn't need database access.
## Benefits of External Services
### For TechIRCd:
- ✅ **Simplified codebase** - Focus on IRC protocol
- ✅ **Better performance** - No database overhead
- ✅ **Higher reliability** - Services crashes don't affect IRC
- ✅ **Easier maintenance** - Separate concerns
### For Users:
- ✅ **Mature services** - Anope/Atheme are battle-tested
- ✅ **Rich features** - Full services functionality
- ✅ **Database choice** - MySQL, PostgreSQL, SQLite
- ✅ **Web interfaces** - Many services offer web panels
## Getting Help
- **TechIRCd Support**: GitHub Issues
- **Anope Support**: https://www.anope.org/
- **Atheme Support**: https://atheme.github.io/
- **IRC Help**: #anope or #atheme on irc.anope.org

208
docs/WHOIS_CONFIGURATION.md Normal file
View File

@@ -0,0 +1,208 @@
# WHOIS Configuration Guide
TechIRCd provides extremely flexible WHOIS configuration that allows administrators to control exactly what information is visible to different types of users.
## Overview
The WHOIS system in TechIRCd uses a three-tier permission system:
- **to_everyone**: Information visible to all users
- **to_opers**: Information visible only to IRC operators
- **to_self**: Information visible when users query themselves
## Configuration Options
### Basic Information Controls
#### User Modes (`show_user_modes`)
Controls who can see what user modes (+i, +w, +s, etc.) a user has set.
```json
"show_user_modes": {
"to_everyone": false,
"to_opers": true,
"to_self": true
}
```
#### SSL Status (`show_ssl_status`)
Shows whether a user is connected via SSL/TLS.
```json
"show_ssl_status": {
"to_everyone": true,
"to_opers": true,
"to_self": true
}
```
#### Idle Time (`show_idle_time`)
Shows how long a user has been idle and their signon time.
```json
"show_idle_time": {
"to_everyone": false,
"to_opers": true,
"to_self": true
}
```
#### Signon Time (`show_signon_time`)
Shows when a user connected to the server (alternative to idle time).
```json
"show_signon_time": {
"to_everyone": false,
"to_opers": true,
"to_self": true
}
```
#### Real Host (`show_real_host`)
Shows the user's real IP address/hostname (bypasses host masking).
```json
"show_real_host": {
"to_everyone": false,
"to_opers": true,
"to_self": true
}
```
### Channel Information (`show_channels`)
Controls channel visibility with additional granular options:
```json
"show_channels": {
"to_everyone": true,
"to_opers": true,
"to_self": true,
"hide_secret_channels": true,
"hide_private_channels": false,
"show_membership_levels": true
}
```
- `hide_secret_channels`: Hide channels with mode +s from non-members
- `hide_private_channels`: Hide channels with mode +p from non-members
- `show_membership_levels`: Show @/+/% prefixes for ops/voice/halfop
### Operator Information (`show_oper_class`)
Shows IRC operator class/type information.
```json
"show_oper_class": {
"to_everyone": false,
"to_opers": true,
"to_self": true
}
```
### Client Information (`show_client_info`)
Shows information about the IRC client software being used.
```json
"show_client_info": {
"to_everyone": false,
"to_opers": true,
"to_self": false
}
```
### Account Name (`show_account_name`)
Shows services account name (for networks with services integration).
```json
"show_account_name": {
"to_everyone": true,
"to_opers": true,
"to_self": true
}
```
## Advanced Features (Future)
These features are planned for future implementation:
- `show_activity_stats`: User activity analytics
- `show_github_integration`: GitHub profile integration
- `show_geolocation`: Approximate location information
- `show_performance_stats`: Connection performance metrics
- `show_device_info`: Device and OS information
- `show_social_graph`: Mutual channels and connections
- `show_security_score`: Account security rating
## Custom Fields
TechIRCd supports custom WHOIS fields for maximum flexibility:
```json
"custom_fields": [
{
"name": "website",
"to_everyone": true,
"to_opers": true,
"to_self": true,
"format": "Website: %s",
"description": "User's personal website"
}
]
```
## Example Configurations
### Maximum Privacy
Only show basic information to everyone, detailed info to opers:
```json
"whois_features": {
"show_user_modes": {"to_everyone": false, "to_opers": true, "to_self": true},
"show_ssl_status": {"to_everyone": false, "to_opers": true, "to_self": true},
"show_idle_time": {"to_everyone": false, "to_opers": true, "to_self": true},
"show_real_host": {"to_everyone": false, "to_opers": true, "to_self": true},
"show_channels": {
"to_everyone": true, "to_opers": true, "to_self": true,
"hide_secret_channels": true, "hide_private_channels": true,
"show_membership_levels": false
}
}
```
### Maximum Transparency
Show most information to everyone:
```json
"whois_features": {
"show_user_modes": {"to_everyone": true, "to_opers": true, "to_self": true},
"show_ssl_status": {"to_everyone": true, "to_opers": true, "to_self": true},
"show_idle_time": {"to_everyone": true, "to_opers": true, "to_self": true},
"show_real_host": {"to_everyone": false, "to_opers": true, "to_self": true},
"show_channels": {
"to_everyone": true, "to_opers": true, "to_self": true,
"hide_secret_channels": false, "hide_private_channels": false,
"show_membership_levels": true
}
}
```
### Development/Testing
Show everything to everyone for debugging:
```json
"whois_features": {
"show_user_modes": {"to_everyone": true, "to_opers": true, "to_self": true},
"show_ssl_status": {"to_everyone": true, "to_opers": true, "to_self": true},
"show_idle_time": {"to_everyone": true, "to_opers": true, "to_self": true},
"show_real_host": {"to_everyone": true, "to_opers": true, "to_self": true},
"show_client_info": {"to_everyone": true, "to_opers": true, "to_self": true}
}
```
## Notes
- The WHOIS system respects IRC operator privileges and host masking settings
- Secret and private channel hiding works in conjunction with channel membership
- All settings are hot-reloadable (restart server after config changes)
- The system is designed to be extremely flexible while maintaining IRC protocol compliance
This configuration system makes TechIRCd one of the most configurable IRC servers available!