cf-ray: 42f241222ff73536-LHR

cf-ray: 42f24124b9533536-LHR

After /ignoring a user, PMs and highlights from that user are not visible in the UI but still trigger notifications sounds, notification popups, and channel activity counts.

Scrolling the user info pane (the one that pops up when you click a nick in the channel member list) doesn't work, there's no scrollbar:

While attempting to look into connection issues that happen when connecting using the PIA chrome extension (ID jplnlifepflhkbkgonidnobkakhmpnmh, version 1.5.10), one of the XHRs returned a 502 while the connection was just sitting in a nearly-empty idle channel.

JS console log: https://gist.github.com/xnrand/694dd1bf2563417ddcba74144680f528#file-kiwi-freenode-net-1529522730656-log

(copied from prawnsalad/KiwiIRC#957 )

Used on: https://webchat.freenode.net/

JS console (Firefox):

Content Security Policy: Ignoring “'unsafe-inline'” within script-src: ‘strict-dynamic’ specified
Content Security Policy: Ignoring “https:” within script-src: ‘strict-dynamic’ specified
Content Security Policy: Ignoring “http:” within script-src: ‘strict-dynamic’ specified
Content Security Policy: Ignoring “'unsafe-inline'” within script-src: ‘strict-dynamic’ specified
Content Security Policy: Ignoring “https:” within script-src: ‘strict-dynamic’ specified
Content Security Policy: Ignoring “http:” within script-src: ‘strict-dynamic’ specified
This site appears to use a scroll-linked positioning effect. This may not work well with asynchronous panning; see https://developer.mozilla.org/docs/Mozilla/Performance/ScrollLinkedEffects for further details and to join the discussion on related tools and features!
i@https://webchat.freenode.net/static/js/app.e8000b96a2645b83977c.js:1:313800
a@https://webchat.freenode.net/static/js/vendor.328d3f3669c7d835f5f5.js:13:104701
L11a/</</r.prototype.handle@https://webchat.freenode.net/static/js/vendor.328d3f3669c7d835f5f5.js:13:104769
value/<@https://webchat.freenode.net/static/js/vendor.328d3f3669c7d835f5f5.js:13:128463
L11a/</</i.prototype.emit@https://webchat.freenode.net/static/js/vendor.328d3f3669c7d835f5f5.js:7:34630
value/this.emit@https://webchat.freenode.net/static/js/vendor.328d3f3669c7d835f5f5.js:13:98648
value/<@https://webchat.freenode.net/static/js/vendor.328d3f3669c7d835f5f5.js:13:128405
L11a/</</i.prototype.emit@https://webchat.freenode.net/static/js/vendor.328d3f3669c7d835f5f5.js:7:34630
value/this.emit@https://webchat.freenode.net/static/js/vendor.328d3f3669c7d835f5f5.js:13:98648
NOTICE@https://webchat.freenode.net/static/js/vendor.328d3f3669c7d835f5f5.js:13:74823
value@https://webchat.freenode.net/static/js/vendor.328d3f3669c7d835f5f5.js:13:98202
value@https://webchat.freenode.net/static/js/vendor.328d3f3669c7d835f5f5.js:13:98033
value/</<@https://webchat.freenode.net/static/js/vendor.328d3f3669c7d835f5f5.js:13:127209
a@https://webchat.freenode.net/static/js/vendor.328d3f3669c7d835f5f5.js:13:104754
e@https://webchat.freenode.net/static/js/app.e8000b96a2645b83977c.js:1:32476
a@https://webchat.freenode.net/static/js/vendor.328d3f3669c7d835f5f5.js:13:104701
n@https://webchat.freenode.net/static/js/app.e8000b96a2645b83977c.js:1:312083
a@https://webchat.freenode.net/static/js/vendor.328d3f3669c7d835f5f5.js:13:104701
L11a/</</r.prototype.handle@https://webchat.freenode.net/static/js/vendor.328d3f3669c7d835f5f5.js:13:104769
value/<@https://webchat.freenode.net/static/js/vendor.328d3f3669c7d835f5f5.js:13:127131
L11a/</</i.prototype.emit@https://webchat.freenode.net/static/js/vendor.328d3f3669c7d835f5f5.js:7:34630
value@https://webchat.freenode.net/static/js/vendor.328d3f3669c7d835f5f5.js:13:63014
o@https://webchat.freenode.net/static/js/vendor.328d3f3669c7d835f5f5.js:13:60179
BzvE/i.prototype.emit@https://webchat.freenode.net/static/js/vendor.328d3f3669c7d835f5f5.js:1:57119
n/<@https://webchat.freenode.net/static/js/app.e8000b96a2645b83977c.js:1:381434
BzvE/i.prototype.emit@https://webchat.freenode.net/static/js/vendor.328d3f3669c7d835f5f5.js:1:57119
r/n.connect/n.ws.onmessage@https://webchat.freenode.net/static/js/app.e8000b96a2645b83977c.js:1:380700
1iuT/r.prototype.dispatchEvent@https://webchat.freenode.net/static/js/vendor.328d3f3669c7d835f5f5.js:1:30011
jpNK/</r.prototype._transportMessage/<@https://webchat.freenode.net/static/js/vendor.328d3f3669c7d835f5f5.js:18:77044
jpNK/</r.prototype._transportMessage@https://webchat.freenode.net/static/js/vendor.328d3f3669c7d835f5f5.js:18:76995
qMFN/r.prototype.emit@https://webchat.freenode.net/static/js/vendor.328d3f3669c7d835f5f5.js:24:3762
r/this.ws.onmessage@https://webchat.freenode.net/static/js/vendor.328d3f3669c7d835f5f5.js:18:88579

There is a similar error when I use Kiwi IRC in Safari, even when all extensions are disabled.

Kiwi's error (both browsers):

We couldn't connect to the server :( Closing Link: 71-135-5-88.lightspeed.rlghnc.sbcglobal.net (Connection timed out) 

$ ping 71-135-5-88.lightspeed.rlghnc.sbcglobal.net
PING 71-135-5-88.lightspeed.rlghnc.sbcglobal.net (71.135.5.88): 56 data bytes
64 bytes from 71.135.5.88: icmp_seq=0 ttl=63 time=10.724 ms
64 bytes from 71.135.5.88: icmp_seq=1 ttl=63 time=11.659 ms

The title of the page is currently "Kiwi IRC - The web IRC client" which means if you say google Kiwi IRC freenode webchat will be second and more importantly look like it is the normal Kiwi.

Consider changing it to freenode's webchat or something like that?

Minor nitpick: Here (Firefox 59) colour selection includes one emoticon (:-D) at the far right end. Should that not be placed in the emoticons instead?

Maybe formatting like bold and underlined (roughly as "standard" as colours are) could be added to the colour chooser instead.

When disconnected, the following appears:

When clicking on the reconnect button it spins stuck:

Tested on windows chrome and android firefox.

Not urgent as webchat doesn't have a reconnect function at all, but it is full of lies.

Steps to reproduce:

1. Click freenode on the left-hand menu
2. Click Settings on the top tab list
3. Note all of this stuff that shouldn't be here (maybe one or two things should, but most of it is useless and confusing):

4. Click "Remove Network" because lol why not
5. Get sent back to login screen
6. Note that logging in doesn't work any more, clicking Start doesn't do anything

Currently the aliases include modes that are not supported on freenode, like half-op.
I assume this can be configured per instance and thus a set more usable on freenode should be chosen.

(Maybe also do remove the /slap one)

Steps to reproduce:

1. Join test channel and get/have ops in it
2. Click nick in bottom left, note the umode display that says +Zi
3. Click Channel Settings in the top-right
4. Click "Invite only" to enable it
5. Click "Invite only" again to disable it
6. Click nick again, note umode is now allegedly +Z
7. Check modes from oper connection, note they are still +Zi (so this is just a display bug)

Similar things happen when you use the other Channel Settings, e.g. if you enable "Block messages from outside this channel" then +n gets added to your umode display, etc.

I'm a member of the Apache Solr community. We have a wiki page for our IRC channels, which live on freenode.

https://wiki.apache.org/solr/IRCChannels

As a regular resident of the channels mentioned on that wiki page, I see join messages with info like the following:

[8284addb@gateway/web/freenode/ip.130.132.173.219]

Most of the time when we see that, the user has come to the channel via our wiki page, but we cannot be absolutely certain. I would like to have a way to actually be certain about this.

If there were one or more URL parameters available whose value is added to the gecos info, that would solve this. We could add the URL parameter to our link, and then we would see that text when the user joins the channel. If somebody decided they didn't want that information to be present in their ID, they could remove the parameter. It could even be a part of the "Connect" form where the user enters their desired nickname.

Summary

Add a supported and automated way to grant voice privileges to any user joining an IRC channel from the web chat client (possibly with ChanServ rules)

Background

In the #rit* and #fedora* communities, we countered high levels of spam by requiring NickServ authentication to speak in the channel; however, we also have a lot of newcomers who join using web chat or other gateway clients like Matrix/Riot and are not familiar with IRC or registering a NickServ account. We used a ChanServ rule to automatically grant voice to these users so they didn't have to figure out NickServ to chat (and also since it was highly unlikely for spammers to use a gateway service to massively spam).

However, now that Kiwi web chat does not assign a @gateway/* cloak, this prevents any web chat users from speaking in almost all of our channels without registering. Of course we can instruct people to register, but if they are connecting to IRC for the first time or are taking one of the classes at our university that introduces them to using IRC, it is a tedious step to register an account first before actually chatting in the channel.

Details

Specifically, we set up most of our channels in this way:

/mode +q $~a
/query ChanServ ACCESS #channel ADD *!*@gateway/* +V

Outcome

• Easier to on-board newcomers into IRC channels / communities
• Avoid loosening anti-spam measures which resolved 100% of our spam issues for 2+ years

Currently (at least on Firefox) it's not possible to hit connect when the channel field is empty. Users new to the webchat (I assume it can be embedded with preselected channels, even though the GUI does not seem to offer such an option) might not know what channels are / which ones to join, so maybe a default example could be added?

Also there might be use cases where users do not want to join channels at all.

Current webchat allows to be linked / embedded and even offers a wizard to create a link with a preset of channels.

I assume that webchat will be replaced, so for these projects wishing to offer this to users, it would be nice if

1. there was a (GUI) option to create links including a preset of channels
2. old URLs could be redirected for the new webchat to work as well, if possible

As it stands, Google's reCaptcha partly relies on tracking users' online behavior to decide whether a person is a robot or not.

Right now, reCaptcha is used in freenode's web interface. I'd much rather a privacy-minded alternative be used. hCaptcha is probably the best-known privacy-oriented alternative, though I'm sure there are others.

if not disabled entirely by default, at least disable for specific channels

There's one after you connect, but meh.

Additionally, I think the language detection is wrong. My language settings look like this:

accept-language: en-GB,en;q=0.9,bg-BG;q=0.8,bg;q=0.7,en-US;q=0.6,ro;q=0.5

And I end up with Bulgarian. en should match first. If I move Romanian or English (US) above, it works (I guess because there's no translation for Romanian?)

Tried /away and /away test, not seeing an away message when I /whois from another connection either way.

Sending the message :test actually sends the message test. Sending the message ::test actually sends the message :test. Sending the message :test test works correctly.

Notably, there's a button to send a :D emoticon, which actually sends just D if you have it on a line by itself (which is how I noticed this in the first place).