71

I'm seeing discussions on other instances about how a "federated" corporate instance should be handled, i.e. Meta, or really any major company.

What would kbin.social's stance be towards federating/defederating with a Meta instance?

Or what should that stance be?

you are viewing a single comment's thread
view the rest of the comments
[-] lml@remy.city 2 points 1 year ago

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.

[-] cacheson@kbin.social 2 points 1 year ago

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.

this post was submitted on 23 Jun 2023
71 points (100.0% liked)

/kbin meta

39 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