Fediverse

287 readers

1 users here now

This magazine is dedicated to discussions on the federated social networking ecosystem, which includes decentralized and open-source social media platforms. Whether you are a user, developer, or simply interested in the concept of decentralized social media, this is the place for you. Here you can share your knowledge, ask questions, and engage in discussions on topics such as the benefits and challenges of decentralized social media, new and existing federated platforms, and more. From the latest developments and trends to ethical considerations and the future of federated social media, this category covers a wide range of topics related to the Fediverse.

founded 2 years ago

Crosspost: 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)? (kbin.social)

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

8 comments fedilink hide all child comments

I originally posted this in m/kbinMeta: https://kbin.social/m/kbinMeta/t/73476/How-do-kbin-instances-and-all-aggregator-protocols-work-to

Not sure what's the etiquette on splitting discussions, but fwiw here's the key para from my post:

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?

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

[–] asjmcguire@kbin.social 1 points 1 year ago (1 children)

So I'm a bit confused by the last part of this post. The protocol is definitely more than a year old, ActivityPub is not new. By any means. And ActivityPub builds on top of protocols that came before it.

https://www.w3.org/TR/activitypub/
https://www.w3.org/TR/activitystreams-core/
http://martin.atkins.me.uk/activity-streams/

As for the posts that appear in the /m/random magazine, they are basically the same as looking at the federated tab on Mastodon - they are posts that arrive here, because someone else on this server follows that person, or they were written by someone on this server. No posts will magically appear on the server without someone here actively following either a person or a community on a remote server. They appear in random, because they are not attached to a magazine, though if they use a hashtag that does track that hashtag, then they will be added to the microblogging tab of that magazine, instead of being shoved in /m/random

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

@asjmcguire i was talking about kbin. The AP programming language (eta: yes it's called protocol or standard as well iirc) is definitely old :)

The fact that kbin does fetch posts from originating instances without instances having the setting to allow or disallow is a problem once something with the computing power of meta and its userbase comes on board. Because mastodon for example doesn't have whitelists, only blocklists.