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 thanks for the heads up. I just blocked them for my own account, hopefully that will stop them. I really felt some type of way when people tagged them in my threads. Like, no. Ask me to publish the thread on my blog, if you want. But don't ask someone else to steal my stuff, without my consent, while all I can do is sit back and watch helplessly as it happens...

@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 Yeah, I understand that why those tools are attractive. Ephemerality and a clear commitment to non-monetisation would help, but the real problem is lack of consent.

@amv I see. Perhaps a more complex logic of "someone requested your post to be unrolled, click ✔️ to accept, or consider posting a long-text version in a more readable format".

Not nearly as effective, but at least, as you say, is consent-first while also nudging people to go back to good ol' blogging :)

@astrojuanlu Yes, I think something like that--with the unroll only available for a fixed period of time, on a noncommercial platform--would work for me.
@amv @astrojuanlu is ephemeral a hard requirement? That would mean more unrolls are needed every time someone wants to read it. But a delete call by the author would definitely needed, to revoke given consent. Just fiddling with ideas.
@amv @astrojuanlu Given how the web works, and given Mastodon has different toot privacy levels - is a public toot with a permalink, not in some manner - expected to be seen without explicit consent ( otherwise the federated timeline seems a giant-violation of consent).

@talios @amv @astrojuanlu if that is not the case, republishing e.g. boosting could be argued to be copyright infringement.

As that would be silly, I assume (but have not checked) that like most online services, the Mastodon ToS state content may only be uploaded on the condition that the site and its users are granted a license to reproduce the uploaded content.

You would have to read the ToS to see now limited the license is e.g. is it restricted to within Mastodon.

@kasilas @talios @amv Well, it's clear from this converation that whoever implements this, they have to do it in a way that the content is not copied over anywhere. Likely a client-only extension, with some JavaScript magic, that displays the thread in a simpler way. Consent would not be needed and IP concerns wouldn't be there anymore.
@astrojuanlu @talios @amv yeah that sounds a reasonable solution that avoid most IP concerns.
@kasilas @astrojuanlu @amv that would probably work for threads (the original topic) but maybe little else
@talios @astrojuanlu @amv I'm going to guess that some solutions are also patented, whilst this is almost irrelevant for workarounds, it might stop mastodon rolling out a solution.
@astrojuanlu @amv I never understood *why* they were useful though? Twitter had bookmarks and proper threading long before the first thread scraper service showed up. Every tweet has a unique URL that can be shared without needing to go to a third party site to find it. What actual benefit did those services provide to anyone?
@astrojuanlu @amv (same arguments apply to the Fediverse as well, those services don't appear to add any value here for the same reasons)
@johnchivall @amv It's basically a "reader view" (https://support.mozilla.org/en-US/kb/firefox-reader-view-clutter-free-web-pages) for tweets/toots. When reading long threads, the constant paragraph breaks, datetimes, engagement numbers, author photo & biography, repeated over and over again add a huge amount of noise.
Firefox Reader View for clutter-free web pages | Firefox Help

Firefox Reader View removes web page clutter to improve readability. Recent Firefox versions can also read pages out loud.

@astrojuanlu @amv ah, fair enough. I'd never considered them as an accessibility tool like that as most people I saw using them used them as bookmarks (and would share a link to the thread reader rather than the original tweet)
@johnchivall @astrojuanlu @amv I shared this confusion! Probably because I always used Twitter via third-party clients.

@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.

@astrojuanlu @amv This is something I'm interested in knowing (and this now become circular and meta), but I'd commented on a feature request for Mailbrew about Mastodon support ( it scans feeds to surface web links you may have miss in a daily email digest).

I referenced this (public) toot about the communities dislike to scraping bots - so hopefully there's some way a happy medium can be devised - that both helps users, but protects tooters.

@amv this is rather more interesting than most prev scraping stories cos threads are a pain - is there hope of a native Masto thread unroller?
@lilianedwards I can see the need for something like that, but I am not a dev, so I cannot answer that question.
@lilianedwards @amv as someone who never wrote twitter threads and have only done the odd one on mastodon. What's painful about them.
@basil @amv cross posting doesn't work - saving to incorporate into articles etc later is laborious - similarly DMing it to colleagues - I'd far rather ppl wrote a blog most the time but as they don't, it's v useful

@basil if they're long, and you have slow net? it gets annoying having to wait for the rest of the thread to load as u read along lol

beyond that, unroller gives u a more streamlined read, unbroken by handles/display names, comment/like/reply/share buttons every two sentences, etc. it's just visually much simpler & easier to digest for some folks.

think of turning on adblocker on a news article-- suddenly it's not broken up by dozens of ads, and it's much nicer to read.
@lilianedwards @amv

@amv good!
@stephenwhq Just to be clear, my moderatorial powers only extend to protecting accounts on religion.masto.host; you probably should block it yourself if you want your content to not be scraped.
@amv — I’ve never actually seen the point of them myself; I’ve never seen what value they add to the experience of reading a string of posts from simply, erm, reading the string of posts

@amv

Looks look .social is already limiting it.

Thank you for flagging it up. I'm keeping an eye out.

As an aside, is there a way to suspend it instance-wide if no one on the instance is following?

@AspiringLuddite Yes, if you are the admin on your instance, go to the user page, click the three dots on the profile, and select "Open moderation interface" and that will take you to a screen where you can suspend it for your whole instance, which is what I did on mine.
@amv with 5k characters in 1 post, there's no point to it anyway
@amv until I read that thread I couldn't understand the opposition.
@amv
@sam I see yr on mod duty this week, can we get an instance-wide block on the thread unroller account? not sure if that's possible
@amv seems that bot has been suspended by .social

@amv

Looks like m.s did the right thing and just suspended the account altogether.

@amv Luckily for Mastodon it has had working threads for years now and zero need to “unroll” anything

@amv Aside from the content theft aspect, as a reader I've always disliked thread readers. Writers put a lot of work into constructing long threads that convey complex information and ideas in a sequence of small mouthfuls – see e.g. @Limerick1914 whose body of work on twitter is phenomenal.

Hitting a 'thread unroll' interruption kills the appetite to read the rest. Does anyone else find text easier to process cognitively if it's in short lines and punctuated by breathing spaces?

@amv can I repost it while tagging #fediblock for more range?
@amv I've allowed myself to do it at https://functional.cafe/@phoe/109353994585579530 after blocking it from our instance.
Michał "phoe" Herda (@[email protected])

Content warning: fediblock, ThreadUnroller

Functional Café
@amv Thanks for this explainer—very interesting issue.

@amv

I've occasionally (on Twitter) seen authors summon these services themselves at the end of a thread, as a service to their readers.

It should be a reasonably simple change for the owner of the service to only accept requests from the author of the thread. That should address any concerns about permission. Without such a change, your points and actions make sense, of course.