Blacklist genres/tags in account settings [Planned]

[Hurriante]

I wish to be able to block a tag, like BL. Too much, and I don't want it interrupting my search.
I know about advanced search. But, sometimes it's nice to just scroll the main page of stuff.

 

[Roler]

I would like to have the feature to filter out releases/manga that I already have in my reading lists when browsing through "latest updates". Asking here because it is partly related to the feature discussed in this thread.

That would actually need to work very differently from tag exclusion, as there are only 76 tags you can block (or less, dunno what they'll set as the limit) that get passed in the URL itself, for whole MDLists that wouldn't be feasible.

A more similar suggestion to yours would be: https://forums.mangadex.org/threads...-rejected-technical-reasons-dev-reply.1076334

 

[Xreator]

That would actually need to work very differently from tag exclusion, as there are only 76 tags you can block (or less, dunno what they'll set as the limit) that get passed in the URL itself, for whole MDLists that wouldn't be feasible.

A more similar suggestion to yours would be: https://forums.mangadex.org/threads...-rejected-technical-reasons-dev-reply.1076334

Exclusion by tags would have 76 possibilities and exclusion by reading status would have 6 possibilities. It also would only be used on a page by page basis on "latest updates" (in my case 50 mangas per page) and not the whole MDLists. So I don't see why it wouldn't be feasible.

Maybe this explanation is better:
If I go to "latest updates" hide the mangas on the page (that are loaded per page) that have a reading status (reading, on hold, dropped, plan to read, completed, re-reading) or the other way around, only show mangas without reading status.

 

[Manko-sensei]

Exclusion by tags would have 76 possibilities and exclusion by reading status would have 6 possibilities. It also would only be used on a page by page basis on "latest updates" (in my case 50 mangas per page) and not the whole MDLists. So I don't see why it wouldn't be feasible.

Maybe this explanation is better:
If I go to "latest updates" hide the mangas on the page (that are loaded per page) that have a reading status (reading, on hold, dropped, plan to read, completed, re-reading) or the other way around, only show mangas without reading status.

Someone else has already explained it more accurately, but the status is something on the user's end, not mainsite wise. Tags here are all those words that link you to a site listing, not to your own profile (in fact, they don't even redirect you there, you simply set the status and then go to library and choose the desired status to merely scroll). It's about the infrastructure of the site.

 

[Roler]

Exclusion by tags would have 76 possibilities and exclusion by reading status would have 6 possibilities. It also would only be used on a page by page basis on "latest updates" (in my case 50 mangas per page) and not the whole MDLists. So I don't see why it wouldn't be feasible.

Maybe this explanation is better:
If I go to "latest updates" hide the mangas on the page (that are loaded per page) that have a reading status (reading, on hold, dropped, plan to read, completed, re-reading) or the other way around, only show mangas without reading status.

Well, no, with the way the API currently works, you can't even exclude manga UUIDs (unlike tag UUIDs), only include them, and if manga exclusion was implemented, it would be most likely implemented the same as manga inclusion and tag exclusion are: by passing every included/excluded manga/tag UUID inside the URL params.

Personal endpoints and public endpoints are separate, latest updates uses a public endpoint which doesn't know the contents of your library (you can see here why library-aware search/sorting is not feasible), so you would need to specify every excluded manga UUID in the list as said above (if manga exclusion was added in the first place), not the list UUID/library status, and that's not feasible with the amount of manga a list can have (you're limited to max 100 UUIDs per request and URL character limits need to be taken into consideration).

Here's an example URL with included manga: https://api.mangadex.org/manga?limit=100&ids[]=29ab6984-7c1d-4d45-b925-25aa082b492e&ids[]=d9e17531-63ee-4427-ac9f-35bd2869ac0b&ids[]=d24d0d72-77a7-4e4d-bce3-aba5c9eb3162&order[latestUploadedChapter]=desc
And here is an example URL with excluded tags: https://api.mangadex.org/manga?limit=100&excludedTags[]=0234a31e-a729-4e28-9d6a-3f87c4966b9e&excludedTags[]=07251805-a27e-4d59-b488-f0bfbec15168&order[latestUploadedChapter]=desc
(though, latest updates actually uses the public chapter endpoint, which currently can't even exclude tags, so not sure if/how that will be implemented)

One way would be to filter it out client side, but that method is/was usually refused as it would show less results than expected and potentially misleading empty pages (for example: page 1 is empty, while page 2 shows results).
Basically the same as this response says (and the linked forum post above says):

If filtering is only done on the user's device, the search might break. For example, when searching for a manga, the top 5 results shown are currently filtered by the server to match your preferences. If filtering happens only on your device, the server might send 5 irrelevant results, which get removed, leaving the search box empty—even though there are matching results further down. We can’t just fetch extra results to fix this, because there’s no way to guarantee how many extra results would preserve the same behavior.