control-panel-for-twitter VS webextensions

Control Panel for Twitter [1] can automatically hide boosted blue replies for you

…although if an account is big enough, you're safer looking at the Quote Tweets instead for actual comments (it also restores the old direct link to those in the focused Tweet), e.g. you're lucky to get more than a handful of non-blue replies under an Elon Musk tweet among the engagement farmers before you hit the maximum number of replies Twitter will load

[1] https://jbscript.dev/control-panel-for-twitter

In terms of a browser extension for Twitter, I highly recommend Control Panel for Twitter. It works as a browser extension as well as on some mobile browsers. It is highly customizable to filter out who/what you don't want to see and is fully open source if you feel the need to tweak.

It's updated regularly and the creator is highly active on Twitter to provide updates and answer questions - @ControlPanelFT

If you decide to use it, drop the guy a donation, they work hard on it!

https://github.com/insin/control-panel-for-twitter

Aye sorry I should have linked. Here you go: https://github.com/insin/control-panel-for-twitter/releases/tag/v3.21.4

Control Panel for Twitter can already put them back [1] * *

[1] https://github.com/insin/control-panel-for-twitter/releases/...

* while Twitter continues to put the headline in the aria-label on the link, given there's no accessibility team left to protect it

* unless you're using Firefox, as Firefox Add-ons now takes ~4 days to review new versions

> Prioritising the replies of people who pay money for it was a body blow

A Twitter reply thread will only load around 200 Tweets in total, so on Tweets which have a lot of engagement, it's more likely that your reply will never be seen even if you paid, which defeats their whole purpose for ruining reply threads as a selling point. Just an incredibly short-sighted change.

My browser extension for Twitter [0] can hide replies from "verified" users - if you look at any Elon Musk tweet with this feature enabled, you'll be lucky if you see more than 1 reply.

Quote Tweets are where it's at now if you want to find comments on busy tweets which aren't Twitter Blue user posting multiple cry-laugh emojis, and they've recently made those take multiple clicks to access, from one of 2 different menus (my extension also restores the old Quote Tweets link).

[0] https://jbscript.dev/control-panel-for-twitter

While I realize this does nothing for mobile (RIP third-party clients), Control Panel for Twitter [1] has been nice for me to use as a browserscript. Defaults/hides "For You" and tweaks a bunch of other stuff (hideable trends, etc).

[1]: https://github.com/insin/control-panel-for-twitter

On desktop, the extension "Control Panel for Twitter" will let you "Replace X branding changes", it's great.

https://jbscript.dev/control-panel-for-twitter

You can also hide the idiots with the BlueLiteBlocker extension

https://github.com/BlueLiteBlocker/BlueLiteBlocker

Makes Twitter a bit more like it was before idiot in chief took over

Idk for mobile, but for desktop - one such example.

I've edited my comment to also include a link to the Chrome docs, but that FAQ entry also has the link to an issue in the webextensions repository indicating it's a limitation of MV3: https://github.com/w3c/webextensions/issues/112

Google outlawing dynamic code in Web Extensions/mv3 is a travesty of high order. There's no place I want to be able to be more alive than my agents. Yet my agents must all be dead. For shame, ye villains.

https://github.com/w3c/webextensions/issues/139

This post definitely was quite a technical explanation. The opening framing, to me, means the world.

The other big change of mv3 that gets no coverage but which is dear to me is that mv3 outlaws any kind of dynamic code. The whole app has to be statically defined. This makes it much easier to know what's running, since an extension can no longer go pull in extra code, but it greatly reduces what you can do as an extension too. Extensions have to have all behaviors predefined. I can't dial home & load my behaviors. Here's the issue, https://github.com/w3c/webextensions/issues/139

For a while it meant that userscripts didn't have any way to run. So Google introduced a new API for user scripting. But those extensions only run in "developer" mode. I'm guessing that means when devtools are open?

I agree a lot with your premise. It sure seems like Google is targeting everyone with these changes, but that better real affordances & escape hatches need to be builtin to not maim the lives of power users. It took a long long time to come up with a userscript solution, and it seems like an awful doesnt-work-for-me workaround (I use userscripts not to dev but to modify everyday experiences). Chrome just hasn't been taking their obligation to user agency seriously.

> the extension APIs are standardised enough that this is actually possible a lot of the time

A bit off topic, but as a co-chair of the WebExtensions Community Group[1] (WECG) I'm a bit touchy about the calling WebExtensions "standardized." A few years back the Browser Extensions Community Group[2] created a spec for WebExtensions, but it never reached a state that we'd normally refer to as a web standard. (Technically W3C community groups can only produce "Reports" and these documents are not on the standards track.[3])

FWIW, I'm very bullish about specifying and (hopefully) standardizing the WebExtensions platform. I'm especially excited about having a good chunk of dedicated time to sit with browser folks at TPAC 2023[4] and try to work out some open questions about where we're going and how we're going to get there.

[1]: https://github.com/w3c/webextensions/

While I was trying to find out what Firefox's limits are I came across this interesting issue on the W3C's webextensions repo: https://github.com/w3c/webextensions/issues/319

4 days ago the Chromium developers proposed upping the limit for certain types of declarativeNetRequest rules based on data AdGuard provided on real world rule lists.

Manifest v3 is used for Chrome's extensions system. The proposal appears to limit what extensions have access to, and what they can do in Chrome. It is proposed as a W3C standard by Google. It is being tracked at the W3C at https://github.com/w3c/webextensions/issues/44.

Google is not even close to finishing MV3: "On the userScripts API, the proposal has been merged into the WECG but the engineering work has not started yet." https://github.com/w3c/webextensions/blob/f8f430f1904c2a6fa8...

MV2 is sticking around until at least 2024.

Some, but not all, limitations are highlighted in this thread: https://github.com/w3c/webextensions/issues/72

Somewhat tangentially, I've been pushing for a popup/overlay API that allows to specify the position and size, and doesn't require any origin permissions.

https://github.com/w3c/webextensions/issues/307