Tom Casavant

Software Developer from Ohio

Interests:
#OpenSource #SteamDeck #Running #Sports #CFB #MLB #NFL

Teams:
#Bengals & #Reds & #OhioState

Creator of @pokemon

  • 1 Post
  • 17 Comments
Joined 1 year ago
cake
Cake day: December 15th, 2023

help-circle


  • @BeAware@social.beaware.live @ThaMunsta@nervesocket.com From glancing through the github issues it looks like it only does that for account deletions. Though I have no idea how many of these are resolved or no longer function as described in the issues

    https://github.com/mastodon/mastodon/pull/22273:

    One outstanding issue with Mastodon is that deleting a local account sends a Delete activity to the whole known fediverse to ensure everyone is aware that the account does not exist anymore. This is wasteful, and increasingly so with the growth of the fediverse. It is also a minor privacy concern, as servers who would otherwise not know about an account would learn about its (previous) existence without a good reason.

    https://github.com/mastodon/mastodon/issues/22154

    Currently, posts deleted over a week earlier on one server are still visible on others. For example, I can see (on both mastodon.social and mstdn.social) a post I deleted at the start of December on mstdn.jp. On both of those other servers, it looks like the post is still live and available on mstdn.jp.

    https://github.com/mastodon/mastodon/issues/22070#issuecomment-1340711206:

    To clear up some misunderstanding, Mastodon does not send a Delete to every known server for every deleted post, that would be too expensive. It does send a Delete to every known server for every deleted account though.
    I do have some idea on how to improve that (keep track of which servers ever requested an account, using a bloom filter so it remains manageable storage-wise), but it will require some work and will only work for newly-created accounts, not ones that existed before the change was implemented.

    https://github.com/mastodon/mastodon/issues/6849#issuecomment-1418688876

    It’s retried a bunch of times, but once every retry is elapsed and the post is deleted, Mastodon stores neither the post’s previous existence nor who was supposed to see it, so such a feature would require the admin to provide:
    the post’s author
    the post’s exact ID
    who to send the deletion notice to











  • @stefan@stefanbohacek.online Oh cool! that’s awesome

    I haven’t seen any impact whatsoever, but I imagine if it was a more high profile article it might generate more traffic if I understand how embeds work? My server already has to handle traffic to a number of servers anyway whenever a post is published in probably faster succession than people opening up that article.

    Tangentially related, I think the verge has been planning to integrate more deeply with the fediverse based on posts I’ve seen from them- and I think long term it’d be better if they just had their own AP server that they grabbed embeds from rather than individual servers? For traffic reasons, and for the fact that I think I have a lot of control over what those embeds look like. Also, my server’s probably a lot less reliable than any larger platform so theoretically that embed could just stop working


  • @FandaSin@social.linux.pizza @BeAware@social.beaware.live Yes this is possible and I think it’s been discussed as a solution. The concern, last time I was reading about it, is that malevolent servers could poison a link preview and send fake images along with the url (the argument against this is you’re already ‘trusting’ the server if you’re federating with them, so that trust should extend to link previews)

    Another proposed solution was just having servers wait a random amount of time before fetching the link preview so not every server is requesting the preview at the same time