Comment

Comment on PieFed 1.4 is released - emoji, federated stackoverflow and AI content filters

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. You’re against admins having the ability to turn this on if they want?

source

Sort:hotnew top

rglullis@communick.news ⁨3⁩ ⁨days⁩ ago
Sure. Pseudonymity. Again, it was dropped.

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.

I’m not here to quibble about the mechanics of the implementation, but purely noting that it is popular.

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.

You’re against admins having the ability to turn this on if they want?

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

The more you try to justify what PieFed is doing, the more you are cementing my original opinion:

it looks and feels amateurish.

Its idea of “design” is “add any tool/functionality/feature that the developers think might be useful to them/their users”.

it is not contributing in any meaningful way to development and improvement of the standards of the Social Web.

You might feel offended by me calling it “a pile of hacks”, but I can not think of any other term to describe this.
source
- Skavau@piefed.social ⁨3⁩ ⁨days⁩ ago
  
  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.
  
  source
  - rglullis@communick.news ⁨3⁩ ⁨days⁩ ago
    We are talking past each other by now…
    
    Well, sure. But it’s still less of an ‘exposure’ so to speak, than a vote federating out.
    
    My point, in one sentence: it’s not up to the developers of a project building on ActivityPub to define policy regarding “exposure”.
    
    ActivityPub is a protocol for public social networks. It’s not about private communications. Anyone looking for privacy should be told that and instructed to not post publicly.
    
    It’s as simple as that. If the developers of PieFed do not understand the basic principle of “use the right tool for the job” and keep trying replicate anti-features from centralized websites (such as the fake-privacy that is provided by closed networks), then I will have no trust on their ability to design a good ActivityPub system.
    
    You are in a vast minority. Most people are keen to see it go further and move subscribers too.
    
    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.
    
    I said the lemmy-federate functions should instead be opt-in, and you still seemed to oppose it.
    
    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.
    
    source
    Skavau@piefed.social ⁨3⁩ ⁨days⁩ ago
    
    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.
    
    source
    -> View More Comments