9

When I load the realtime question page, this happens in my console:

enter image description here

And the list doesn't update in real time. This makes me sad. Please fix it.

Improve this question

1 Answer 1

Reset to default
8

Hmmm, so that DNS was used after all! We did some cleanup yesterday on the stackexchange.com zone.

A build updating it to the correct qa.sockets.stackexchange.com is going out now, should be working shortly.

Improve this answer
20
  • 3
    Awesome, it already works. Thanks!
    – Undo
    Apr 13, 2014 at 2:28
  • do I understand correctly the websocket URL has changed? Should I update my userscript?
    – John Dvorak
    Apr 13, 2014 at 9:23
  • @JanDvorak it changed some time ago, but why does it appear in a user script? We may change it at any time, hardcoding it anywhere isn't an awesome idea.
    – Nick Craver
    Apr 13, 2014 at 10:39
  • @NickCraver how should I obtain the URL, then? Or, is there a documentation of the StackExchange object?
    – John Dvorak
    Apr 13, 2014 at 10:41
  • @JanDvorak let me step back, why is your user script trying to access websockets in the first place? They have a very specific purpose which is already in those pages
    – Nick Craver
    Apr 13, 2014 at 10:58
  • 1
    Here is said userscript: meta.stackexchange.com/questions/193646. I chose websockets over scraping the page for variety of reasons. One is that I thought it would hold more information than the page (say, a longer snippet). The other was of performance: MutationObservers were not well supported in web browsers back then, nor were mutation events (they also killed performance. the the MO support is better now, but I don't want to rewrite this part just because I can), and polling the page for changes felt conceptuallly wrong. Also related: meta.stackexchange.com/questions/218343
    – John Dvorak
    Apr 13, 2014 at 11:16
  • 1
    @JanDvorak we have greatly improved the spam blocking since then, and are about to do another round of improvements, is this an issue anymore? Obviously from my side you can see the concern: I want to fix spam appearing for all users rather than fix a script made to hide it for a few.
    – Nick Craver
    Apr 13, 2014 at 11:20
  • @Nick on the smaller sites spam can stick for hours if not reported using such measures so I think it'll always be an issue.
    – Shadow The Spring Wizard
    Apr 13, 2014 at 11:22
  • 3
    @NickCraver That script helped several of us to be alerted of cross-network spam so we could go and flag even on sites we're not necessarily active on. I have plenty of accounts where my only activity is spamflags to help them out. That was a pretty useful thing IMO.
    – Bart
    Apr 13, 2014 at 11:23
  • @ShadowWizard then any scripts performing decent automated blocking (that we currently miss) we'd certainly welcome as suggestions to improving the global spam blocking. I'm not opposed to the user script working, but that logic should also travel upstream don't you agree?
    – Nick Craver
    Apr 13, 2014 at 11:25
  • I appreciate the effort to block spam before it appears. If it makes my spam filter obsolete, I will be more than happy. So far, I do have quite a few true detections (and seems very reliable for certain persistent spammers). Do I understand correctly the spam-filter only checks high-volume sources? As for the "for all users concern", this is a tool to find stuff to flag, not a way to hide it for a single person. The latter could be just as easily accomplished by me not visiting the realtime tab ;-)
    – John Dvorak
    Apr 13, 2014 at 11:25
  • @NickCraver I do certainly agree that this should be fixed server-side. My script produces a lot of false positives, but Manish's script seems to work perfectly well. It reports screaming (all-caps titles, which are either VLQ or outright spam), phone numbers and some select keywords.
    – John Dvorak
    Apr 13, 2014 at 11:27
  • @Nick the existing scripts/bots are not blocking anything, they just report such spam in chat thus calling users who can flag as spam.
    – Shadow The Spring Wizard
    Apr 13, 2014 at 11:28
  • 2
    @Jan the Smoke Detector also got his share of false positives, e.g. error numbers in code which appear as phone numbers to the script.
    – Shadow The Spring Wizard
    Apr 13, 2014 at 11:29
  • 1
    @NickCraver which is a great thing, indeed. And I'm more than determined that hunt down the few that made it through the sieve, even if I'm unnecessarily alerted of multiple false positives. Autoflag heuristics can be much more strict than autoblock heuristics. Perhaps some of these heuristics should be fed to the existing VLQ queue (another side effect is that the audits would look more realistic)?
    – John Dvorak
    Apr 13, 2014 at 11:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .