72
Is kbin.social anti-corporation? Should it be?
(kbin.social)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 23 Jun 2023
72 points (100.0% liked)
/kbin meta
38 readers
1 users here now
Magazine dedicated to discussions about the kbin itself. Provide feedback, ask questions, suggest improvements, and engage in conversations related to the platform organization, policies, features, and community dynamics. ---- * Roadmap 2023 * m/kbinDevlog * m/kbinDesign
founded 1 year ago
It seems unlikely to me that corporate instances would ever actually federate in good faith.
They may appear to be compliant initially, but in the long term they just have different goals.
I'm not sure where exactly the line gets drawn, but at the far extreme, I say we treat money-making instances as bad actors. If they stand to gain profit from their actions, they need to be defederated to prevent the sabotaging or enshittification of the fediverse.
@Biscuit Very reasonable question!
I highly recommend this article, How to Kill a Decentralized Network (such as the Fediverse) by Ploum as a relevant factor in this discussion. Even if there's parts you disagree with, I think that's worth discussing too!
To grossly oversimplify the contents of that article, I think federating in bad faith could look like:
@Biscuit Right!?
This is a slight tangent now, but Tik Tok's Enshitification by Corey Doctorow describes another great example of long-timeline corporate "playbooks" or patterns that are... not good but increasingly common. That's where Reddit seems to be going unfortunately, but at least we can see why.
That's a good breakdown, thanks! The bad thing is that I could see these issues happening even unintentionally, with the fact that we have a few large instances vs. many smaller ones. So far we seem to have everyone running the same code, straight from the repositories (at least functionality wise). For my own kbin instance though, I have technically changed things. I changed some code to make a custom logo appear nicely, I've added some padding here and there, etc. I have also thought about implementing an automatic job that clears posts tagged with 'nsfw' or other related things in the microblog feed.
I might implement that, and then submit it to the kbin devs if it works well. There's no guarantee that other admins/devs would do that as well. If they implement a feature that makes their community more popular, they would seem to have incentive to keep it private. And that's where stuff like Meta comes in. If they implement rigorous content filtering, I doubt that would make it into the actual AP protocol. It would be the differentiating factor between using their 'safe' instance, vs. going rugged on an independent instance.
They could say "we implement the ActivityPub protocol as specified" and they wouldn't be wrong. They would just have some extras added onto the top to make their experience more polished. Easy to do when you are a for-profit and have plenty of devs. They would just argue that those are the features that make their interface different, like kbin and lemmy are different.
The only way around it is for communities to agree that they will run the software as released, maybe with only cosmetic changes. Any improvements to functionality should be submitted to the devs so that the wider community can benefit.
Kbin and Lemmy are licensed under the AGPL, so instance source code changes are required to be shared with those that connect to that instance (I assume that includes peer instances as well as users). Corpos can make their own proprietary instances, but they'll have to start from scratch and not just piggyback on top of our work.
For example, federating with the intention of driving other instances out of existence by dominating the space.
Well I clearly missed something!
that's not an example, intentions dont matter if they cant act on them. How can they act in bad faith?
draw users in with piles of money and way better exposure, then get everyone on board with your well ran service with good ui and 100% uptime. Play nice with everyone else, meanwhile gaining dominance on the fediverse. Get a very large userbase in comparison to everyone else. Now, once you gain that dominance, you basically control the fediverse. You can steer it anyway you want. You could even defederate with your userbase and enjoy your new found network built on the back of the community.
Maybe true. What of a money-making instance that was a B Corp, or a non-profit (moneymaking but aligned to a purpose?) I think there might be space for something along those lines?
@Melpomene I'm concerned about the B-Corp getting big, but staying profit driven. Imagine if Steam had an instance. That seems... fine, I guess, for now. But then let's say Steam suddenly acquires the entire video game industry lol. That's definitely a problem. But what if they do it over.. 12 years? At what point are we supposed to realize we're frogs getting boiled?
And non-profits, yeah, you're probably right that they should be fine.
But okay, do you know MEC? They were initially Mountain Equipment Co-op, technically a non-profit. Now they're Mountain Equipment Company, a retail store, but most customers barely registered the difference. This type of thing concerns me lol.
I think B Corps and non-profits can be allowed to make magazines here, that's fine. They just need to follow our rules. They won't like it, but no risk of Fediverse collapse ever, and honestly it's probably best if we get to hold them accountable this way.
A fair point re priorities shifting, for sure. Though we'd run into the same problem if a super popular instance decided to sell its instance to, say, Google. There's nothing stopping that from happening, either. Bad actors are going to act bad; we just need to figure out how to mitigate their impact.
I have a fair bit of skepticism re nonprofits too. But beyond defederation, there's not much we can do to stop anyone (including Meta) from operating in this space.