Autore: PUOJACKZ Data: 2005-11-09 Modificato: 2005-11-12 Letture: 470 Torna indietro

1. Introduzione

Oggigiorno, esistono molte reti IRC al mondo, che seguono varie politiche di gestione ed amministrazione. Alcune seguono di più il protocollo IRC (RFC 1459), rispettando il più possibile tali regole, mentre altre han introdotto delle innovazioni. La più chiara tra queste modifiche è la presenza del NetWork Service.

2. Sì, ma creare un IRCd che non rispetta il protocollo, può comportare dei problemi?E riguardo l'RFC?

Beh, prima di tutto, iniziamo spiegando una cosa: il protocollo IRC non è un regolamento al cui non ci si può sottrarre, o si rischia la pena capitale. No, assolutamente. E' solo una serie di regole "pubbliche". Ovviamente, se le si segue, tutti i dispositivi e i programmi creati basandosi su questa serie d'idee, saran compatibili. Se si decide di far di testa propria, magari creando un nuovo protocollo, proprio, occorrerà anche tener in considerazione che, probabilmente, i clients IRC più conosciuti non riusciranno a connettersi o a formattare il testo o i comandi in modo corretto.
Tutto ciò potrebbe avere un effetto negativo sulla popolarità della rete.
Ad esempio, se quando effettuo il comando /JOIN #Canale, su una rete IRC che supporta un IRCd particolare, al posto di entrare nel canale specificato, ci ESCO (e viceversa), il caos che si verrà a creare sarà un deterrente decisivo, e, sicuramente, tutti gli utenti che utilizzano degli scripts o dei programmi, ove il comando JOIN è impiegato per entrare nel canale, avranno dei problemi a chattare in tale rete.
Occorre, però, non lasciarsi spaventare dalle nuove implementazioni non regolamentari.
Ad esempio, DALnet ha portato la lunghezza dei nicknames, da 9 caratteri, a 30. Questo non ha pregiudicato minimamente il funzionamento dei clients, ed, infatti, anche se non è stato rispettato lo standard, i clients più famosi non han avuto problemi di compatibilità.

2.1 Scusa, ma vi sarà un motivo chiaro e plausibile del perchè alcune reti han deciso di non seguire il protocollo?

Qui s'inizia ad addentrarsi nella politica di amministrazione delle reti IRC.
Ad esempio, il ban globale. Undernet ha deciso per la G:Line, mentre DALnet ha introdotto l'Akill. Chiunque, ora, potrebbe chiedersi "Perchè?", infatti, alla fin fine, hanno lo stesso effetto, cioè bannano un utente da tutta la rete.
Su questo particolare non vi son dubbi, ma la G:Line dev'essere impostata da almeno 3 IRCOp della rete ed è a durata SEMPRE temporanea (es. anche 2 anni di durata, ma è temporanea). L'AKill, invece, viene settata dai servizi e può allontanare un host/IP/Sito/Regione permanentemente. La differenza è stata decisa dall'amministrazione.
Evidentemente, sia per Undernet che per DALnet, occorreva ideare un sistema per allontanare, da tutti i server della rete, un host sorgente di abusi. Su IRCNet, ad esempio, nell'IRCd 2.10 (senza patch), di alcuni anni fà, non vi era il ban globale. Ultimamente han introdotto la Global Kline, che è un'altra versione di ban. Produce lo stesso effetto della G:line e AKill, ma cambiano alcune particolarità. IRCNet, ad esempio, ha preferito utilizzare comunque la K:Line per mantener fuori un host, piuttosto che aggiungere una stringa a tale scopo.
Per concludere, l'importanza dell'aggiunta di un opzione o di una feature, non è detto che venga condiviso da tutte le reti IRC esistenti. Ogniuna decide autonomamente.

2.2 Ok, ma le implementazioni apportate da UnderNet, DALnet ecc... han avuto un importanza fondamentale?

Beh, DALnet introdusse le U:Line, in modo da garantire la possibilità, ai services, di modificare la rete senza che le routine di resynch annullassero gli effetti.
Ovviamente, anche in questo caso, l'importanza delle modifiche è strettamente legata alle idee dell'amministrazione (le quali potrebbero non essere condivise da tutti).

3. I Pro & I Contro dei services

Qui di seguito verran descritti i pro e i contro generici nell'avere i services nella propria rete IRC.

3.1 Perchè avere i services?

- Vi son 2 problemi nelle reti IRC, le collisioni e i TakeOvers. Grazie al ChanServ e al NickServ, un utente può essere sicuro che la propria identità e la propria stanza siano sempre, a lui disponibili, senza dover partecipare a guerre di canale, che spesso conducono a DoS non solo degli utenti, ma anche dei servers, trasformando la rete IRC in un campo di battaglia.

- Rende totalmente inutile lo sfruttare gli splits (il più delle volte indotti), per ottenere lo status di ChanOp in un canale, in quanto, i services, durante la fase di NetHealing, ripristinano le modalità originarie del canale, deoppando chi non è presente nelle liste ufficiali.

- Evita che il canale sia insediato da centinaia di bots, per il mantenimento dello status di moderazione. Inoltre, la mancanza della botnet evita che i chanop finiscano vittima delle misconfigurazioni contro il flood di canale.

- Permette la conservazione delle identità/canali, aggiungendo a queste ulteriori opzioni di gestione, oltre ad informazioni riguardo il suo possessore. Nelle reti senza services, per inserire alcuni dati del canale (es. se è di una community), occorre occupare lo spazio del Topic, che, secondo l'RFC è destinato per descrivere l'argomento di discussione.

- Garatisce l'uso del chan/nick a chi lo ha registrato, anche se un utente estraneo lo stà momentaneamente impegnando, richiedendo la liberazione forzata. Questo evita che un harraser possa utilizzare il nickname per screditare il vero possessore. Inoltre, non richiede il collegamento di bots che conservino il nickname, durante i periodi di assenza del suo utilizzatore ufficiale. Nelle reti senza Services, un utente può non solo usurpare l'identità di un utente, per causare problemi, ma anche spacciarsi per IRCOp.

- E' possibile collegarlo alle liste di canale del ChanServ, in modo che solo l'utente originale può ottenere gli status nei canali ove ha accesso. Questo evita i TakeOvers. Nelle reti senza Services, una volta che il canale ha perso tutti i suoi operatori, non è più possibile riprendere lo status di moderatore, lasciando il canale in completa balia dei flooders.

- Fornisce, a volte, degli strumenti per rilasciare delle note o dei memo, agli utenti registrati. Questa opzione è molto utile per avvertire gli utenti non correntemente online, riguardo un qualsiasi evento, senza attendere che questo ritorni attivo.

3.2 Perchè non avere i services?

- Ogni rete è indipendente e differente. Se tutte quante avessero le stesse opzioni e feautres, non avrebbe senso l'essere divise.

- Per evitare i TakeOvers, alcune reti implementano l'HalfOp, pertanto, il rischio di perdita di controllo del canale si riduce.

- Alcune reti, come EfNet ed IRCnet, hanno già pensato se fosse opportuno implementare dei servizi di registrazione. Purtroppo, però, non è detto che tutti sarebbero d'accordo con tale idea. Inoltre, sarebbe ancora più duro, successivamente, stabilire di chi è un canale o un nickname. Ad esempio, se il servizio viene attivato il giorno in cui tu non ci sei e qualcuno registra il tuo nickname, tu non lo puoi più usare. Stesso discorso per i canali.

- La registrazione toglie la possibilità di libertà. I canali vengono registrati, e così i nicknames, pertanto, non vi è più la regola del "Chi prima arriva meglio alloggia". Inoltre, gli IRCOps possono modificare arbitrariamente i dati delle identità, dando o togliendo la possessione dei canali/nicks. Nelle reti senza registrazione, gli operatori, simili privilegi, non ne hanno e quindi non l'utente è libero di aprire tutti i canali che vuole e svolgendo qualsiasi attività desideri.
 
- La registrazione diminuisce la responsabilità in canale, pertanto, gli operatori possono anche gestire la chat in modo errato. Qualora questa venga resa inutilizzabile, il ChanServ ripristina le modalità come se nulla fosse accaduto. In una rete senza services, quando sbagli a fornire uno status e il canale cade in TakeOver, chi ha mancato d'attenzione impara la lezione ed evita di ricommettere lo stesso sbaglio in futuro.

- Gli IRCOps/Admins possono ottenere status di canale, senza che sia un moderatore a fornirglieli. Nelle reti IRC ove OperServ non è presente, gli IRCOps non possono ottenere la modalità ChanOp, se non è un operatore di canale ad offrirgliela.

- L'uso dei canali, a volte, è impossibilitato senza un valido motivo (es. senza che vi siano bans all'interno o flags), da parte dei Services, in quanto, gli IRCOps han bloccato l'uso di questo. Nelle reti IRC senza services, nessuno può bloccare l'uso di un canale, se non carica, a suo interno, dei bots, con status moderatore.