this post was submitted on 07 Jul 2023
64 points (79.1% liked)
Lemmy.world Support
3236 readers
3 users here now
Lemmy.world Support
Welcome to the official Lemmy.world Support community! Post your issues or questions about Lemmy.world here.
This community is for issues related to the Lemmy World instance only. For Lemmy software requests or bug reports, please go to the Lemmy github page.
This community is subject to the rules defined here for lemmy.world.
To open a support ticket
You can also DM https://lemmy.world/u/lwreport or email [email protected] (PGP Supported) if you need to reach our directly to the admin team.
Follow us for server news π
Outages π₯
https://status.lemmy.world
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
It's starting to look like the capacity for a user to independently defederate their content from specific platforms is in order. Even better would be the capacity to select what specific content is federated where when publishing.
I personally want nothing to do with Meta, but I'd prefer to have the choice rather than having it made for me by the admins.
Agreed. I am already blocking communities I don't care for all the time but sometimes it would be much easier to be able to just block their entire instance (because the whole instance circles around the same type of content). I won't be able to find one single instance the federated with just the right others for my taste so let me just filter myself.
Blocking and defederation are not the same, just to note. If you block someone, I'm pretty sure they can still see your stuff. You just can't see them. Defederation would actually stop them from seeing your stuff.
Defederating doesn't stop Facebook from seeing your posts. It stops you from seeing theirs. Everyone seems to have this the wrong way around
You are correct. I did get it backwards in a few of my comments. Thanks for the correction.
I don't think that's true, because we a world user I can still see things posted on Beehaw. They just can't see anything I reply with. So, if our instance defederates from threads, we won't be able to see their posts but they will see ours.
You can't have an instance that runs on your personal set of preference unless you run your own. Somebody else went to the effort of buying a domain, hosting, handling moderation on their own time, and everything else that comes with running a fediverse instance, so if you sign up to that instance, you get to deal with their rules.
Even if you found an instance which suits your desires--which ultimately amounts to being essentially unmoderated, since you don't trust an admin to be in charge of moderation--you'd find it getting defederated by other instances because bad stuff happens in unmoderated spaces. What you're asking for, an instance which can access everything at all times, is fundamentally incompatible with the nature of the fediverse. I'm not being glib, but if that's what you're here for, you're in the wrong place.
That's not at all what I'm here for but okay.
It sounds like you are, because if you want a place where you alone are in charge of what content gets blocked, what you really mean is a place where nothing gets blocked by the admins, so that it's all up to you. If you want to be in charge of everything you see, all of that content must be allowed to reach the instance, i.e. it must be unmoderated and federated with everything.
I don't get how you arrive at that conclusion. All I want is for me myself to not see certainty content I don't care for. Here's an example: there's an nsfw instance that is federated with my instance. I don't mind that at all. Great content for many people I am sure. But it seems to mostly be communities for straight men (or does into female bodies). I'm a gay man. I really don't care for tits of any size. So I keep blocking these communities when their posts show up. Would be much easier if I could just block/hide the whole instance from my own feed.
OK, I follow you now, sorry for misunderstanding. When you said "I wonβt be able to find one single instance the federated with just the right others for my taste so let me just filter myself," I took that to mean you wanted to start from scratch, rather than starting from a baseline moderation level you agree with plus your own filtering on top of that. That, I can certainly agree with (especially as a kbin user, where I have that capacity). I imagine it will come to Lemmy as well at some future date.
Yeah all I meant was there won't be a single instance that tailors exactly to my taste in content, which is fine.
No! The fediverse must conform to my will and my will alone!
This is virtually impossible. The amount of processing power to do that would grind any server with more than a handful of people to a halt.
Best case scenario is hoping Lemmy servers has the same capabilities as other ActivityPub servers. You can make it so Threads can see the server but the server can't see Threads. In those scenarios, even if they reply to your post, you won't see it.
In any case, if you want to choose who you federate at a user level, create your own server. You can easily federate with who you want at that point. By being on another server, you give the admins some control. That's an agreement you made when you joined a server controlled by someone else. There is very little stopping you from your own server. It can cost very little up front and after that, effectively just your own efforts to keep it running. You can be the sole user and make it fairly easily.
It's not a larger server load, because you're actually publishing less as users defederate their content. The SQL is actually pretty simple if you have a content field for blacklisting that the user selects when publishing. On the federating front end, you simply don't publish the content to the instance the user defederated from, as marked in the content field. It's basically one more line in SQL - essentially would be something like:
where content.blacklist != domainin the select statement.
This is actually already in play to some extent over here at kbin, where @Ernest has made one helluva incredible engine - we've got domain level filtering for our feeds, and the search capacity is getting pretty cool. Having that same capacity for what we publish would make for an amazing platform.
You're confusing blocking and defederation. You can already filter what you see as a user.
No, this is talking about what you publish as a user, and choosing where it appears.
That's not really how the protocol works though. You're suggesting a major change to ActivityPub itself.
Edit: and it's a change that isn't even necessary. It's the whole reason you can create your own instance.
It's not a big change - it's adding a field, a table, and a filtering line to the outgoing SQL select statement that chooses what a domain accesses when it requests the feed. Access level control has been a thing for content management systems for 20 years - this is not a big ask.
But to be honest, as you're the third person to have this misconception, I'm getting to the point where I'm almost tempted to crack open the kbin code and see if I can do it myself.
Again, you're talking about changing the ActivityPub protocol. Objects aren't published the way you think they are. It's more like batch processing. This simply can't be done at scale without massive investment.
Edit: ActivityPub is closer to an RSS Feed than it is to sending out what you publish to each server. It makes it's lsit available to others (who don't have this filter you're talking about) and they grab the whole thing. They don't scan each item and grab it as they go. And again, that scanning is done by them, not the hosting server. The feed is open by default. There is no real authentication and identity at the level you'd require to transform this into an entirely different product (a CMS).
I'm going to have to dig into it more, as filtering content from an API feed based on the referring domain's api credentials is something that's commonplace in the private sector and on other open source projects - in fact, I've recently built some reports in Quicksight that do exactly that, and output results on a secure row level basis.
I think it appears more daunting than it is (context I've been a web dev, analyst, ecom manager for 20+ years), but I haven't yet had time to dig into the code. As you're now the fourth person to make this claim, I'm now inspired to actually go and dig into this and see if I can hack it on my own. If I manage to do it (or it results in total failure), I'll update my opinions and these posts accordingly. Disclaimer - I am lazy and slow, so this may take a bit.
Yeah, you can filter your feed. No one is arguing that. But you can't filter the feed to someone else. That's not how it works. I also don't understand why you have to keep throwing around your supposed credentials when you haven't been able to understand a simple web api concept. If you want Threads not to see you, they need to defederate your server. You don't honestly think this server is posting to information to every other server individually, do you? Those servers grab information and that information is the same for every server that grabs it. It does not publish individual feeds to individual servers. That's ludicrous when you consider the minimum specs for a server.
Your credentials don't mean much when you can't provide any hint of skill to make it mean much.
FFS. Filter by domain referrer when the call is made to the API from the instance that wants to publish your work. It's not that fucking hard. How do you think IP filtering works?
Sigh. You people are fucking exhausting. #5 of saying "you can't do that" and giving nothing more than "server can't handle it" as a reason, which is why I stated my credentials, because I'm sick of people talking out of their asses.
When the instance that wants to publish your work makes a call to the api, they have a domain referrer value. Being able to filter on that value is already in place through the process of defederation.
Filtering the output on that domain referrer value is neither some complex process, nor will it increase server load as you're reducing the amount of content the API is producing.
How do you think IP filtering works? Every public facing web service does it. This is the exactly the same thing, except that rather than blocking the entire site, you're blocking a small part of it. It's even easier than blocking a specific page to an IP, because you only have to block a subset of data coming out of the feed on the api.
Your choice is in which instance you sign up to, meaning you find somewhere you agree with the admins' choices. If your views are so unique that no such place exists, you start your own instance.
Well, yeah, that's how it works now.
I'm looking at an improvement to the current system. Admin views can change, and in this scenario they're a form of centralized power and responsibility. Delegating this particular power and responsibility to the user would remove the additional burden of moderation and allow the admins to focus on running the instance rather than policing the Fediverse.
Giving users the choice of where their content is federated seems like a happy medium for all parties concerned. The admins don't have to get political and the users can stay away from the Zuckening if they want to.
This would be a mess to support on a server and I don't blame anyone not wanting to pay to host that much wasted processing power. You can start a server for under $50. Admins have the power to do what they want on the servers they own. Federation works on a per-server basis. You can block who you don't want to see. Some even allow you to block entire instances. But federation at the user level is ridiculous on its face and would require ridiculous server power.
As someone who works with large data on a daily basis, no, it's not.
Gonna point you to my post here.