Texan_ReverendFeb 25

RE: https://mementomori.social/@rolle/116125657344469470

Now would be an excellent time for @Mastodon devs to prioritize the inclusion of tootctl-style status and media clearing options in the default Admin interface. These issues have been sitting open on GitHub for literal years at this point.

Across the network, we need better and more accessible means of managing database and media storage sizes to keep costs more affordable and to reduce server closures. This need is only becoming more and more pressing as infrastructure costs climb.

Show threadTexan_ReverendFeb 25

In case you're a non-admin user and not familiar with what those features are:

Database storage holds all posts that a server has ever seen - everything posted there, everything that's ever passed through the Federated Feed, etc.

Media storage is all the photos, videos, and audio files that have been included in posts - they are stored separately and effectively linked to by their respective posts.

Show threadRockarioFeb 25

@Texan_Reverend I do wish that users had an easier way to look at their media storage footprint and potentially bulk-delete posts.

Cause you know, love to send memes and dumb images, but at a certain point I kinda want to just get rid of the posts and save the images myself if I think they're worth reposting.

Show threadTexan_Reverend

@rockario While I agree that users would benefit from more options & controls over their posts, that's not the big issue for admins.

I don't need or want to purge what people post on Kind.Social, and I don't want folks here to think they have to limit their posting _at all._

The issue is eight years of posts from Mastodon.Social and countless other servers which nobody here ever interacted with and perhaps never even saw.
We don't need to hold these.
We don't need _every server_ to hold these.

Feb 25 at 3:15amWeb
Show threadRockarioFeb 25
@Texan_Reverend Agree 100%
I had that "clean up after myself" instinct start even in the first year on here, but that's just a personal thing. Keeping all those old nothing posts from connected servers is not a good design.
Show threadTexan_ReverendFeb 25

@rockario To an extent, I get it and agree with it. Having each server store what it sees so that their users are pulling from local storage rather than hammering other servers with requests for the same post is good.
There just needs to be a limit.

On Kind.Social, I would aim for not keeping posts from other servers beyond a year unless they'd been interacted with.
That still ensures you can see plenty of post history on someone's account.

Show threadblackcoatFeb 25

@Texan_Reverend @rockario Would it be possible to have those posts from local storage still be available to pull from their originating instance?
So, [email protected] posts a picture, nobody sees it, it gets purged, two years later, [email protected] is flipping through alice's posts, gets to the end of the local storage, kind.soc throws off a "hey, gimme the next hundred posts and I'll store them again", then they get purged?

that way history can still get cached locally, but preserved?

Show threadTexan_ReverendFeb 25

@blackcoat @rockario The short answer is that the backend doesn't currently work in a way that would support that. I think it could be useful to have some method of asking your own server to check for more posts on a remote user's profile, similar to the current system for loading more replies to a post when they've been found.

However, the way it works now is that a server stores new posts from remote accounts after those accounts have become known to it - through user searches, follows, etc.

Show threadTexan_ReverendFeb 26

@blackcoat @rockario I also want to make sure something's clear. In your example, you had someone on a remote server looking for the posts of someone else on that server; that wouldn't involve Kind.Social's server settings at all.

I'm assuming you meant something like:
Old posts from [email protected] get purged due to lack of interaction.
Then, [email protected] scrolls their profile, reaches the end of stored posts, and wants Kind.Social to pull remaining ones from Mastodon.Social.

Show threadblackcoatFeb 26
@Texan_Reverend @rockario Yeah, that's exactly the scenario I was envisioning. At that point, the pull and recache is invisible to blackcoat@kind, with the exception of maybe some network delay. (or maybe there's some UI of "hey, would you like us to see if there are other posts on that server?")
Show threadblackcoatFeb 26
@Texan_Reverend I don't know enough about how the masto/fedi backend works, and I'm not pitching for wholesale rewrites (If I was that interested, I'd go make my own PRs), but I was just wondering if something like that might alleviate some of the "but what about lost history" woes. It wouldn't require masto.soc to constantly be feeding network requests, but we don't have to fully duplicate all info for all time.
Show threadTexan_ReverendFeb 26

@blackcoat If nothing else, the full post history of a given user is always available by viewing their profile on their server's site.
Navigate to their profile normally, select the three-dot menu, select "Open original page."

That said, we'd all love a smoother method that doesn't involve leaving your own server and not being able to easily fav or boost whatever new posts you see there.

Though at the moment, that would be an entirely new project with significant changes to existing structure.

Show threadTexan_ReverendFeb 26
@blackcoat @rockario Yeah, the UI you're describing is very similar to the one currently in place for fetching additional replies to a post. A little pop-up shows at the bottom of the screen saying "More replies found" and gives you an option to click/tap "Show" to retrieve them.