/kbin meta

4 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

How do kbin instances (and all aggregator protocols) work to maintain privacy and safety? What can we put up on the roadmap (when there is one)? (Instance members at least; ppl posting on fedi in gene (kbin.social)

submitted 1 year ago by cendawanita@kbin.social to c/kbinMeta@kbin.social

17 comments fedilink hide all child comments

This is going to be kbin focused because that's the infra I'm most familiar with, but if any part of this is relevant to Lemmy and other upcoming aggregators it's worth a think too:

in the more microblogging part of fedi, it's been about week and some of active discussions because of the reveal that FBMeta is developing its own Project 92, or Barcelona, a competing service to Twitter (called Threads) that supposedly will be using ActivityPub
it's followed up by confirmation that there's been overtures to those running big (in size) instances esp on the Masto protocol to meet (Eugen never confirmed but in deleted posts talked about the idea of a meeting even with NDA positively; Universeodon definitely confirmed taking a meeting. Universeodon admin also runs a threadiverse instance (kbin). No one else, and in fact more confirmed they didn't: Dan who does Pixelfed and runs the Fedi database; Chris who's one of the admins of calckey.social; Jerry who does infosec.exchange and also runs a kbin instance)
the big discussion is if then Fedi instances should federate with Threads. There's a Fedipact now of those who won't and will outright block. There's more who's being cautious and have decided on preemptively silencing (so conditional following). There's those who wants to wait and see.
I'm bringing this over to the kbin side because of the three concerns: political (extend, embrace, extinguish playbook means standards-setting work will be under threat of an eventual oligopoly); privacy (data scraping and surveillance capitalism is a known thing, legal or otherwise); and infrastructure (the full blast of new Threads accounts and the way AP and esp Masto does JSON will mean the perpetual fetching will overwhelm smaller instances) - the most particular for threadiverse is on technical capacity.
most instances are still finding their feet. What measures are already in place short of defed to help admins not get overwhelmed? What measures are being worked on?
kbin does scraping posts very well. Even untagged posts end up here on kbin.social because the 'random' magazine was created. What can instances do to not become a risk vector for at-risk persons who probably didn't realize this protocol (that's not even a year old) has been quietly slurping their posts in machine-readable forms all this time?

I've been super enjoying my time here, and if i know where we can collectively stand on this, it will take a load off of my mind.

you are viewing a single comment's thread
view the rest of the comments

[–] 0xtero@kbin.social 4 points 1 year ago* (last edited 1 year ago)

My two federated cents:

political (extend, embrace, extinguish playbook means standards-setting work will be under threat of an eventual oligopoly);

Bringing over potential 1.2bn users is going to change the landscape. We'll get access to brands, advertising and influencers. New people tend to gravitate towards larger instances and Meta will make sure they market Threads heavily. This will be a huge concern for those that want to see fedi "succeed" (in terms of popularity). Meta doesn't really have to do anything malicious. Just by existing, they'll attract most new people who would have gone to mastodon.social or pixelfeed otherwise.

For me, personally - it's not an concern. I'm fine with instances with far less people. I'm not here to see fediverse "succeed". In my opinion more people isn't the same as successful service. In fact the best communities are just around 150 engaged people discussing the stuff they love. Dunbar's Number is important here. I like high signal with minimal noise. For me, fedi is just that right now. So I'm firmly in the "defederate the shit out of Meta"-camp (also because it's a shit company, with shit people).

privacy (data scraping and surveillance capitalism is a known thing, legal or otherwise);

Meta/whoever can do this already today, and they don't really need much for it. They certainly don't need to develop a whole new service for it. The fedi is full of public APIs. Mining and surveillance is easy to do and hard to detect in federated environment. If someone wants to be malicious, there's really very little we can do to stop them. So apply that to your personal threat model when you post.

But in general I'd like better moderation tools - being able to control where my stuff ends up, how long it lives and what I see in my feeds is a priority for me. Fedi services have been historically very bad with this - we should be better. Mastodon has nice features like auto-delete content based on time, filter incoming messages based on hashtags, words etc - we should have them here on kbin as well.

infrastructure (the full blast of new Threads accounts and the way AP and esp Masto does JSON will mean the perpetual fetching will overwhelm smaller instances)

This is my biggest concern. The ActitivyPub implementations in fediverse are a hot mess of inefficiencies and bloat. Especially at Mastodon. One "viral" toot will generate silly amount of traffic in federation status updates. It's a shitty situation with a potential to "DDoS" small instances or overwhelm them with hosting bills. Especially if the population explodes to +1bn new users suddenly.

This would suck.