I see that @[email protected] has made it to Mastodon. I have suspended it from religion.masto.host, and will suspend any other content scraping bots I become aware of.

Thread readers scrape content without the consent of the creator, move it to a website outside of the creator's control, and sometimes monetise it, as discussed here:

https://twitter.com/erynnbrook/status/1099086911463800832

Erynn Brook on Twitter

“Why I don’t like thread compilers: a thread. Please do not compile. I’ve blocked threadreaderapp and it won’t store my threads.”

Twitter

@amv In case others agree with this take, is there a way a "thread-unrolling" bot would look appropriate to folks? For example if the content was ephemeral and the site ran no ads?

Many people used the bot on the birdsite not because they wanted to exploit creators, but because they found it genuinely useful. I'd love to see discussion of how those useful features can be baked into the #fediverse in a consensual, friendly way.

@astrojuanlu @amv To my understanding, this "unrolling" is about how a thread is shown. This is very different in the user interfaces I use (web UI, Tusky, Twidere). Tusky has a rather nice looking approach and I would suggest that an "unroll" feature should be placed in the web UI or client, like we have "print view" on some websites there could just be an improved thread view.

I do not see any reason to involve a third party here.

@mhaseneyer @amv No reason except that clients don't support that yet. The work has to be done somewhere, either an official client or a third party

@astrojuanlu @amv A third party has to deal with the issue of missing confirmation from the author to use their content.

Also, when publishing something and being bothered/nudged by maybe multiple of these bots/services to provide my approval, this imagination scares me.