I would really appreciate if the Discourse user interface wasn’t trying to sell me AI. I’m not buying, now or ever. Could there be a preference that disables suggestions to summarize every single post with AI?
I notice that it isn’t doing it on this site. I see from other posts that AI summary is an add-on. It’s fine with me if TC39 (the JS standards organization) has this add-on, but my personal preferences are different than theirs and my desire to have their values imposed upon me is 0
Welcome to Meta 
Can you clarify which nudges you are talking about? Currently, I am not sure if you are talking about a feature of the official Discourse ai plugin, or if that is a custom feature on another Discourse forum you are using.
I know the button to summarise topics, but I am not aware of a feature that shows a button for summarizing on every post.
1 Like
Yep, those are the ones I’m talking about. I guess they do exist on this site too.
I guess you could use CSS with a browser plugin like Stylus to hide the button for yourself. I use that to remove another part of the topic map on this site.
I’m a frontend engineer by trade, so that thought had occurred to me. Setting that aside for a moment let’s say I wanted to code a PR to Discourse that created a new setting to disable this feature, would a high-quality PR to that effect be accepted?
I can’t answer on their behalf, but in general they tend to think more than twice before adding new customization settings to prevent more complexity than it is necessary, and favour feature requests that get traction.
1 Like
It’s not exactly a random request. I know I’m very far from the only person who is opposed to AI on ethical grounds. I’m also just deeply bitter about this technology given its corrosive effects on collaboration and competence. Almost every tool that has chosen to cram in AI features has also faced significant demand to be able to turn them all off: Firefox, VSCode, Notion, etc.
1 Like
This is quite important.
We love getting those high quality PRs, but every setting causes overhead one way or another, so we are trying very hard to be critical of what we add as such.
An alternative route would be to raise the question on the forum that you are using itself… maybe you can convince them to turn it off altogether.
Either way, before putting in your own time and effort into making that PR, a good bet would be to make a Feature request and see if your idea gets any support.
However, if you can easily hide it via CSS as suggested here, I’m curious why you’re adamant about making it into a setting? It that just ideologically driven?
1 Like
note that admins can already turn AI off entirely with a single toggle
as a user preference the scope would mostly involve optionally hiding buttons… individuals could not entirely disable AI features used by an admin, like spam detection
2 Likes
Yeah I figured that a simple setting in user interface wouldn’t really do more than toggle the button. But that’s really what I want. Since I’m not ever going to use that button, it doesn’t improve the product for me, and so I’d prefer not to see it.
1 Like
I wanted to disable all AI integration on my site, and I am really pleased that it is a single setting. An answer to what the OP is looking for might be the equivalent of discourse_ai_enabled but on a per-user basis. That way, AI is not exactly on/off for the whole site. Even AI features that are on at a site level could be suppressed on a per-user basis. The logic of discourse_ai_enabled is then site-wide == true and per-user == true.
While it is generally true that they think about adding new customization settings to avoid unnecessary complexity, AI is the feature with the largest number of configurable settings. In the short span of time AI has even been a thing, it seems to have become the most customisable feature in Discourse.[1]
Here’s a quick and dirty analysis. I am relatively new here, so I show my work in case I’ve made a mistake.
su discourse -c 'bundle exec rails runner "SiteSetting.defaults.all.keys.sort.each { |k| puts k }"' > keys.txt
wc -l keys.txt
1663 keys.txt
cut -d _ -f 1 keys.txt | sort | uniq -c | sort -rn > counts.txt
If this is the right way to count them, there are 1663 possible site settings. Of those, 104 begin with ai_ and 3 AI settings don’t (composer_ai_helper_allowed_groups, discourse_ai_enabled, and post_ai_helper_allowed_groups) . So, by my reckoning, AI is the largest group of custom settings by a long shot (107/1663 or 6.4% of all site settings). Here’s the top 10:
- 107 ai
- 84 discourse
- 83 chat
- 71 max
- 65 enable
- 48 default
- 30 dfp
- 28 oauth2
- 28 amazon
- 28 allow
On the one hand, per-user suppression of AI features is just 1 more out of 1663. On the other hand, it might be hard to check it on a per-user basis when lots of code paths check it on a site-wide basis. That’s a tradeoff I’m not qualified to speculate on.
It’s also a fairly well-defined and self-contained feature, and relatively young, so its naming consistently with
ai_makes its settings easier to count than other components. That’s why I say it’s quick and dirty analysis. ↩︎