Topic: What's the story on tag subscriptions?

Posted under Site Bug Reports & Feature Requests

The more I use e621, the more desperate I am for a way to organize the artists, franchises, and general tags I enjoy in one place. The rate of new content being posted makes it difficult to browse all of it at once without missing things, and I have too many interests to search each one manually.

After spending a while searching the forums, I discovered the old tag subscriptions feature, which I understand was nonfunctional for some time before eventually being removed. I also found multiple subsequent requests for functionality that would be met with the tag subscription mechanism.

My first question is, why was it removed? Was it difficult to maintain, or was there low user interest? Since personalized content feeds are a central feature of so many other modern websites, I don't see an obvious reason why e621 is an exception.

Second, are there already any plans or decisions regarding this feature? If the devs have specifically decided against ever re-adding tag subscriptions, I can accept that. Conversely, if there is already a plan to add them, I would be thrilled to wait patiently for it.

Two more points: If added, I'd like to request this feature be available to all users, rather than just privileged accounts as it was before. Also, I'm aware that some third party tools offer similar functionality, however, platform support is much narrower for those than a native site feature would be, particularly on mobile devices.

I think you're allowed to search up to 100 tags at once these days. As a stopgap, you could save a bookmark for a search for every tag you want to subscribe to, with each one being preceded by a ~ character (which means only one of the listed tags needs to be present in a search result).

bitWolfy

Former Staff

wat8548 said:
I think you're allowed to search up to 100 tags at once these days. As a stopgap, you could save a bookmark for a search for every tag you want to subscribe to, with each one being preceded by a ~ character (which means only one of the listed tags needs to be present in a search result).

Up to 40 tags.
That method is more or less how my userscipt checks for subscription updates.

It broke at some point, so I suppose it was difficult to maintain.

Pasting your searches on your profile or bookmarking them is almost the same functionality. Just making a list of artists and tags can help you immediately, since you would need to do that either way.

The bookmarked search idea is something I considered, but it's awkward and limited at best. I haven't tallied them up, but I think I would surpass 40 tags fairly easily. Somebody has deleted the wiki page since my original post, but according to it, tag subscriptions had a 200 tag limit, which is far more usable.

Additionally, I use private/incognito browsing and don't keep any bookmarks of this type of content. (This is another reason why userscripts and such are difficult.) Bookmarks also don't sync across devices without going to extra effort and possibly risking personal privacy.

Pasting it on your profile avoids bookmarks. If it's just a list of artists you like, I doubt anyone here would care.

{{~artist1 ~artist2 ~artist3 ~artist4}}

I think tag subscriptions had a 20 tag limit, and up to 5 sets of them. The search revamp is a major improvement. We can do very complex searches now, or do the ~ thing.

You could group sets of 40 artists and categorize them by theme. For example, if you like some predominantly scalie artists, put pikajota and similar artists in a group, and so on.

History:

Feature was broken and forgotten when I joined the team. It was set to run every hour, and sometimes would start, and then take 8+ hours to run. Even with only a few people using it. The cost of running it was enormous, and the people that did use it, didn't look at the results for their searches very often. So it was more expensive to maintain than just having them run a normal search. It also didn't scale, would never scale, and was fraught with design problems. Instead of continuing to promise a broken feature that couldn't reasonably be fixed, it was removed from the codebase over time.

Rational:

Personalized feeds are expensive to maintain, there isn't many ways to avoid that. Either the cost goes into maintaining the list in the hopes that it will be looked at, or into creating the list when it is looked at. For complex searches with hundreds of artists, they quickly become too expensive to maintain for the full population of the site.

Letting people run targeted searches that I know the site can withstand, as they want them, works out better.

Thank you for the detailed response KiraNoot, I think that answers everything I wanted to know. I still hope somebody can find a practical way to implement this in the future, but I'll let the issue rest for now.

  • 1