marking as neeeding ui-review.

I'm skeptical about the feasibility of this.

It is one thing to parse fixed commands like register/identify and offer to save a password that we can use to authenticate when connecting, but trying to make sense of "random" bot output is a whole different story - commands cannot be changed without breaking tons of documentation, but messages can easily differ between different implementations/versions ("This nick is registered." "'fmuellner' is a registered nick.", ""fmuellner" is a registered nick.", ...)

(I've nicked the "normal" popover for bug 760872 though)

Created attachment 319837 [details]
less intelligent mockup of nickname handling

Did a mockup that makes less assumptions about anything. It's slightly concerning that we can't really know whether identifying succeeded or registration succeeded - I wonder if SASL would help in any of this.

(In reply to Bastian Ilsø from comment #3)
> Did a mockup that makes less assumptions about anything. 

It makes *tons* of assumptions. Let's take this example:
 - you are connected to irc.example.com
 - you are joined to rooms #foo, #bar and have
   private conversations with baz and quz
 - is your nick registered? do you need to identify?

Unless you have *some* idea how to answer those questions from the information before (and *only* that information), I don't see how those mockups would be implemented.

Created attachment 319902 [details]
polari nick name identification rev 4

(In reply to Florian Müllner from comment #4)
> It makes *tons* of assumptions. Let's take this example:
>  - you are connected to irc.example.com
>  - you are joined to rooms #foo, #bar and have
>    private conversations with baz and quz
>  - is your nick registered? do you need to identify?
> 
> Unless you have *some* idea how to answer those questions from the
> information before (and *only* that information), I don't see how those
> mockups would be implemented.

ah, I'm misunderstanding the level of support we're intending to provide here.
So if I understand you right, you're saying it's not viable to ask the user to read messages from NickServ and provide UI for the commands it's asking the user to use for replying.

The iteration I'm attaching now is keeping NickServ handling on fringe-feature level and just offering to store the password.

(In reply to Bastian Ilsø from comment #5)
> So if I understand you right, you're saying it's not viable to ask the user
> to read messages from NickServ and provide UI for the commands it's asking
> the user to use for replying.

Well, it's more that the bot doesn't have to be called 'NickServ' (it used to be 'services' on irc.gnome.org not too long ago), so we can't really know when to show those commands or what exactly the commands would do (just sending the password to anyone calling themselves 'NickServ' would be pretty bad on servers where that's not the actual bot).


> The iteration I'm attaching now is keeping NickServ handling on
> fringe-feature level and just offering to store the password.

I don't think that's quite fair - it's not about whether nick registration should be a fringe feature or not, but about to what level we can support a feature that is a complete afterthought. Whether nick registration is supported and how it is done depends on the IRC network in question, and there's no automated way to figure it out.

The new mockup reflects IMHO the maximum generic support we can have (offer to save a password when we think the user is talking to an auth bot), while addressing the major issue we're currently lacking (identifying the nick before joining any saved channels).

Now, we might still consider something more integrated in the future - once we support preconfigured networks, we can include information about nick registration there. Though that'd probably mean that we cannot ship the list with polari, but need to fetch an updated one from the network on startup (and of course make sure the list is kept up-to-date). But even in that hypothetical future, we'd want something like in the mockup for people who follow instructions to the letter (see the /msg bug where someone was unable to translate "/msg NickServ identify foo" to "message NickServ and type identify foo") ...

(In reply to Florian Müllner from comment #6)
> (In reply to Bastian Ilsø from comment #5)
> > So if I understand you right, you're saying it's not viable to ask the user
> > to read messages from NickServ and provide UI for the commands it's asking
> > the user to use for replying.
> 
> Well, it's more that the bot doesn't have to be called 'NickServ' (it used
> to be 'services' on irc.gnome.org not too long ago), so we can't really know
> when to show those commands or what exactly the commands would do (just
> sending the password to anyone calling themselves 'NickServ' would be pretty
> bad on servers where that's not the actual bot).

Ah, my bad - sounds like I'm not doing my preliminary research in enough in-depth here.


> The new mockup reflects IMHO the maximum generic support we can have (offer
> to save a password when we think the user is talking to an auth bot), while
> addressing the major issue we're currently lacking (identifying the nick
> before joining any saved channels).

I agree.


> Now, we might still consider something more integrated in the future [..]

nod. Maybe Such a future might also contain a backend which supports something more sophisticated like SASL, who knows. :-)

[0]: http://ircv3.net/specs/extensions/sasl-3.1.html

GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version of Polari, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/polari/-/issues/

Thank you for your understanding and your help.