Topic: Auto-added tags attributed to me.

This is a minor thing, but it really bugs me when tags get auto-added to a post because of updated implications or such, but these tags changes are attributed to my name. For example on post #1531112 I only added the "balls touching" tag. But in the image's history, it shows that I added "foreskin, gem, genitals, humanoid genitalia, narrowed eyes, penile, plant, sega and sonic the hedgehog (series)" and removed "sonic mania, sonic (series) and uncut", all for a manual addition of a single tag.

Is there any way to make it so that these auto-added tags are specified to have been automatically added, instead of being attributed to me? I have had a time before where a mod accused me of adding a tag to a post, even though it was auto-added and just attributed to my name.

It would be very nice to improve the way this works, there's a little bit of discussion at issue #623, but the issue is mostly just not having enough developer time to tackle it - on top of not really having a solid idea of how to better represent this information.

sexygriffon said:
I have had a time before where a mod accused me of adding a tag to a post, even though it was auto-added and just attributed to my name.

I've stated before that it's even confusing for experienced users of the website - this is yet even more proof of that. It should not be so arcane that moderators are accusing users of doing things they didn't because they can't read the output properly.

So I just discovered that it's a LOT worse than I thought it was.

Yesterday, I was browsing some old images randomly and I came across post #1885070 from six years ago. I'd never seen this one before, so I decided to add it to a set that I have. That's literally all I did, I added it to a set. Didn't even click on the "Edit" button.

Today I was checking my account and I saw that there was a record for a post edit that I didn't recognize. I panicked for a few moments because I thought my account had been hacked or something. It took me way too long to realize that when I added that post to my set, it changed a bunch of tags that have since been updated (ie, Pussy -> Vulva) and it has been attributed to my account. Why? I didn't even do anything to the tags this time! I only added it to a set. Why is there suddenly a sizeable tag swap edit attributed to my name?

OH BUT IT GETS WORSE! In order to understand wtf was happening, I navigated to post #1885068 to investigate. I should note that before I did anything, I noticed that the "Vulva" tag was already listed on the side and the "Pussy" tag was gone. And yet, when I added this post to a set, suddenly there's another tag edit attributed to my name that says I removed "Pussy" and added "Vulva"..even though that change seems to have already taken place? It also says I updated the Twitter source link to an X link.

Appending these phantom tag updates onto an existing tag edit is one thing, but having the site generate completely fictitious tag edits and attributing them to me is just nonsense. I don't want these changes connected to my name when I had NOTHING to do with them. I have literally never touched the tags on this post. Why is the system like this, and can it PLEASE be changed?

sexygriffon said:
Why is the system like this, and can it PLEASE be changed?

Unfortunately issue #623 was closed as "won't fix" so there are seemingly no intentions of ever making this better.

That makes me uncomfortable.

I solved this issue on my own instance by just having each action of the BUR create a post version and if the most recent version was made by the system user, merging the changes into that existing version rather than creating a new version

At one point I even overhauled BURs entirely

This was originally a testing ground for features/changes I wanted to eventually bring here, but that isn't happening anymore

I am highly doubtful any changes will ever happen here since we've had over 5 years to make said changes since ng, and since the current development focus seems to be more on ui changes than anything

If that's the case, then maybe there should be a "ui change" to the page that lists a user's tag changes, to the tune of adding a disclaimer to the top saying that not all tag changes were actually intentionally performed by the user in question.

I feel colouring any system changes a different colour (like yellow instead of green) would be helpful in showing that this change was not added by the users themselves, while still keeping the existing system of attributing the edit to the user intact.
Not sure if this would be feasible or even possible on the technical side.

The thing about trying to handle this stuff at a later time is that you're going to catch aliases and implications that are actually being added by the user unless some complicated filtering is doing
It also still really doesn't help the fact that it's being credited to the editor, even if they're noted to be from an alias or implications they would still be triggered when doing anything that edits the post

In the future, if one of us staff members makes a mistake, you're always welcome to discuss the matter with them, & if the staff member in question isn't receptive, you can file a report or open a private help ticket on our Discord server to bring the matter to the whole team.

As for this issue, while we're aware of this in some form, I was unaware that post changes like adding to a set triggers the versioning. I looked into it, & it should be trivial to at least disable that.

As for the root problem, there has to be some simpler way to handle this; I'll try to look into it when I get a chance. Current thought is to cache the normalized changes to the post & use that during creation of the version info to isolate changes that must be by the user & changes not related to the edit at hand, but I'll have to see if that's viable.

aacafah said:
As for the root problem, there has to be some simpler way to handle this; I'll try to look into it when I get a chance. Current thought is to cache the normalized changes to the post & use that during creation of the version info to isolate changes that must be by the user & changes not related to the edit at hand, but I'll have to see if that's viable.

Wouldn't the simplest solution be to make a version change for the affected posts of AIBURs and attribute that to automod?

I mean, yes, that would lead to a lot of version changes (and possibly create some performance issues),
but it would also make the version history much more transparent than it is now.

snedmano said:
Wouldn't the simplest solution be to make a version change for the affected posts of AIBURs and attribute that to automod?

I mean, yes, that would lead to a lot of version changes (and possibly create some performance issues),
but it would also make the version history much more transparent than it is now.

IIRC, it has been said that it would be too much of a performance problem to actively create a version change for posts affected by aliases and implication being applied. Especially for more commonly used tags that would affect more posts. Maybe if there was some way to delay making a version change until the post is updated later, e.g. when a user modifies a post's tags, it then creates a version change for any automod changes before creating the user's change, so that the system doesn't get bogged down when adding the tags from aliases and implications being created and does it later on a per-post basis, when creating a version change for the given post anyway it can create a second one, but I have no idea the practicality of that.

snedmano said:
Wouldn't the simplest solution be to make a version change for the affected posts of AIBURs and attribute that to automod?

I mean, yes, that would lead to a lot of version changes (and possibly create some performance issues),
but it would also make the version history much more transparent than it is now.

Post changes are already heavily limited in searchability due to performance issues, there are 45.3 million of them and you can only search the most recent 10,000 for any given query because going any further has significant performance issues
Creating a version for each BUR edit would almost certainly make that problem at least 3 times worse than it already is, which is why it's not an option

donovan_dmc said:
Post changes are already heavily limited in searchability due to performance issues, there are 45.3 million of them and you can only search the most recent 10,000 for any given query because going any further has significant performance issues
Creating a version for each BUR edit would almost certainly make that problem at least 3 times worse than it already is, which is why it's not an option

Huh, I didn't consider that to be an issue.
And that would also go against the idea of watsit, as that would just delay that problem.
Though if there are multiple AIBUR changes before a user does an edit, these would get merged together, minimizing the version changes while still being as transparent as possible.

snedmano said:
Though if there are multiple AIBUR changes before a user does an edit, these would get merged together, minimizing the version changes while still being as transparent as possible.

That was basically my thought. When a user submits tag changes for a post, it would first look at the last post version and the current tag set for the post being modified, and generate a post version if there's a difference and attribute it to the automod, and then handle the tag changes from the user as a separate version change. When the AIBUR changes were made isn't really necessary to record, nor which AIBURs caused which changes.

watsit said:
When a user submits tag changes for a post, it would first look at the last post version and the current tag set for the post being modified, and generate a post version if there's a difference and attribute it to the automod, and then handle the tag changes from the user as a separate version change. When the AIBUR changes were made isn't really necessary to record, nor which AIBURs caused which changes.

Seems simple enough to implement.
I agree, this is most likely to be the most elegant way to solve this issue.

And yeah, seeing which AIBUR is behind the change is not really that important. These can be easily seen when searching through the implication / alias listing.
The important part is to separate the user changes from the AIBUR changes.

Edit: Removed double quote

I'm not creating versions for AIBUR edits, at least not like that. It needlessly bloats both the database & the search results, doing it before the change goes through means if the edit fails for whatever reason, you now have an extra entry, & users could have manually made changes overpowered by the AIBUR (e.g. removing male while leaving male/male doesn't change anything). Like I said, I'd determine which changes couldn't possiblely be attributed to the user, & then I'd either add a field to store those separately or discard them entirely; we still store the entire list of prior tags, so we don't need the prior state + all the changes to match the new state.

aacafah said:
I'm not creating versions for AIBUR edits, at least not like that. It needlessly bloats both the database & the search results, doing it before the change goes through means if the edit fails for whatever reason, you now have an extra entry, & users could have manually made changes overpowered by the AIBUR (e.g. removing male while leaving male/male doesn't change anything). Like I said, I'd determine which changes couldn't possiblely be attributed to the user, & then I'd either add a field to store those separately or discard them entirely; we still store the entire list of prior tags, so we don't need the prior state + all the changes to match the new state.

Ah, guess it isn't as simple as I thought it would be.
I'm not sure though how you would determine which tags weren't changed by the user. (I guess by checking for a delta between the tags after the edit (with all aliases and implications applied) the last version change and the tags before the edit?)

I think displaying the AIBUR changes in some way, rather than hiding/discarding these entirely, would be a good idea.
Like in a completely separate field or showing these tag changes in a different color (perhaps yellow?).

snedmano said:
I think displaying the AIBUR changes in some way, rather than hiding/discarding these entirely, would be a good idea.
Like in a completely separate field or showing these tag changes in a different color (perhaps yellow?).

Suggested but ignored? ¯\_(ツ)_/¯

thegreatwolfgang said:
Suggested but ignored? ¯\_(ツ)_/¯

Oh, I didn't even see that. (My ability to completely miss things staring at me right in the face strikes yet again 🫠)