There are a few high volume users who post many observations that I’m not interested in identifying. I’m aware that it’s possible to copy/paste a list of exclusions into the search every time, but it would be more convenient if the exclusion list were persistent. The “mute” concept already exists and I think that excluding muted users from the observation search would be expected behavior.
I approved this feature request but I don’t think we would ever automatically exclude muted users from Identify. People have already chosen accounts to mute knowing exactly what muting does and does not do, and changing its definition at such a basic level would be really disruptive.
That being said, I’m for adding exclusion filters to the Identify page, especially exclusion filters for users. I could imagine a checkbox one could use to exclude one’s muted accounts from Identify.
I disagree. I would not want muted users excluded from a search. Many users mute people to prevent notifications, not to prevent seeing their observations.
From what is described above, then just don’t activate the option. This just gives the option to exclude muted users.
I recently muted a user for the first time, as they seem to enjoy submitting hundreds of blurry photos, and multiple observations of the same flock of birds (claiming they are different parts of a flock) - amongst other things. I decided that it isn’t worth my time to go through and identify each one. I know I could filter to the user and Mark All As Reviewed, but even then it can be a few pages.
I had expected that muting a user would exclude that user from the Identify search, but apparently not. I’m glad I’m not the only one that thinks that should be how it works.
Edit: The user has over 18,000 observations since the start of the year.
I have a saved URL search for “basic identify” that excludes a user who uploads hundreds of the same photos, uncropped, each one “identifying” a different (usually distant) plant 
So I added their user ID to my URL. But it seems a clumsy way to exclude a user you have no problem with, but don’t want to see obs from…
That’s a good idea. I have a saved URL for my specific search terms already, so I will just modify it to hide that user.
Edit: In case others need it…
https://www.inaturalist.org/observations/identify?not_user_id=username
Or change to **&**not_user_id= if you have other URL modifiers.
That would be better than us tweaking an URL to achieve the same purpose. Hate cobbling together elaborate strings for an URL ! Available filters are easier and effective.
Superficially, I like the idea of the original request, but this might be the safer course of action.
I have to confess that I use the modified search URL to exclude the observations from a long list of users, and I have a smaller list of users muted to suppress their notifications. I would have to think about whether merging the two lists would cause any problems for me. I know that I muted one user today simply because I got tired of seeing them adding IDs to observations that I somehow got subscribed to (I probably annotated them). They’re from outside our region and isn’t likely to ever report an observation I would be interested in identifying. But it might not work the other way. I can well imagine wanting to know about an incorrect ID submitted by one of the folks whose observations I filter out (ie. an ID on someone else’s observation).
One upside of modifying the search URL over simply filtering out your muted list is that you can SEE who has been filtered out by looking at the URL. I don’t know if there’s a way to see your muted list, but if not, it would be more involved to check if a particular observer is muted.
A downside of the URL method (at least for me) is that if you have several different URL’s saved for different tasks, on different machines, it can be a pain to update all of them every time you want to add/subtract a user from your filtered list.
It would be nice to have a single place where you can maintain a list of observers you want filtered out of your identification view. If the option to filter out my muted list were made available, I would take the time to consolidate my muted and filtered lists into a single list. And it would probably get considerably longer.
I think it would be great if these functions were completely separate.
Right next to the “follow” and “mute” buttons on each member’s profile, there could be a button that automatically marks all of their observations (past and future) as reviewed.
There are a few observers in my area I would use that feature for, but I don’t want to actually block notifications from any of them, if we interact on someone else’s observation.
https://www.inaturalist.org/people/username/edit#relationships should do it, halfway down the page.
Excellent. Thanks.
That might work for the average user, but it assumes that “reviewed” means “I’m not interested”. That’s not how I was using reviewed up until this year. So in my world, “reviewed” means one thing for observations submitted before 2026, and now means “I’m not interested”.
(as a side note, I made a feature request to expand “reviewed” into 2 or 3 discrete status flags to help with keeping track of observations, but it didn’t get much traction)
I wasn’t assuming that at all, but I still think it could functionally be used for both.
I’m not sure how you were using it before this year, but for me “reviewed” usually means either, “I’ve already identified this” or “I looked at this but couldn’t identify it.” I don’t need to see it again next time I’m identifying in that category. So “reviewed” just keeps me from sorting through the same observations again and again, regardless of how interested I might have been the first time.
I think it could be expanded to also include automatically marking observations from certain users “reviewed” without even looking at them once, whether that’s due to lack of interest or just incompatible workflows. The reason doesn’t really matter, it’s just about having them hidden by default when in identify mode.
My use case was a bit idiosyncratic, because I review observations for subsequent download to an external database. I was using “reviewed” to mean: “yeah, I’ve looked at this and I agree with the ID. I want to include this in my download without having to click agree”. I was doing it this way because I could click “reviewed” on an entire page of RG observations after reviewing the thumbnails (and drilling down where necessary). This was much faster than clicking agree on each individual observation. When you’re dealing with 10’s of thousands of observations per year, saving a few seconds on each page of RG observations adds up.
My software would then access the API and download RG observations that had been reviewed by me (to capture both the observations I had personally identified, as well as those which I agreed with and just clicked “reviewed”). I’m not following this workflow going forward, but everything prior to 2026 has been marked this way. If your suggestion were to be implemented, it would mess things up for me. Yes, the pre-2026 observations have already been downloaded, but if I wanted to do any audit type work on those observations, I have to preserve what’s marked as reviewed, etc. Your suggestion would retroactively mark observations as “reviewed” if I decide to mute an observer tomorrow (conferring defacto approval onto observations that I had intended to exclude).
This is a problem with iNat - the tools identifiers use to manage their work queues leave something to be desired. As a result, identifiers have to devise workarounds and hacks to meet their needs. So they might be using some features in ways that other users would never imagine. If you tamper with those features under the assumption that everyone else is using them the way you are, it might cause unforeseen problems.
Please note that “identifiers using features in ways other than those originally intended” is not unusual. Indeed, every time you suggest a new feature to make your work easier, the first thing you see is a flood of suggestions for hacks/workarounds that will kinda-sorta provide the functionality you’ve asked for, as long as you don’t mind a long list of inconveniences…
In that case, I can see why you wouldn’t be able to use the feature if it were the same as “reviewed.”