Poter usare NickServ usando un nick differente

[Dracoo]

Salve!
Volevo proporre di poter permettere ad un utente con il nick X, identificato anche al nick Y, di modificare le impostazione del nick Y senza doverlo "indossare", usando ad esempio

/ns set Y noop on
/ns listchans Y
/ns remove Y #chan
/ns access Y add|del|list|wipe [mask]
É fattibile?

[Steve]

Salve!
Volevo proporre di poter permettere ad un utente con il nick X, identificato anche al nick Y, di modificare le impostazione del nick Y senza doverlo "indossare", usando ad esempio

/ns set Y noop on
/ns listchans Y
/ns remove Y #chan
/ns access Y add|del|list|wipe [mask]
É fattibile?

Per un Help Operator e' gia' disponibile /ns listchans nickname, per controllare in quali canali abbia accesso un dato nickname.
Inoltre, il REMOVE e' un comando di ChanServ :P

Per gli altri casi, la terza parola completa il comando da lanciare per conto del nick utilizzato, quindi credo proprio che l'unica modifica proponibile e' di forzare l'inserimento del nick in quella parte di comando, cosa che quindi andrebbe fatta anche a nick utilizzato. Tutto sommato, mi sembra una soluzione peggiore del male...
Per questa ragione, nonche' per un mio parere personale, credo che sia meglio lasciar le cose come stanno.

[Dracoo]

Mmm... effettivamente per il SET, il REMOVE e l'ACCESS (ma anche il REMOVE di ChanServ :P) la parola cui precedono è una parola chiave (per esempio se uno avesse il nick DEL oppure ADD ci sarebbero dei casini!), perciò si potrebbe far si che il nick possa venire specificato come ultima parola ^_^
Ovvero:

/ns set parametro on|off|email|url|ecc [Nick]
/ns access add|del|wipe mask [Nick]
/ns access list [Mask] [Nick] (questo caso è un po' strano, però il nick non può venire confuso con la mask in quanto la mask deve avere per forza il @, carattere non permesso nei nick!)
/CS remove #canale [Nick]

Uh?

[Steve]

A parte il fatto che non devi essere obbligato a proporre una modifica su tutti i comandi esistenti... :)
Io comunque resto della mia idea: se hai un secondo nick e ti identifichi ad esso, non e' un grande problema fare /nick quelnick e settarsi quel che serve. Puo' essere un grande problema invece fare quel che chiedi, specie per NickServ che deve farsi un po' di controllini per capire se ti sei identificato o no.
Nel complesso direi che il male minore e' restare come siamo adesso.

[Dracoo]

A parte il fatto che non devi essere obbligato a proporre una modifica su tutti i comandi esistenti... :)
Io comunque resto della mia idea: se hai un secondo nick e ti identifichi ad esso, non e' un grande problema fare /nick quelnick e settarsi quel che serve. Puo' essere un grande problema invece fare quel che chiedi, specie per NickServ che deve farsi un po' di controllini per capire se ti sei identificato o no.
Nel complesso direi che il male minore e' restare come siamo adesso.I controllini NickServ li fa già per altri comandi (fai /ns info Nick ti un nick diverso da quello che stai usando, ma a cui sei identificato, ti va vedere l'indirizzo email di autorizzazione), perciò la funzione non serve crearla, in quanto già esistente.
Perciò, una soluzione possibile è (ad es per il comando SET NOWELCOME)

SE ($1 == "SET") {
SE ($2 == "NOWELCOME") {
SE ($3 == "ON") {
SE ($4 != "NULL" && $autorizzato($nic,$4) == 1)
attiva($4,NOWELCOME)
ALTRIMENTI
attiva($nick,NOWELCOME)
}
ALTRIMENTI {
SE ($4 != "NULL" && $autorizzato($nick,$4) == 1)
disattiva($4,NOWELCOME)
ALTRIMENTI
disattiva($nick,NOWELCOME)
}
[...]
}
}
Dove $autorizzato è una funzione che controlla se il nick è autorizzato al nick a cui chiede di settare il NOWELCOME (funzione evidentemente già esistente).
Di sicuro ci sono altri controlli (tipo per capire se il nick, in caso voglia lanciare il comando su sè stesso, se è autorizzato o meno, se il nick è registrato ecc ecc ecc)

[Koper]

Mettendo da parte che i servizi non sono scritti in mircscript fortunatamente e che quindi e' una roba diversa.. Io non uso /ns set da quando sono stati aggiornati i servizi includendo l'opzione nochanmemo.. Quindi non vedo tutta questa utilità. Piuttosto sarebbe bello aggiungere /ms read numero nick, /ms list nick, and so on.

[Dracoo]

Mettendo da parte che i servizi non sono scritti in mircscript fortunatamente e che quindi e' una roba diversa.. Io non uso /ns set da quando sono stati aggiornati i servizi includendo l'opzione nochanmemo.. Quindi non vedo tutta questa utilità. Piuttosto sarebbe bello aggiungere /ms read numero nick, /ms list nick, and so on.
Mai detto che i services sono scritti in MircScripting (ovviamente sono scritti in un linguaggio di programmazione, penso C/C++).
Non avevo pensato a MemoServ, ma devo dire che sarebbe utile anche quello!

[Raynk]

Io sinceramente sarei favorevole all'introduzione del parametro "nick" nel listchans di NickServ, in quanto spesso può capitare di non voler cambiare nick, ma allo stesso tempo di voler visualizzare i canali cui si ha accesso. Prendendo spunto dal fatto che, come ha detto sopra Steve, per gli HelpOp è già disponibile, è chiaro che NickServ effettui un controllo su colui che esegue il comando, in quanto se non si ha accesso a sufficienza ritorna "Accesso Negato"... un controllo per vedere se l'utente è o meno identificato al nick sul quale esegue il listchans tutto sommato non è che sia una catastrofe :)

[Steve]

Io sinceramente sarei favorevole all'introduzione del parametro "nick" nel listchans di NickServ, in quanto spesso può capitare di non voler cambiare nick, ma allo stesso tempo di voler visualizzare i canali cui si ha accesso. Prendendo spunto dal fatto che, come ha detto sopra Steve, per gli HelpOp è già disponibile, è chiaro che NickServ effettui un controllo su colui che esegue il comando, in quanto se non si ha accesso a sufficienza ritorna "Accesso Negato"...
Non posso affermarlo con precisione, ma nell'esecuzione del listchans non si va a verificare l'identificazione ad un nickname specifico, ma si verifica la presenza dell'accesso a livello di servizi (lo usermode +h per intenderci).
In ogni caso, essendo gia' possibile un'identificazione ad un nick senza doverlo per forza cambiare, aggiungere ulteriori funzionalita' di - chiamiamola cosi' - gestione remota di un nick, secondo me non e' positivo ed alla lunga puo' portare all'abuso di registrazione per determinati nick che non verrebbero invece effettivamente utilizzati.
Esiste poi un limite preciso al numero di canali presenti nel proprio listchans, cioe' 40, a fronte di "soli" 15 canali joinabili contemporaneamente: raggruppare in qualche modo gli accessi di piu' nick puo' portare all'invalidazione del primo limite, e se anche ci si volesse clonare per avere la possibilita' di seguire altri 15 canali, in ogni caso bisognerebbe usare un secondo nick, magari registrato e quindi con le sue specifiche caratteristiche ed accessi.