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
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?
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.
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?
AFAIK, Correct.
It’s not. See the two examples in your original comment (Cowbee, and me replying to my test accounts)
Yes.
Exactly.
Then further, on the posts made on communities on your instance, those comments won’t federate out further. So say, a lemmy.ml user is replying to you on a post in the movies@piefed.instance community, which is your home instance, lemmy.world won’t be able to see that lemmy.ml comment either. (unless the lemmy.ml comment is in direct reply to a lemmy.world user, maybe I’m not sure. But that’s what happened with my piefed.zip reply)
ⓘ This user is suspected of being a cat. Please report any suspicious behavior.
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:
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 must be reading this wrong, but are you saying that it will do this retroactively if you block someone???
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.