"Meta creating an account or an instance is really not an effective way to conduct a surveillance operation ...not on an infrastructure that has oodles of open APIs that make it far easier to collect data using direct connections vs creating an instance. "
While i agree thwt survelance probably isnt their biggest goal it is important to note this would be the only way to datamine your follower only, dm, and private content. Without an instance there is just no way to get at that data.
That said i woukdnt block meta for the sake of it.
True, that the small amount of data that users private DM's or posts they mark as "to "followers only" etc would not be publically scraped - but for most users everything they think of as their social graph is already public and likely scrapeable by Meta or others building LLM's or other datasets.
Simple point: defederation is simply does zero to stop data mining of all of that. So defederating to stop it is a moot question.
No need to edit. I even agree that defederation ks not the way to handle it. Just say it does legitimately give them access to tons of your data thry couldnt get through the apis directly
@tchambers@freemo@jerry but it is the tool to keep all of that garbage out of my timeline, thank you? I don't want to be associated, even remotely, with fash platforms.
Id argue no, it isnt the best tool for that. Shared instance block lists accomplish that at a user level while still giving the user the choice. So a much better tool imo.
@anantagd@tchambers@freemo@jerry Facebook and Twitter are run by fascist enablers and they will refuse to effectively moderate just like they always have. At a bare minimum they'll use their status as a big "default, tell your dad to use it" player in the Fediverse as leverage for their own profit or to crowd out other instances, otherwise there would be no business case for doing it.
Anyone not realizing this is a collaborator and I question why they joined fediverse in the first place.
@freemo@tchambers@jerry "My users" says it all, really.
And: do you really wish to associate with a platform that was a major cause of the Rwandan genocide? A platform that used and sold its user data to influence Brexit. To push Trump to the WH, and basically schooled its users to normalize fascism and accelerate it. No moral qualms at all? It's just a matter of functionality?
I have plenty of qualms, which is why im not on their social media.. its simply not my place to force my iews on my users. They are responsible afults and can form their own opinions, and have historically they have made great choices in that regard.
They are the users who choose to trust me with their digital freedoms. Thus "my users"... if your going to try to do mental gymnastics to turn that into something negative waste your time somewhere emse
And no i never said it is abuse to block a bad server, in fact i said i completely respect and am ok with you choosing that for your server, nothing wrong with blocking them, in fact id strongly encourage my users to bloxk them if they wish
@tchambers@jerry I'd like to hear a legal expert's opinion on the feasibility and enforceability of any legal language that has the intent to limiting what remote entities can do with the data on an instance?
Plus look at the most common example of EEE working: For RSS, yes Google's Rugpull sucked for RSS readers but the tech morphed: and now both moved to be ubiquitous in server-to-server and now RSS via podcasting has taken over the world.
EEE against Linux FAILED. EEE against Podcasts by Spotify FAILED.
EEE Mostly fails. And the only real defense is a vigilant and active developer community of OUR OWN. Not defederation.
@tchambers because my conviction is that Meta does need to be pre-emtpively struck with a block. The finger on the button wouldn't protect me at all. So I'm happy I'm on a server that won't federate. I would have left otherwise. Good luck, Tim
@tchambers@erlend decided coincidentally and for other reasons to migrate to Indieweb recently, and seeing these takes makes me happy with that decision. It's a sensible approach.
Q. Won't this flood our Fedi servers? Won't if flood my feed?
A. Who knows til it launches what it is at all: but if it is their own server:
No, users won't crush our servers - all the P92 users will be hosted on P92 servers... and No your feed won't see P92 users * unless you choose to follow them * or if your friends choose to boost them into your feed....but ALL TOOLS for blocking, muting, etc, all exist now for that.
Not exactly. Assuming P92 is like any other instance, P92 content will be federated to local instances and if you follow a P92 user, a copy of their content will be stored on your instance server. Also, if P92 users follow you, a copy of your posts will be sent to the P92 servers and stored there. So there will be incremental load on every instance that federates with the P92 server. If it is a huge instance, it will add significant communications and storage loads. Right?
@tchambers A more problematic issue is content rights. What sort of license will #Meta be extracting from P92 customers? If it is a a license similar to the Facebook, Twitter or Bluesky license they will be assuming a broad license to the content. It may be the case that any Fedi entity that federates with them is committing the shared content to the license terms. This will not be acceptable to the Fedi community at all. You can't license my cat picture to Mark either.
@mastodonmigration Well a fair question and one worth watching. I think BS has pledged to change their license too so need to look and see if they have.
Not to put too fine a point on it, but what are the content rights that any mastodon server operating under right now?
Because that answer is not clear for the vast majority of them.
But no, whatever the license terms are for Meta and their users doesn't matter just because your service "federates" with theirs. Not unless there is an active decision made to abide by the terms of their API which is signed somewhere by someone who has the right to sign.
@hrefna@tchambers The content rights that mastodon servers generally operate under is defined in the Privacy Policy of the instance. The standard Privacy Policy simply describes the use of the content and therefore creates a very narrow implied license for such use. The problem with big corporate social is they tend to extract very broad licenses with the right to sublicense for any content they host.
The privacy policy for my server says what my server is allowed to do with. Not what any other server in the fediverse is allowed to do (unless it says otherwise, explicitly).
To the extent other servers may operate under an implied license or fair use contract, it doesn't change the terms under which I published it. There is no agreement in place that "to use this API you must agree to these terms" that the person who has the right to do that has agreed to.
If I write BSD code and you include it in your GPL'd code it doesn't change the license that my code is originally under.
My agreement is with my server. It doesn't change the license my content is under just because my server has a deal with someone else, and it certainly isn't changed just because they make an API call without any such agreement.
I'm curious what corner of contract law you are looking at that says otherwise?
@hrefna@tchambers Just saying that sending Fedi content (user posts, pictures etc.) to a #Meta server is not going to give them a license to the content other than the implied fair use license under which the user posted the content to their Mastodon instance. #Meta will not be able to exploit that content as they do with content they get from their users. They will not want this to be the case and therein lies the rub.
@mastodonmigration@hrefna@tchambers The privacy risk is something like Gmail: your email may be private, but Google has a copy if you sent it to anyone hosted at Google, thus feeding data analysis and the surveillance machine. But then, the public posts on Mastodon are public, so they already feed that surveillance machine.
@hrefna@tchambers Right, but you still hold the copyright. You did not give anyone a right to sell or otherwise monetize your content. What social media companies do is mine your content and sell data about you to ad tech companies, among other things. #Meta does not have a license to do this with your content. Suppose they can just display it, as per fair use, but that is not how they do business.
@hrefna@tchambers As you point out this only would apply to content that they acquired from someone who had the authority to grant such a license, and whomever bridged the content to #Meta via federation may not have that right.
So now #Meta has a problem, because they are hosting content to which they don't have the kind of content rights that they need in order to monetize the content.
So #Meta will have to find a way to gain content rights to your content by maybe requiring instances that they federate with to get licenses with the right to sublicense from their users.
@mastodonmigration@hrefna As with everything, we will see. But highly doubt any activitypub server from any entity even them would require licenses. But again, time will tell.
A. I agree with Darius here: even if the "rug pull" happened, we would almost certainly be no worse off:
"Regardless of bigco shenanigans around open protocols, Kazemi isn’t worried ...'The nice thing for me is that if the big companies do jump in [to support ActivityPub] and then sort of walk it back,' he remarked, 'at worst, we’ll be back to where we are right now, which is still a pretty nice place.'”
Q. Doesn't federating leave us open to an "Embrace, Extend, Extinguish" strategy like XMPP and FB or Google, or RSS and Google Reader? If they rugpull support won't that hurt developer momentum?"
A. Firstly, to my view a mass defederating of Meta PREMPTIVELY would explode trust to developers that ActivityPub would reliably be there - if they could be blocked before they launched any service at all. This would spook and drive away more developer than any "rug pull." #project92
@tchambers remains the very moral question, Tim Chambers. Do you want to associate at all with a platform that was a major cause of the Rwandan genocide? What you'll tell developers is : we don't associate with eugenicist fascists. That would reassure me because then I know that "developers" won't develop their eugenics and fascism inspired " AI tools" off my musings here.
I don't think admins should preemptively block Meta if they don't want to. But at the same time they shouldn't be discouraged from doing it if that's what they believe is in the best interest of their community.
@gulovsen OK so of course, admins are free to do what they think best. I'm making the case to my users and to other admin that this is the wisest course.
@LightTheUnicorn Agreed, each admin makes their own call and I respond those who choose differently, but as I lay out in this thread, I also think that is a position that is ultimately weaker in protecting their users.
@tchambers With all due respect, why do you hope "all #fediadmins to consider taking this same policy"? It's not up to any one individual admin to tell all fediadmins what they should do or consider. Diversity is the point.
@tokyo_0 I definitely respect any admin who makes a different choice, but feel like it would be ultimately self-defeating to the goals of better protecting their users. For the reasons I put out in the thread.
@tchambers That's a great thought...but in reality what if #P92 (ps: not P95) starts inserting ads in the text of people's posts...that then appear in everyone else's TL's if you boost or reply?
@jann we would definitely block individual p92 based accounts pushing ad based posts to our users, as we do now on accounts that do from other servers.
@tchambers Just curious: Why do you think the server admin position is "stronger" when blocking meta later instead of right away? That is a weird assertion to me...
Add comment