Open Bug 915159 Opened 12 years ago Updated 3 years ago

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

Categories

(Chat Core :: IRC, enhancement)

enhancement

Tracking

(Not tracked)

People

(Reporter: jsbruner, Unassigned)

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
(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 :)
Component: Instant Messaging → IRC
Product: Thunderbird → Chat Core
Version: unspecified → trunk
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.