IRC - Implement a ghost command that ghosts a user and then switches your nick to that name.

NEW
Unassigned

Status

Chat Core
IRC
--
enhancement
4 years ago
3 years ago

People

(Reporter: JosiahOne, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Say you have two computers.

Computer A nick = SomeUsername

Then later you go to Computer B and try to connect, obviously you can't, so you have:

Computer B nick = SomeUsername1

Using '/msg nickserv ghost SomeUsername password' from Computer B will cause SomeUsername to disconnect, but then immediately reconnect because of how we handle disconnects.

We are assuming the user was randomly disconnected, which isn't true. Instead we should handle a ghost leave by not reconnecting at all.
(In reply to Josiah Bruner [:JosiahOne] from comment #0)
> We are assuming the user was randomly disconnected, which isn't true.
> Instead we should handle a ghost leave by not reconnecting at all.

This isn't really what I suggested on IRC, I suggested adding a ghost command which would automatically tell nickserv to ghost a nickname and change your nick. Since the messages would be sent immediately following each other, we should be able to capture the nick before the other machine reconnects.

I really doubt there's a way to tell you were ghosted without looking at the text inside of the ERROR response, which is freetext and not speced out.
(In reply to Patrick Cloke [:clokep] from comment #1)
> (In reply to Josiah Bruner [:JosiahOne] from comment #0)
> > We are assuming the user was randomly disconnected, which isn't true.
> > Instead we should handle a ghost leave by not reconnecting at all.
> 
> This isn't really what I suggested on IRC, I suggested adding a ghost
> command which would automatically tell nickserv to ghost a nickname and
> change your nick. Since the messages would be sent immediately following
> each other, we should be able to capture the nick before the other machine
> reconnects.
> 
> I really doubt there's a way to tell you were ghosted without looking at the
> text inside of the ERROR response, which is freetext and not speced out.

Hmm... Well that's a bummer. Simply not reconnecting would be much more elegant, but in that case I'll change the bug.

The idea I guess would be:

"/msg nickserv ghost take Username password"

Is that a valid syntax Patrick?
Summary: iRC - Don't reconnect the account after a ghost command is used from another machine. → IRC - Implement a ghost command that ghosts a user and then switches your nick to that name.
(In reply to Josiah Bruner [:JosiahOne] from comment #2)
> (In reply to Patrick Cloke [:clokep] from comment #1)
> > (In reply to Josiah Bruner [:JosiahOne] from comment #0)
> > > We are assuming the user was randomly disconnected, which isn't true.
> > > Instead we should handle a ghost leave by not reconnecting at all.
> > 
> > This isn't really what I suggested on IRC, I suggested adding a ghost
> > command which would automatically tell nickserv to ghost a nickname and
> > change your nick. Since the messages would be sent immediately following
> > each other, we should be able to capture the nick before the other machine
> > reconnects.
> > 
> > I really doubt there's a way to tell you were ghosted without looking at the
> > text inside of the ERROR response, which is freetext and not speced out.
> 
> Hmm... Well that's a bummer. Simply not reconnecting would be much more
> elegant, but in that case I'll change the bug.
In which case it'll immediately get closed as WONTFIX. :) Reconnecting is a must have for instant messaging.

> The idea I guess would be:
> 
> "/msg nickserv ghost take Username password"
> 
> Is that a valid syntax Patrick?
I'm not sure what you're proposing here at all...what I'm saying we should do is add a ghost command:
/ghost <username to ghost> <password>
This would then send
NickServ GHOST <username> <password>\r\n
NICK <username>\r\n

Comment 4

4 years ago
(In reply to Josiah Bruner [:JosiahOne] from comment #0)
> Say you have two computers.
> 
> Computer A nick = SomeUsername
> 
> Then later you go to Computer B and try to connect, obviously you can't, so
> you have:
> 
> Computer B nick = SomeUsername1
> 
> Using '/msg nickserv ghost SomeUsername password' from Computer B will cause
> SomeUsername to disconnect, but then immediately reconnect because of how we
> handle disconnects.
> 
> We are assuming the user was randomly disconnected, which isn't true.
> Instead we should handle a ghost leave by not reconnecting at all.

I'm not sure I understand what you think the problem is exactly. Is the issue that you want to make computer A disconnect remotely, or that sending the ghost command on computer B fails to acquire the desired nick?
(In reply to Patrick Cloke [:clokep] from comment #3)
> (In reply to Josiah Bruner [:JosiahOne] from comment #2)
> > (In reply to Patrick Cloke [:clokep] from comment #1)
> > > (In reply to Josiah Bruner [:JosiahOne] from comment #0)
> > > > We are assuming the user was randomly disconnected, which isn't true.
> > > > Instead we should handle a ghost leave by not reconnecting at all.
> > > 
> > > This isn't really what I suggested on IRC, I suggested adding a ghost
> > > command which would automatically tell nickserv to ghost a nickname and
> > > change your nick. Since the messages would be sent immediately following
> > > each other, we should be able to capture the nick before the other machine
> > > reconnects.
> > > 
> > > I really doubt there's a way to tell you were ghosted without looking at the
> > > text inside of the ERROR response, which is freetext and not speced out.
> > 
> > Hmm... Well that's a bummer. Simply not reconnecting would be much more
> > elegant, but in that case I'll change the bug.
> In which case it'll immediately get closed as WONTFIX. :) Reconnecting is a
> must have for instant messaging.
> 
> > The idea I guess would be:
> > 
> > "/msg nickserv ghost take Username password"
> > 
> > Is that a valid syntax Patrick?
> I'm not sure what you're proposing here at all...what I'm saying we should
> do is add a ghost command:
> /ghost <username to ghost> <password>
> This would then send
> NickServ GHOST <username> <password>\r\n
> NICK <username>\r\

Now I'm confused. Don't we want some separate command/argument for this? What if we just want to ghost a user and not take their nick? Your suggestion appears to remove this ability.

(In reply to aleth from comment #4)
> (In reply to Josiah Bruner [:JosiahOne] from comment #0)
> > Say you have two computers.
> > 
> > Computer A nick = SomeUsername
> > 
> > Then later you go to Computer B and try to connect, obviously you can't, so
> > you have:
> > 
> > Computer B nick = SomeUsername1
> > 
> > Using '/msg nickserv ghost SomeUsername password' from Computer B will cause
> > SomeUsername to disconnect, but then immediately reconnect because of how we
> > handle disconnects.
> > 
> > We are assuming the user was randomly disconnected, which isn't true.
> > Instead we should handle a ghost leave by not reconnecting at all.
> 
> I'm not sure I understand what you think the problem is exactly. Is the
> issue that you want to make computer A disconnect remotely, or that sending
> the ghost command on computer B fails to acquire the desired nick?

The main *problem* is that sending a ghost command from Computer B to a nick on Computer A causes Computer A's nick to disconnect for less than a second. Thereby making changing your nick on Computer B to that name almost impossible.

I figured if there was some way to detect a disconnect via a ghost command, we could handle it by not reconnecting at all. In other words I thought if possible we should do:

Computer B (name1) sends '/ghost name password'

Computer A (name) recieves a disconnect and detects it as a ghost command. In which case it doesn't reconnect.

According to Patrick though, such a detection isn't possible, in which case I think we may want a new "Ghost and steal" command.

However, Patrick's suggestion (if I'm understanding this correctly) is to alter the existing ghost command to both ghost a user AND switch your nick to that user's name simultaneously. I expressed my thoughts to that above.

Sorry if this is confusing, but if you haven't figured it out yet, my knowledge of IRC is quite low :)

Updated

3 years ago
Component: Instant Messaging → IRC
Product: Thunderbird → Chat Core
Version: unspecified → trunk
You need to log in before you can comment on or make changes to this bug.