• 1 Post
  • 93 Comments
Joined 1 year ago
cake
Cake day: June 6th, 2025

help-circle








  • That won’t be terribly meaningful. lbz has a huge defederation list, because we seeded our defederation list with defeds from our sharkey instance. So as a result, lbz has hundreds of defeds of dead instances from 3 years ago and defeds of mastodon, pleroma and other instances that have never interacted with the threadiverse in any meaningful way.

    If you’re just trying to work out how much of the threadiverse each threadiverse instances has defederated, you’d need to do a bit of filtering on the results.


  • The tl;dr answer is that it’s axiomatic. It’s built in to the model, and if it weren’t true, the model wouldn’t work.

    More broadly though, symmetry in relativity exists because there is no way of distinguishing the “truth”. No one point of reference is more correct. You can’t tell who is truly moving, because as you highlight, A is moving away from B is just as valid as B is moving away from A.

    Acceleration breaks symmetry though, because you can measure it. You can tell whether it’s A or B that’s accelerating, and there is a “right” answer.







  • Ada@piefed.blahaj.zonetoLinux@lemmy.mlWhat have I done?
    link
    fedilink
    English
    arrow-up
    7
    arrow-down
    1
    ·
    3 months ago

    I could care less about apps, because I can just avoid them. My concern is the OS level stuff, and currently, all of the legislation is around requirements that the OS itself capture birthdate data.

    The moment that becomes mandatory at the OS level, is the moment I drop whatever it is that is forcing that issue. Systemd was the first to pre-emptively comply with facilitating the change at scale, so chances are, they will keep doing the same going forward.





  • It’s not more useful than hashtags.

    It’s a hashtag relay.

    On the fediverse, there is no central “fire hose”, no central source of “every post from everyone”. Rather, when someone makes a post, the instance the post was created on looks at the list of people following the person making the post, and sends a copy of the content to all of those instances.

    When someone boosts a post, the original post is sent to all instances that have people following the person doing the boosting.

    And that’s basically it.

    So if you’re on a single person instance, the only content you will see is the content created by or boosted by people you follow. No other content makes it to your instance, so your “global feed” and your “home feed” look the same.

    On a big instance with lots of users, the global feed is just a master list of all of the public content that makes up all of the home feeds of the users on the instance. So the more users, the more content in the global feed.

    And when you follow a hashtag, the only content you see is hashtag content that made it to the global feed. So if no one on your server follows a particular person, none of their hashtag content will make it to your instance.

    Relays are a fire hose. Every instance that adds a relay sends all of its public content to the relay. And in turn, the relay sends back all public content it receives from every instance subscribed to the relay. So if you’re a single user instance, and you subscribe to a relay, your global feed will look very different to your home feed, because the relay will be sending you content from all of the instances subscribed to that relay!

    tags.pub is a garden hose instead of a fire hose. It’s a way of getting filtered content from a relay, so that only content that matches the hashtags you or your admin have subscribed to make it to your instance. The other main difference between tags.pub and a typical relay is that individual users can subscribe to a tag on the tags.pub relay, and get content from it even if their instance admin hasn’t added it as a relay.