65
What principles you wish to see social networks (or the fediverse) adopt in their design? (lemy.lol)
submitted 10 months ago by to c/fediverse@lemmy.world
53 comments fedilink hide all child comments
 

For example, for me, here are some things I wish to see (or would implement in my design) :

  • design around ease of self-hosting. A non technical user must be able to self host easily and at a very low cost.
  • Embrace content sorting and filtering algorithms, but on the client side, with optional control by the user.
  • Standardize tags on all content. So many of the different ways different platforms classify or organize content can be implemented as tags, which increases interoperability between them.
  • Abandon obsession with real-time-first implementations for use cases that don't explicitly need it.
  • Transferable user identity (between instances)
  • User identity and authentication as separate service from social network instance

Would love to hear yours!

you are viewing a single comment's thread
view the rest of the comments
[–] [S] 7 points 10 months ago (11 children)

I agree with this. I think instance owners retaining ability to block other instances is still unfortunately necessary, if at least for administrative and legal reasons. But putting the onus on granular blocking controls on the user is a big achievement, as I prefer the user to retain that control.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 11 child comments
    •
  • [–] 3 points 10 months ago (8 children)

    That's not a universal want. Trans people and other vulnerable, targeted minorities face a real cost in having to play whack a mole with bigots. Sure, you can block them as they appear, but by that point, you've already seen their hate. And it means every trans person has to see and block that content. After which, the bigot just comes back with a new account, and does another round.

    The blahaj instances offer aggressive, pre-emptive blocking of bigots and transphobes, at the instance level, with the goal of giving our users an experience of social media that isn't shaped by hate.

    Of course, not all trans folk want that, and some absolutely do want the power to choose for themselves who gets blocked and are willing to face the hate in order to retain that ability. But that's the other power of the fediverse, because there are instances that cater to that approach as well.

    tl;dr - Granular user control of blocking/federation is good, but it's not "better" than instance level blocking and defederation.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 8 child comments
    •
  • [–] [S] 4 points 10 months ago (4 children)

    An easy middle ground is the ability to sync your block list with someone else. This gives the same capability you desire, but allows users freedom to do it on their own. Everyone's happy! What do you think?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 1 point 10 months ago (3 children)

    It's a good idea, but still not an alternative to instance level blocking.

    The downside is that if you're new to the fediverse, you have no way of knowing whose lists you should follow. So there needs to be some sort of instance/client level opt in recommendation to make it visible/useful to new users.

    Beyond that though, on an instance like blahaj, it would be largely irrelevant, because there is no scenario where I let transphobes federate to the instance, whether or not individuals have the ability to block them from a subscription list.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] [S] 2 points 10 months ago (2 children)

    The downside is that if you're new to the fediverse, you have no way of knowing whose lists you should follow.

    Isn't the whole idea that you choose a trans-friendly instance and you naturally adopt the instance wide blocklist? Same thing here, except you choose the block list similar to choosing an instance in the old flow.

    And if you disagree, this could still easily be mediated. For example, the instance could have a default block list. As long as one can opt out, that would respect user choice.

    Or choosing the blocklists can be part of the account creation flow.

    There's others ways to go about it.

    Beyond that though, on an instance like blahaj, it would be largely irrelevant, because there is no scenario where I let transphobes federate to the instance

    What I suggest isn't meant to take away the instance owner ability to defederate or moderate. But this makes it such that you don't have to modify your moderation strategy when your users can adopt different moderation in addition to what you have. (example: maybe a large group of your users want to block US-centric content, or political content, etc.) and people not on your instance could possibly adopt your moderation as well!

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 10 months ago (2 children)

    I'm not saying that instances shouldn't have default blocklists, but that users should have the right to disable them granularly.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 3 points 10 months ago

    No way. Transphobia is not welcome on any instance I run for example. And that isn't something that a user should be able to change for themselves. That's a scenario where you would pick a difference instance

  • permalink
  • fedilink
  • source
  • parent
  • [–] 1 point 10 months ago (1 child)

    you should look at the domain names of some of these blocked instances.

    going live without a block list implemented upon start up is going to put you in a very serious legal quagmire where you are now responsible for your ISP having transmitted CASM.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •