Piefed.social Staff

Community owner of !television@piefed.social and !obscuremusic@piefed.social

  • 5 Posts
  • 166 Comments
Joined 10 months ago
cake
Cake day: March 18th, 2025

help-circle


  • This is tyranny of the majority. If one person is out there saying “I don’t want to have the data I’ve posted on server A to be presented as if I posted on server B”, then this person will be right to complain if they see their requests being respected.

    Well we already have ‘tyranny of the majority’ here regarding a whole host of functions on the fediverse. On reddit voting is entirely private, mod-logs hidden and people now can even hide their posting history. I am sure a non-zero amount of people here object to that (I know some do). But there’s no support for changing that due to the belief prevalent across the fediverse that these being publicly accessible keep the fediverse honest.

    This is tyranny of the majority. If one person is out there saying “I don’t want to have the data I’ve posted on server A to be presented as if I posted on server B”, then this person will be right to complain if they see their requests being respected.

    Maybe one could have an opt-out toggle in users profiles for potential community migration. Ultimately, I’m in favour of (if this functionality ever actually exists to completely move a community) being widely known. People would join the fediverse knowing that there’s a possibility that the community they’re posting on could, down-the-line, move to another instance and thus ‘move’ their posts and comments within that community.

    And I’m just replying to your points from a community perspective. You’re welcome to reply or not.


  • Then why restrict this logic to “like/dislike” activities, and not extend to any type of activity?

    Some communities are also, or can be set to local only. What other activities do you have in mind?

    A mitigation is not a proper solution, even less so when it violates other principles in distributed systems.

    So far as I can see, that’s up to the collective fediverse population. You done a poll on this?

    The harm itself will be for the instance admin later on. Still, the larger point is this solution is a workaround that does not bring any meaningful benefit for others in the Fediverse.

    It’s not supposed to in this context. It’s for an instance admin who wants to populate the content of their own instance. Although it could be beneficial if it’s an instance for others that is not personal in scope and is supposed to be a wide-use instance.


  • My point, in one sentence: it’s not up to the developers of a project building on ActivityPub to define policy regarding “exposure”.

    As someone who actually opposed the initial implemention of Piefed’s voting being made non-public to non-instance admins (as much as possible) to other users, I completely disagree. Some people don’t like it and don’t want their votes to be easily accessible to the wider fediverse. The only way that can be implemented currently is by removing federation. Rimu serves that.

    This is a good example of selection bias. You are getting most of your feedback from other PieFed users, who clearly are not aware of the implications of such implementation.

    No, I’ve seen this opinion from others. It’s also a wider criticism of the viability of the fediverse long-term in that communities are only as long as their hosted instance. This does a lot to mitigate that.

    Yes, I am opposed to any functionality being added to the server when it can be solved at the client. Content discovered can be done by the client and using a separate service like Fediverser, fedidb, or anything else. It makes no sense to have this built-in into the ActivityPub server. It is one of the many examples where the piefed devs are adding a feature because they can without thinking whether they should.

    Can you tell me exactly what harm this does to the mythical ActivityPub, beyond an instance owner toggling it on in ignorance to their own detriment.


  • No, it was not dropped. “do not federate votes” is not a privacy guarantee. It just reduces the exposure of the information from the whole Internet to the server admin. People still need to trust the admin.

    Well, sure. But it’s still less of an ‘exposure’ so to speak, than a vote federating out.

    If you are one of the developers of the project, you should be quibbling about the implementation. “It is popular” is not a good enough reason to effectively fabricate information.

    People don’t see it as fabrication if the community movement is reflected in the public logs - which it would be. I think I’ve only seen one other person object to the mechanic of community migration on the basis of “fabricating” information, other than you. You are in a vast minority. Most people are keen to see it go further and move subscribers too, from what I can tell. The end-game is a situation where most people recognise that communities on the fediverse are functionally modular and can be moved if necessary. Most people would understand, if this was the norm, that communities are modular and can be movied in certain circumstances.

    What I am against is this constant release of poorly thought out features and the prioritization of “easy” vs “correct”.

    That’s not what I asked you. I said the lemmy-federate functions should instead be opt-in, and you still seemed to oppose it.


  • Maximum anonymity is a lie. Users still need to trust the server
    admin. The truth is that the Fediverse is not a secure/private
    messaging platform, and attempts to hide this from the users might be well-intentioned but will bite the devs in the ass, sooner or later.

    Sure. Pseudonymity. Again, it was dropped.

    To solve this it would be better to have the PieFed team pushing/implementing the appropriate FEPs (FEP-7952 and FEP-EF61) instead of an-hoc hack.

    I’m not here to quibble about the mechanics of the implementation, but purely noting that it is popular. You seem to be opposed to it on principle.

    Doesn’t matter. Admins will see it, think “that is nice!”, turn it on and only realize later that their database is completely bloated with data that is not really needed. Meanwhile, the real problem of content discovery could be solved by implementing pull-based federation and client-side caching, but again this type of work is not being done because it’s not something that the users see directly.

    Then attach with it an explanation that it could cause data bloat and increase costs for them which might be unwelcome if they’re designed as a personal instance. You’re against admins having the ability to turn this on if they want?


  • Sending pseudonymous actor ids to hide votes

    This has long been scrapped. You can choose to not federate out your own downvotes now for maximum anonymity, but this was widely disliked so it was dropped.

    “Migrating” communities by re-creating activities and objects on their own server, just rewriting the URLs and pretending the piefed server actually was the original source.

    Yup. Although this isn’t complete in many cases, but is an entirely transparent process. I’ve told you this has vast fediverse support because it enables community modularity, which is needed in a world where instances will go offline, causing communities to be orphaned.

    Integrating functionality that is hardcoded to specific instances/groups (auto-posting new communities on !newcommunities@lemmy.world)

    This was agreed with the moderators of said community.

    Integrating lemmy-federate directly into the instance - which is a horrendous idea if you consider that will lead to every piefed instance holding every copy of the messages, even if no one in the instance actually follows or interacts with it.

    I’m not quite sure how this specifically functions for new instances, but I have suggested this be opt-in rather than opt-out.










  • I think you will find that most forums before Digg and Reddit did have rules. There is some revisionism from muh free speech types that seek to redefine them as free speech zones, when many were not.

    Moreover, many clients and apps that were had much smaller userbases.


    The point about the CP here is that you are saying that it would remain technically on the systems you are referring to.


  • So the child porn still remains present, effectively.

    So Ada described Nostr like this:

    "Nostr uses relays. In some ways, a relay is like an instance on the fediverse. Where they differ though, is that a) relays don’t talk to each other and b) users can sign up to many different relays and pull/push content to all of them.

    So in practice, in order to see a wide amount of content, you need to end up connecting to multiple relays. And even though a relay does have some moderation capabilities to block content, unless every relay you use blocks the content from the bigoted account, you’ll see it.

    If you signed up only to a single relay, and that relay had good moderation, then in theory, your Nostr experience wouldn’t be terrible, but a single niche relay like that will mean you see basically no content. And as soon as you connect to a larger public relay to get more content, you lose all of the moderation advantages offered by your first instance. Which means in practice, there is no incentive to run a well moderated instance.

    And so all of the moderation ends up on the end user, who has to manually block accounts only after they appear and dump their load of hate (at which point, the bigot will just spin up another account). Some people prefer that experience, but when you’re the regular target of hate, that approach just doesn’t work for many folk."

    This is accurate?