this post was submitted on 22 Jan 2026
50 points (98.1% liked)

Slop.

771 readers
679 users here now

For posting all the anonymous reactionary bullshit that you can't post anywhere else.

Rule 1: All posts must include links to the subject matter, and no identifying information should be redacted.

Rule 2: If your source is a reactionary website, please use archive.is instead of linking directly.

Rule 3: No sectarianism.

Rule 4: TERF/SWERFs Not Welcome

Rule 5: No bigotry of any kind, including ironic bigotry.

Rule 6: Do not post fellow hexbears.

Rule 7: Do not individually target federated instances' admins or moderators.

founded 1 year ago
MODERATORS
VILenin@hexbear.net
MiraculousMM@hexbear.net
Hestia@hexbear.net
oscardejarjayes@hexbear.net
Diva@lemmy.ml
Diva@hexbear.net
mathemachristian@hexbear.net
50
PieFed vs Lemmy. What say you? (lemmy.world)
submitted 5 days ago* (last edited 5 days ago) by LemmySlopSkimmer@hexbear.net to c/slop@hexbear.net
188 comments fedilink hide all child comments
 

So, it seems like PieFed is becoming a real alternative to lemmy.

What are the differences between these two? From a tech perspective, and also morality/ethics, if you want. Any differences in vision for these services?

Say whatever is on your mind. I want to know.

On which one should we put our weight?

PieFed all the way. It’s developing at lightning speed, while Lemmy lags behind as the transphobic genocide denying devs beg for donations with in built donation begging banners on all Lemmy instances front pages. Instances are apparently scared to defed from .ml for fear the devs wont support them with help.

Rimu has made some interesting choices, such as blocking 196 from default federating posts until a user subs first or a dislike for meme subs. But when spoken to has been receptive and removed such things or made them optional for admins.

Ethically and feature wise PieFed is in the lead, its not perfect but its open to change and receptive to ideas

you are viewing a single comment's thread
view the rest of the comments
[–] RedWizard@hexbear.net 7 points 5 days ago (1 children)

I feel like this has been a thing for a while though. But this function

proactively_delete_reply

def proactively_delete_reply(community: Community, ap_id: str):
	    deletor = None
	    # Try to find a local moderator to send the Delete
	    for moderator in community.moderators():
	        moderator_account = db.session.query(User).get(moderator.user_id)
	        if moderator_account.is_local():
	            deletor = moderator_account
	            break
	    # Use admin account if there is not one.
	    if deletor is None:
	        deletor = db.session.query(User).get(1)
	    if deletor:
	
	        delete_id = f"https://{current_app.config['SERVER_NAME']}/activities/delete/{gibberish(15)}"
	        to = ["https://www.w3.org/ns/activitystreams#Public"]
	        cc = [community.public_url()]
	        delete = {
	          'id': delete_id,
	          'type': 'Delete',
	          'actor': deletor.public_url(),
	          'object': ap_id,
	          'audience': community.public_url(),
	          'to': to,
	          'cc': cc,
	          'summary': 'Automatic deletion due to block'
	        }
	
	        announce_id = f"https://{current_app.config['SERVER_NAME']}/activities/announce/{gibberish(15)}"
	        actor = community.public_url()
	        cc = [community.ap_followers_url]
	        to = ["https://www.w3.org/ns/activitystreams#Public"]
	        announce = {
	            'id': announce_id,
	            'type': 'Announce',
	            'actor': actor,
	            'object': delete,
	            '@context': default_context(),
	            'to': to,
	            'cc': cc
	        }
	        domain = furl(ap_id).host
	        instance = find_instance_by_domain(domain)
	        if instance and instance.inbox:
	            send_post_request(instance.inbox, announce, community.private_key, community.public_url() + '#main-key')

Is a strange way to handle blocks, right? It's fetching either a local moderator account, or a local admin account, and then using that account to send a block command on behalf of that user account? I still don't really know why the system doesn't simply store the blocks locally and then check at page render if the content is blocked, and then not render it for the user who created the block. Am I understanding this correctly, that this system enforces individual user blocks on the entire community? Even remote communities?

[–] edie@lemmy.encryptionin.space 7 points 5 days ago* (last edited 5 days ago) (2 children)

You seem to be confused. Let's start with this "delete replies on remote instances when author has been blocked by parent content author", it was added a week ago, on the 13th of january, proactively_delete_reply was added then with it. What it does is not block, but delete, you may be familiar with a different name for it: remove.

Dealing with a new comment happens here, it starts with create_post_reply, it will for example return None if the parent comment author has blocked the replier, so the code never reaches PostReply.new(), it is inside this PostReply.new that the comment is added to the database, so the reply is never added to the database. Furthermore, since create_post_reply returns None, reply is None, and so if reply: is false, this means announce_activity_to_followers is never called, and as such other instances are never informed of the new comment (AFAIK it is the duty of the instance on which the community is on to announce to instances with subscribers to that community of new content)

ⓘ This user is suspected of being a cat. Please report any suspicious behavior.

[–] RedWizard@hexbear.net 6 points 5 days ago (1 children)

Ah yeah I see where I got mixed up. Sorry! Was the end of my day and doing to many things at once.

But do I have it correct that it seems as though individual users have some amount of control over how content federates on their instance through the blocking mechanism?

It's clamped to just the user's content, their comments and posts, but it still prevents federated content from being stored on the server or content being federated to other servers.

It's not a purely cosmetic block right? Because it changes what other users see relative to my own content. Unless I'm still confused about how this works.

If I make a post and I have a large block list of users from other instances, those users could be replying to my posts on their instance. But on my home instance, it wouldn't store those in the database because I've blocked them, which would result in users from my home instance never seeing them either, right?

[–] edie@lemmy.encryptionin.space 6 points 5 days ago* (last edited 5 days ago)

But do I have it correct that it seems as though individual users have some amount of control over how content federates on their instance through the blocking mechanism?

It’s clamped to just the user’s content, their comments and posts, but it still prevents federated content from being stored on the server or content being federated to other servers.

AFAIK, Correct.

It’s not a purely cosmetic block right?

It's not. See the two examples in your original comment (Cowbee, and me replying to my test accounts)

Because it changes what other users see relative to my own content.

Yes.

If I make a post and I have a large block list of users from other instances, those users could be replying to my posts on their instance. But on my home instance, it wouldn’t store those in the database because I’ve blocked them, which would result in users from my home instance never seeing them either, right?

Exactly.

ⓘ This user is suspected of being a cat. Please report any suspicious behavior.

[–] RedWizard@hexbear.net 5 points 4 days ago* (last edited 4 days ago) (1 children)

Wait. The logic flow makes sense though. I've been double checking this. The proactively_delete_reply only proactively deleted if the parent user has the replying user blocked.

What this means, is that this function is attempting to mirror the host instance even closer. LocalUser (LU) blocks RemoteUser(RU). LU makes a comment that federates to RU's instance. RU replies and their comment is sent back to LU instance.

LUs community where the comment is received checks its inbox. It then validates the comment. It then checks to see if the comment is from a site banned user, it passes. It then checks if the RU is blocked by the parent comment user (LU), it fails.

In 1.5.X currently this returns None thus never storing the comment.

In the main branch however, a secondary task is fired off, calling proactively_delete_reply only if the community is local. proactively_delete_reply searches for a mod or admin account and sends a moderator action back to the remote server with the note "Automatic delete do to block".

This is because of a few reasons:

  1. They prevent local users from leaving comments on posts and comments from users who block them using the UI.
  2. They CANNOT do this for remote piefed instances (I think). They obviously can't do it for Lemmy instance. Thus the Return None.
  3. Now this new code enforces the removal of the comment on the remote server because it is already stored in the DB.

They are effectively enforcing blocks at the DB level instead of the API level. Lemmy to my understanding will simply flag the user as blocked and it is on developers to prevent the content from being displayed to the user.

The implications seem to be that in the future if a Lemmy user replies to a post or comment from a piefed local community, and the author blocks them, a federated mod action will be sent to the Lemmy server to remove the comment.

[–] I_Hate_AmeriKKKa@hexbear.net 2 points 4 days ago (1 children)

The implications seem to be that in the future if a Lemmy user replies to a post or comment from a piefed local community, and the author blocks them, a federated mod action will be sent to the Lemmy server to remove the comment.

i must be reading this wrong, but are you saying that it will do this retroactively if you block someone???

[–] edie@lemmy.encryptionin.space 1 points 4 days ago

I think its meant as passive, I.e. already blocks them. So not retroactively.

ⓘ This user is suspected of being a cat. Please report any suspicious behavior.