• 1 Post
  • 12 Comments
Joined 1 year ago
cake
Cake day: June 20th, 2023

help-circle

  • Yeah for sure, it’s pretty fucked. Hopefully I can do my banking through a web browser if my bank ever decides to pull some dumb shit like that.

    One thing that really fucks me off, are schools requiring students to use proprietary nonfree software. Windows, adobe, MS office, etc

    IMO all schools should be using desktop Linux, and teaching students on free and open source software.

    It respects student freedom and privacy, and doesn’t unfairly punish the less financially fortunate. On top of that, it teaches students important lessons about sharing and collaboration. Imagine what the FOSS movement might look like if free and open source became the standard in education.






  • I highly recommend lineageOS, or better yet lineageOS with microg.

    Running a completely degoogled android phone right now, and it feels smooth as butter. Microg has gotten so good, the vast majority of playstore apps work completely fine even without Google services, including things like my banking apps.

    Feels liberating as fuck, not gonna lie.

    Only apps that don’t work for me are ones that require IaP’s. About 30% of those I can crack with LuckyPatcher. I can also crack other paid apps with license protection.

    Mostly I havent needed to do any of that though, because I’ve found that there are so many great open source apps that do the things I need.


  • I’ve said it before and I’ll say it again, defederation should be removed from the protocol. (And replaced with a default ban list that can be overriden by the user).

    Each instance should basically just be a set of default settings that are used to access the same shared pool of content.

    This removes the new user hurdle, because they can now join any instance and not be worried that they are making some important, permanent decision. If they find that they don’t like something about the instance, they can tweak their settings later.

    Also, some of the other solutions to this issue carry significant risks. Pushing users towards a ‘default’ instance increases centralization. Apps that are preconfigured to use a specific instance are even worse (since people wont want to change instance if it means giving up a familiar app). Without some degree of vigilance decentralized services tend to centralize over time. This gives too much power over the entire fediverse to a handful of instance admins. If an instance with 60% of all users starts defederating all smaller instances, most users will just migrate to the larger instance.

    This isn’t just some theoretical that I pulled out of my ass, its an easily abusable weakness of federated services. It has been abused in the past, and there is no reason to believe it wont be abused again.

    Google used it to kill XMPP. Facebook will almost certainly use it to kill mastodon, once they siphon enough users and content to build a critical mass. Microsoft is so notorious for using this strategy that they has their own internal phrase for it: Embrace, Extend, Extinguish.

    https://en.m.wikipedia.org/wiki/Embrace,_extend,_and_extinguish



  • The problem is that defederation is that it causes damage to the wider network, and can be far too easily abused.

    It makes instance selection very important to the user (which is already a major friction point). And causes terrible UX when users can’t figure out why content is unavailable to them.

    It can also be used as a weapon by powerhungry admins to force centralization around their instance.

    I know there aren’t really great alternatives to defederation for content moderation right now. But I think that these could easily be implemented. For example, instances could maintain a ‘blocklist’ which users could automatically be subscribed to upon joining, but they would be able to inspect and ‘opt-out’ from blocking certain instances or categories if they desired.

    I think this is a good balance of protecting users, and also respecting their freedom.

    Keep in mind that this doesn’t mean they could POST rule breaking content. (They are still users of your instance after all). Just that they would have the choice of which content they feel comfortable with VIEWING.

    When all you have is a hammer, every problem looks like a nail. And defederation is a nuclear powered sledgehammer lol.


  • Your points are valid, but that doesn’t mean we should do nothing. Enforcing federation and using copyleft licensing are both strong defenses against centralization and network dominance by a well funded third party.

    As far as GPL goes, from what I’ve seen, big tech companies tend to take it pretty seriously. There is no reason we shouldn’t be using that, and other license protections if we have the option.

    As for natural centralization over time, I think that is a far less urgent problem than the current risks we are facing, those being major network fragmentation due to the use of defederation, and the risk of centralization around a proprietary platform and/or instance.

    Removal of defederation and strong copyleft licensing seem to be natural first steps in combatting that risk.


  • Seems like just another reason why defederation should be completely removed from the protocol. It’s way too easy to abuse and force centralisation.

    There are other far less destructive and abusable ways of dealing with spam and content moderation.

    I maintain that it’s better to give the users the control, and allow them to decide which instances, communities, and users they want to be exposed to. Bottom up moderation, instead of top down.

    For example, instances can provide suggested ‘block’ lists (much like how an ad blocker works) and users can decide whether or not to apply those lists at their own discretion.

    By forcing federation, the network stays decentralized. Maintaining community blacklists that can be turned on or off by the individual user protects against heavy handed moderation and censorship, whilst also protecting users from being exposed to undesirable content.