So on my ONI instance that I've been use as an alternative fediverse profile for myself for about two years, the full storage used is about 3.4G, but out of that there's 2.5G containing mostly the Delete activities of mastodon.social.
-
So on my ONI instance that I've been use as an alternative fediverse profile for myself for about two years, the full storage used is about 3.4G, but out of that there's 2.5G containing mostly the Delete activities of mastodon.social. Crazy.
-
? Guest crossposted this topic to General Discussion
-
So on my ONI instance that I've been use as an alternative fediverse profile for myself for about two years, the full storage used is about 3.4G, but out of that there's 2.5G containing mostly the Delete activities of mastodon.social. Crazy.
@mariusor after reading this, i had to run the same test on my epiktistes/ktistec database. Delete activities are the most numerous activity type, exceeding even Create. 39% of activities are Delete. of those, 45% are from mastodon.social. storage usage is less—those Delete activities are only about 8% of the database size, including indexes.
-
@mariusor after reading this, i had to run the same test on my epiktistes/ktistec database. Delete activities are the most numerous activity type, exceeding even Create. 39% of activities are Delete. of those, 45% are from mastodon.social. storage usage is less—those Delete activities are only about 8% of the database size, including indexes.
@toddsundsted this scattershot approach to sending Deletes is such a waste of requests and bandwidh on the part of Mastodon.
There's been so much faff about how verbose ActivityPub is and here we have a trivial optimization to make: just don't send Deletes to the whole network that you have access to. The only interested parties are followers and following collections. Simple!
-
@toddsundsted this scattershot approach to sending Deletes is such a waste of requests and bandwidh on the part of Mastodon.
There's been so much faff about how verbose ActivityPub is and here we have a trivial optimization to make: just don't send Deletes to the whole network that you have access to. The only interested parties are followers and following collections. Simple!
Unfortunately not so simple.
Followship may vary over time.
Accounts could be remotely resolved by fetching conversations.
Accounts could be remotely resolved manually.
Accounts could have sent an answer to someone with no relationship.
And so on. -
Unfortunately not so simple.
Followship may vary over time.
Accounts could be remotely resolved by fetching conversations.
Accounts could be remotely resolved manually.
Accounts could have sent an answer to someone with no relationship.
And so on. -
Unfortunately not so simple.
Followship may vary over time.
Accounts could be remotely resolved by fetching conversations.
Accounts could be remotely resolved manually.
Accounts could have sent an answer to someone with no relationship.
And so on.@nick none of those actions can't be solved by trying to fetch the actor before operating them.
Also having requests fail should not be an issue for any clients. Receiving 404 and 403 responses is just a normal day on the internet.
-
@toddsundsted I'm considering adding extra logic to the Delete workflow so if the Deleted object does not exist locally (previously fetched or created) the Delete doesn't get processed or persisted...
-
@toddsundsted this scattershot approach to sending Deletes is such a waste of requests and bandwidh on the part of Mastodon.
There's been so much faff about how verbose ActivityPub is and here we have a trivial optimization to make: just don't send Deletes to the whole network that you have access to. The only interested parties are followers and following collections. Simple!
@mariusor @toddsundsted Mastodon hasn't ever been known for being efficient or elegant, and after being here for a decade I don't see that ever changing
-
@mariusor @toddsundsted Mastodon hasn't ever been known for being efficient or elegant, and after being here for a decade I don't see that ever changing
@deutrino I know, I know, I'm the biggest complainer about Mastodon's lack of effort when it comes to better support the specification. I suspect everyone in their team has me on mute already.
-
@nick none of those actions can't be solved by trying to fetch the actor before operating them.
Also having requests fail should not be an issue for any clients. Receiving 404 and 403 responses is just a normal day on the internet.
@mariusor @nick How does fetching the actor's current state help with knowing the original distribution of an activity? What happens when a popular follower boosts a post to thousands of their followers and to many servers (and their followers re-boost to yet more servers, etc.). There are also relays that may have forwarded an activity to many servers and is now no longer active to forward Deletes. If your trivial solution is effective, I'd like to see a full description/analysis in an FEP.
-
@mariusor @nick How does fetching the actor's current state help with knowing the original distribution of an activity? What happens when a popular follower boosts a post to thousands of their followers and to many servers (and their followers re-boost to yet more servers, etc.). There are also relays that may have forwarded an activity to many servers and is now no longer active to forward Deletes. If your trivial solution is effective, I'd like to see a full description/analysis in an FEP.
@steve I'm not sure I understand your question. What does a popular account posting have to do with the dissemination list of Delete activities? Are you suggesting that the problem is that they're sending to deleted actors? Perfect, now the server knows to stop sending there.
-
-
@mariusor @nick AFAICT, Fediverse Delete is practically going to be "best effort" and not complete. The question is how much effort is an implementation willing to make. Only sending a Delete to followers and following collections seems to me to be minimal effort with minimal effectiveness. On the high effort side, an implementation could track every domain that's ever fetched a specific document and send Deletes to those. However, that's doesn't seem practical.
-
-
@mariusor @nick AFAICT, Fediverse Delete is practically going to be "best effort" and not complete. The question is how much effort is an implementation willing to make. Only sending a Delete to followers and following collections seems to me to be minimal effort with minimal effectiveness. On the high effort side, an implementation could track every domain that's ever fetched a specific document and send Deletes to those. However, that's doesn't seem practical.
@steve so between impractical, minimal effectiveness, and scattershot wasting everyone's resources and time, which one is better in your opinion?
-
-
-
@steve 2.5GB of activitypub data out of a total of 3.4GB is not waste when I haven't seen the Creates that generated those Deleted entities?
-
-
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login