In case you’re curious, here’s the practical relevance of tumblr “shadowbanning” for my bot (and thus for me).

• Frank can’t see asks from “shadowbanned” users on her equivalent of the inbox page.
• She can view and respond to these asks, but she needs some way other than her inbox to learn about them.
• I used to just delete these asks whenever I got them.
• Earlier this year, I build a mechanism where I can manually notify Frank about them one by one.
• This is tedious and I have to do it separately for every ask.
• As a result, Frank is slower to respond to asks from “shadowbanned” users, esp. if they’re in a very different time zone from me.

sreegs:

nostalgebraist:

sreegs:

FAQ

Read this before sending an ask. I’ll update it as frequently as I can. If you’re looking to see posts I’ve made about Tumblr, check my #tumblr tag.

Keep reading

You’re not shadowbanned. There’s no shadowbanning on Tumblr. If you can tell something is obviously wrong, then it’s a bug.

It’s not always a bug.

When I asked why asks from certain users don’t show on the /posts/submission endpoint of the public API, I was ultimately told this:

Later the same day, one of the affected users reported that they were now showing up in searches and notification feeds, which had not been true before my support ticket.

So:

• There is a state that users can get into.
• It has various symptoms like not showing up in searches and notifications.
• The state exists on purpose, even if it’s sometimes applied to a given user inappropriately.
• There are spam prevention filters that can put a user in this state.
• The state is commonly (if perhaps misleadingly) referred to as “shadowbanning” by the user base.

Is this state a “bug”? I wouldn’t call it that. It’s meant to exist.

I suppose one could argue that the state itself isn’t a bug, but that false positives in the relevant filter are bugs. Even that doesn’t seem right, though. Every spam filter will have some false positives.

This has existed since at least Feb 19 2022 (before the OP was made), since that’s the date of the earliest example post I provided with the ticket.

Indeed, the public API issue has been happening for much longer than that. My examples start on Feb 19 2022 only because that was the day I finally got around to implementing a workaround for it, which produced logs I could later search.

I’m trying to phrase this as non-combatively as possible, although I don’t feel like I’m doing very well. I’m not trying to start an argument, about this kind of website trivia of all things. Just want to make the situation clear to people.

What this response is describing is probably the user’s trust score, a rank assigned based on whether they seem human and non-spammy enough for certain period of time. Confirming your email will raise the score for example. I’m not sure if these trust scores can be lowered automatically but there might be bugs preventing the scores from increasing automatically.

Could also be a bug with the strike system if they received strikes for trust and safety infractions. I can’t confirm any of this, but it’s my best guesses.

So yes, it is a bug that users get stuck in this state. There are anti-spam and moderation scores that are values on the user and the mechanisms that set them can break or the values could be read wrong.

Thanks for the inside info!

If it’s a bug, it’s one with pretty widespread effects. (I guess that’s what you mean about the website being broken…)

I found 6 affected users this morning, just in my bot’s logs from the past ~2 months. According to my logs, during that same time interval, my bot received asks from 721 distinct usernames in total.

6 of 712 is a little less than 1%. Tumblr’s active user count is in the low tens of millions.

So if my bot’s askers are at all representative of the incidence rate among users as a whole, then as a rough order of magnitude, over 100,000 users would have experienced the problem in the same time period. (Real users – my bot basically never gets asks from actual spammers.)

sreegs:

FAQ

Read this before sending an ask. I’ll update it as frequently as I can. If you’re looking to see posts I’ve made about Tumblr, check my #tumblr tag.

Keep reading

You’re not shadowbanned. There’s no shadowbanning on Tumblr. If you can tell something is obviously wrong, then it’s a bug.

It’s not always a bug.

When I asked why asks from certain users don’t show on the /posts/submission endpoint of the public API, I was ultimately told this:

Later the same day, one of the affected users reported that they were now showing up in searches and notification feeds, which had not been true before my support ticket.

So:

• There is a state that users can get into.
• It has various symptoms like not showing up in searches and notifications.
• The state exists on purpose, even if it’s sometimes applied to a given user inappropriately.
• There are spam prevention filters that can put a user in this state.
• The state is commonly (if perhaps misleadingly) referred to as “shadowbanning” by the user base.

Is this state a “bug”? I wouldn’t call it that. It’s meant to exist.

I suppose one could argue that the state itself isn’t a bug, but that false positives in the relevant filter are bugs. Even that doesn’t seem right, though. Every spam filter will have some false positives.

This has existed since at least Feb 19 2022 (before the OP was made), since that’s the date of the earliest example post I provided with the ticket.

Indeed, the public API issue has been happening for much longer than that. My examples start on Feb 19 2022 only because that was the day I finally got around to implementing a workaround for it, which produced logs I could later search.

I’m trying to phrase this as non-combatively as possible, although I don’t feel like I’m doing very well. I’m not trying to start an argument, about this kind of website trivia of all things. Just want to make the situation clear to people.

cyle:

nightpool:

nostalgebraist:

Someone sent Frank a very long spam ask containing approximately 15755796 characters of text.

That’s around 300 times as long as the Bee Movie script. If you save it as a text file, it’s around 16 megabytes!

This seems like, uh, not something that should be possible? It even affected the UI adversely – my askbox page took like 20 seconds or something to load.

hmm, this article seems to indicate that it should only be possible to include 4,069,000 characters worth of text in a post (1000 content blocks * 4069 characters per content block). Maybe there’s a discrepancy because of multibyte Unicode characters or something?

hmmm the max post size (not including media) in total is supposed to be 1MB, so yeah, that’s not quite right…..

Turns out I miscounted the file and character size. (And in a really dumb way – used grep on my log file and forgot the offending string would have appeared multiple times, lol)

Anyway, the actual length was 2621440 characters: 640 content blocks, each containing the letter “e” repeated 4096 times.

This is below the character limits @nightpool mentioned. However, it’s still more than 1 MB of text (it’s ~2.6 MB).

changes:

Changes to Tagged and Search URLs on Tumblr

Heads up! We’re changing the way we parse URLs on tagged and search pages, to properly encode/decode them to support spaces, hyphens, plus signs, and underscores. Most of these changes will be invisible to you, but if you’ve kept bookmarks or links to tagged and search pages on Tumblr or your blog, read on!

We’re going to start this process by rolling out a new setting you can enable when customizing your blog on the web:

ALT

What does it do? Today, and with that toggle disabled, going to a blog’s tagged URL like https://staff.tumblr.com/tagged/tumblr-tuesday would turn “tumblr-tuesday” into “tumblr tuesday” and you’d see posts with that tag. Same with search URLs. If you have that toggle enabled, that https://staff.tumblr.com/tagged/tumblr-tuesday URL will be decoded as “tumblr-tuesday” instead. If you want to link to the “tumblr tuesday” tag on your blog, you’ll have to use “tumblr%20tuesday” in the URL. But this means that if you use certain special characters in your tags, you’ll now properly be able to link to them!

The toggle above gives you early access to figure this all out. On December 1st, 2021, we’ll be enabling this behavior for all blogs on Tumblr.

We’ll update all of the links when you click on tags in Tumblr. However, if you manually added links to your tags in your blog description, theme, somewhere off Tumblr, saved bookmarks, or in posts (like a pinned post on your blog), then you’ll need to update those links if they contain spaces, underscores, or hyphens. Spaces in tags will now be encoded as “%20” rather than “-” or “+”. To do this, turn that toggle on, and click around on your tags to see if any of the URLs changed. Having this setting enabled and updating any links you’ve saved somewhere will future-proof you for when we roll this change out site-wide.

ALT

We hope this is great news for anyone who uses tags in specific ways (we see you!) and has been frustrated that the way to link to them has been inconsistent, or just plain not working since… forever. We’re working on several fixes across Tumblr related to these inconsistencies, but the majority of them require no action on your part.

Please hit us up via Support if you have any questions or concerns about this!

I’m happy that this issue is finally getting some attention.

That said, I’m not happy that the proposed change will break all external links to tag pages, except the ones for tags that are one word.

I know this is a pretty trivial-seeming thing to get worked up about, individual cases of linkrot always seem like that, but when it accumulates and accumulates … linkrot is Bad.

What if, instead, there was a new route for this new behavior, like “/tagged/v2/tumblr%20tuesday”?

The old route (without the v2) would stay functional until it’s time to switch over.

And then the switchover would consist of simply turning the old route into a redirect: “/tagged/tumblr-tuesday” now redirects you to “/tagged/v2/tumblr%20tuesday”.

This seems conceptually feasible, at least, although there may be technical or organizational blockers to it that I don’t know about.