Increase ethical stance in project - REQUIRE twitter user consent for bot clone to be created
p0sty opened this issue · comments
Context:
Ultimately this project exists to help acclimatise mastodon/activitypub people to the lack of a certain accounts on the mastodon network.
some people create botsin.space bots on a case by case basis, this is another way to do it that is quite ingenious and I respect it. this is sort of a 'as a service' for those type of bot creations. I do know others that do not appreciate it at all.
I think there needs to be some rewording of the "about" to indicate this is a "API level" ethical project, it's following the rules of twitter that allows each BSL instance to exist by using a twitter api.
The mastodon project is so open that even trump attempted to rip it off and all that could really be done is that crediting and the licence be respected - which it reluctantly was.
was all of that ethical? I'd say no, but it was legal.
I'd term this "API legal", rather than ethical, because as is - the user who gets cloned (albeit privately) has no say in its existence. I know you term this a 'plaything' but it's seeing some decent usage, enough to spark some ire in parts to really consider this. I prefer to work with rather than against, hence this request.
I know people who use twitter in a specifically ephemeral way, posts exists for only days or months at a time, then they use bots to delete their posts. this is not uncommon. for these users a private mirror is a form of abusive behaviour as it's against their wishes. I've seen in the readme that the api always links to the twitter content, but does it also mirror the content? I'm unsure, if not i'll remove this from the issue request.
Request:
- re-word the about to be API legal rather than ethical for now
- work towards truly ethical by at the time of clone creation - using the twitter API to somehow ask for consent (mention or dm, I would go for DM personally) from the actual twitter user for the clone to be created. I am betting this ask might be the first time a bunch of people even hear about mastodon, it's an opportunity to put a best foot forward, so the request should be short, sweet and not too technical. yes, people might ignore it. this should be fine. but the ones that don't will be infinitely more valuable until the user themselves chooses to post to mastodon.
If this goes ahead wording can be worked out in thread here.
this way that clone could be public and stop needless duplication and make the project stop being 'underground' - an official mirror will also encourage the BSL instance runners to keep their server around for as long as the user remains on twitter.
a feature could be added that once an agreed clone is set up that the request to create a new one redirect to the authorised one, but i realise this could be hard and require some centralisation, or distributed lists. A public one could also increase interest in mastodon - "there's 30 followers waiting for you over here" type stuff.
what do you think?
Thanks for sharing your thoughts here. 🙂
First, I'd like to show you an article that is 2 years old that was published 6 months before the first release of BSL so that you can see where the idea of BSL comes from, and what the "ethical" part refers to.
Some of my further development is already present in the article, but let me repeat them here too:
BSL isn't "ethical" in the sens "legal": there is indeed a huge difference between the two words, and I really mean ethical in the current state of BSL:
- BSL doesn't provide a publicly available mirror like other mirroring service (that is the most unethical aspect of all the other ways we can find in the fediverse today).
- BSL publishes all data in follower-only mode: so it's not polluting the public TL.
- BSL doesn't copy nor pretend to be the host of the data: unlike the other mirrors relying on some Mastodon or Pleroma fork, if you open the original link of the tweets in your fediverse client... you will be redirected to the Twitter content itself.
- In fact, BSL doesn't copy nor keep any sort of data from Twitter: it only hand it to the fediverse instances. It doesn't clone an account and its content, it only gives access to.
Since this is a huge leverage in the ethical field compared to the current way to bring twitter data in the fediverse, I think it's fair to label it this way: it's just factually the more ethical twitter bridge you can find today (unless you can show me another project I don't know of and that is doing things better).
About the consent part, BSL is a 3rd party client for Twitter, exactly like Tweetdeck, Fenix, Tweetbot, etc. And accessing accounts through any of them wouldn't be defined as "cloning" nor would request any kind of particular consent (since, it's the way intended by twitter in the first place). In the case of BSL, you’re basically using your Fediverse client like a proper 3rd party Twitter client.
The fact that some data may or may not be cached at some point doesn't invalidate the fact that those are just 3rd party client to the Twitter network.
Therefore asking for any kind of consent for something that is completely normal would be very awkward, anxiogenic and may lead to misinterpretation: imagine asking someone on a public network posting publicly if you can read their content, this is not how normal people behave and the recipient might think you’re some crazy person, even if the request isn’t malicious nor inappropriate.
But that’s an interesting aspect, because what is happening to the people that are switching their account in Private mode? I am happy to say that BSL will revoke all followers from the account and prevent the account to be followed again. As it should be on an ethical aspect.
About the life of the data, you’re right: the current implementation (BSL didn’t reach the 1.0.0 milestone, and is still in a beta state) isn’t ethical enough, one enhancement I really like to do - it is on the top of the TODO list - is having an auto-delete for all synchronized data after a certain threshold, for all accounts without exception, and not limited to those that would have set some auto-cleaning bot on their Twitter account.
Federation of BSL instance to limit duplication, help visibility, and other benefits is a really interesting idea and honestly I would love to see something like that been developed at some point, but I have to warn that if it will be made at some time, it wont be by me: doing such development is a huge scale up of the project that would exceed by far the efforts I am able to invest in it. But PR are welcome, and I would be more than happy to help bootstrap any person willing to work on this kind of functionality.
Another cool functionality I perceive in your message would be a “move the followers to this new official Fediverse account” and I would definitively love that. It would be a good addition to the software and would also permit new and popular user to start in the Fediverse with a set of retrieved followers.
I will try to add those ideas in the issues so that it will be more official and visible if anyone would like to help and work on it.
I hope all this will lighten a bit more why I’m characterizing BSL as ethical and what flaws can be fixed and how.
While it might be true that BSL doesn't do anything that a normal Twitter client doesn't do, it still works very differently as a tool. Any other Twitter app is tied to a specific user who can use the API to access Twitter from their own view, their own account. Sure they can search tweets but nobody in a Twitter app manually does that to the tweets of thousands of users to read all their tweets and pass them along to others, who will definitely store them in some permanent form. That's why in a normal Twitter account using a normal Twitter app, you follow people, and that's also what gives people the possibility to respond to that following and say whether they consent to this following or not.
Via BSL, people can follow the Twitter account and be live-notified of any new tweets just like a follower on Twitter would, but without actually appearing in the follower list. This completely removes the consent part from the app. This is something Fenix or Tweetbot simply don't do: other users can decide whether you can follow them or not. BSL is not just removing that consent, either: it is also simply passing the data along into the fediverse, to foreign servers, who can do god knows what with those tweets (including completely storing them for an indefinite amount of time, even if users delete it).
If you want to argue that BSL is as ethical as other Twitter clients, then it's an absolute no-brainer that you need to recreate this ability for Twitter users who don't want their content to be copied and republished on ActivityPub. Twitter allows public accounts to be followed by default, so maybe there doesn't have to be an opt-in - but Twitter allows blocking users as an opt-out. Without an easy opt-out, you're definitely nowhere near "ethical". Period.
One way to establish this would be that the account used for the API requests a) follows all the accounts that it's mirroring to ActivityPub, just like any normal Twitter client would do, and b) announces itself via a @ mention or DM that it's mirroring the content to . Every block not only removes the account from the BSL instance, but also notifies all instances that all posts have been deleted.
Another thing that I would see as mandatory for considering BSL as just as ethical as other Twitter clients would be to allow Twitter users to find out who is following their BSL account, which they currently can't do here but which they can do for any user that follows them via, let's say, Fenix. But that's arguably less important than the ability to outright block BSL and opt-out of it.
Thanks for bringing those interesting thoughts. 🙂
First let me cover the API thing since the way it works define a lots about what's the use that is indented.
In fact, while it's true you can browse the Twitter API with a proper authentication and with the idea of being "on behalf of" a precise user, it's not the only way. Twitter API also allow you to browse and use data with a user-agnostic / user-detached token. And that's what BSL is using exclusively. You have limitations for this usage tho, but that's why BSL have a limited ceiling of calls (it would be much higher if I'd permit people to login) and the data gathered this way it's precisely aimed to an usage that isn't related to a precise identity.
About the 3rd party app aspect. It's true a lot of clients mimics the original Twitter UI and pushes the "authenticated user" paradigm as far as the original one. But that's not a mandatory use of the API, in fact, I would argue that the value of 3rd party app should be to experiment and going on other roads to gather, aggregate and present data. For example a 3rd party app that would display some particular content based on music, pulsation, random events on earth and on a non-linear display (graph? VR?) are legitimate use, even if they don't follow the usual "follow to display live data" paradigm. It's true BSL doesn't strictly follow this paradigm too, that doesn't mean its non-ethical nor illegitimate.
(Twitter even provided an RSS stream per account in the old days, that would behave exactly as BSL is behaving today. It was removed with the obligation to use (only) the API, that BSL is currently totally complying with).
For the issue that data could be read without following, well that's how twitter is designed and if you don't like it the solution isn't the block functionality (since anyone can logout and refresh the profile): it's the protected functionality (that enforce being a follower to be able to access the data). I'm glad to say that BSL is really sensible about the protected aspect, and if any account is found to be set to this protected state, the mirror is disabled and all followers kicked out, even if it's a temporary switch. It's a radical design because it's a clear signal from the user that they don't want to have their data available publicly, while the blocking functionality isn't really that since there is many (and very easy) ways to get around and still get access to it.
About the control over data, that's true rogue server could ignore deletion, and it's definitively an issue. But that's an Internet flaw and has little to do with BSL exclusively. Currently, any content published publicly on twitter can have a longer lifecycle than expected: after all any tweets can be archived with web.archive.org and therefore being available even in the case of deletion (without any use of API or 3rd party service). Same for search-engine caches, user screenshots, etc. By essence, public data on internet is public with very little control on it once it's out.
I know proprietary social networks gave a false sens of control over data to encourage people to give data and information they might not otherwise, but that's a lie and clearly not the case technically and legally speaking (it's covered in the EULA that no-ones read). But please don't shoot the messenger here, I agree it's an issue and instead of trying to hide it, we should speak openly about it and make people more aware of this fact.
That being said, those considerations are also the reason why I decided to post on follower-only mode and orientated many other design decision to get an "as good as possible" service, there is some limitations, sure, but since they're less problematic than the official service itself (that can be archived/indexed) I don't really agree it's so much of an issue.
Hi, as an alternative idea, I've run into a bunch of semi-famous people who migrated to mastodon recently who started acting quite worried over being impersonated, and it's turned out to be Birdsite live.
It might help calm some nerves if the profile pages generated by birdsite live clearly indicated that the site was hosting a bot or unofficial mirrors.
Yes, I'm planning enhancing this aspect since newcomers doesn't see the "bot" aspect of the profile and lead to a lot of misunderstanding.
Yeah all the sudden attention for mastodon from former blue checks seems to have left them feeling a bit neurotic about losing their official validation.
Once I figured out birdsite live was just an unofficial mirroring tool, I've tried explaining it, but not everyone has understood.
Heck I should probably read the documentation on how to actually use birdsite live because it'd be nice to get some of those national weather service or fire department alerts that are currently twitter exclusives.