There are additional costs that aren't factored in (although they're not specifically lemmy, and I pay for them myself rather than use donations) such as a very cheap vps for our status.lemmy.zip page and i got a 3 year deal for an external email provider for less than some email providers wanted a month.

Our server is the same one feddit.uk use (a hetzner auction server) although lemmy.zips I think was a touch more expensive per month. But it's got a lot of room for growth.

Also we now host all our backups offside too, which adds a little on top. I'll probably cover this in the next server update.

Nice, I'd seen you'd stopped a while ago but I'll look at hosting it if it's back alive.

It has

Or do you have an existing project that requires additional effort to enable further development?

So I assume the Lemmy devs should be good to reapply.

Here's a handy site to check your federation status: https://phiresky.github.io/lemmy-federation-state/site?domain=social.packetloss.gg

It looks like all the sites are lagging, which can sometimes mean there is an issue. What's the specs of the server? Can you try restarting it and seeing if that helps?

There are issues for servers hosted in places like Australia because of the latency in communicating with .world due to how big it is and how much data it sends because of this.

Pop got me into Linux in July 2021 (i switched the same time as the steamdeck was announced) and I ran Pop for a good two and a half years. Great distro.

Now I'm on EndeavourOS, but it was Pop that helped me make the transition.

Mostly yes. As it was abandoned by the mod I'm using it to test rss feeds and some of the other bots functions while trying to populate some content into the community rather than let it lie dormant.

Not directly, but you can go to browse.feddit.de and type the instance into the search bar to get a list of communities

Most other social networks allow users to select whether they are reporting a violation of community rules, or site rules as whole.

Why not take this approach to simplify it then?

Asking the user to specify who they think should receive a report feels like it will add confusion (not to mention is subjective anyway), and could create delays in responding to important stuff if the user picks the "wrong" option. If a user picks the mod option on csam report then it might get missed by an admin? At least the option between "this community" or "site rules" is a bit clearer.

This is to prevent cases of admins accidentally preventing mods from moderating according to their own community rules

As an admin I should be able to respond to a mod report on a community if I'm there first and its urgent, i.e. csam. This is a policy/discussion point between mods and admins on any given instance and shouldn't be enforced in the software. Separation for clarity's sake is fine, I even encourage that as I don't tend to touch a report for a community anyway as it stands, but I should be able to mark a report complete if I have dealt with it. Otherwise I'm just going to go to the post and sort it out anyway, so its just adding complexity.

Admins can still always explicitly take over communities by making themselves mods, in this way, they are able to handle mod reports for any abandoned communities, etc

Barriers/extra steps to administration is not the way forward here. Continuing with Admins being able to mark reports resolved just makes sense.

Alternatively, we could make reporting even more granular. It would be possible to allow users to select only a specific instances admins as the intended report audience, for example.

No. This is a step backwards in transparency and moderation efforts. Granularity and more options is not always a good thing. If you've ever had the misfortune of using Meta's report functionality you'll know how overly complex and frustrating their report system is to use with all their "granularity".

Simplicity of use and getting a report to someone who can do something about it quickly should always be the priority, adding options and functionality should be secondary and support this. If you don't want to be stepping on moderators toes, make that clear in your guidelines and processes.

I am legally on the hook for content on my instance, not the moderators, and proposing changes that make it harder to be an admin is a touch annoying.

To add: I would suggest thinking about expanding this to notify the user a report has been dealt with/resolved, optionally including rationale, because that feedback element can sometimes be lacking.

Nice solution, thank you :)

Thanks, this doesn't pull only unread comments - if I pull the latest 5 comments and then mark those overarching posts as read, I get this:

2024-02-02 09:52:11,278 - INFO - Requesting API Request.GET /comment/list
2024-02-02 09:52:11,507 - INFO - Requesting API Request.POST /post/mark_as_read
Post ID = 9335073
Comment ID = 6915381
2024-02-02 09:52:11,629 - INFO - Requesting API Request.POST /post/mark_as_read
Post ID = 9007864
Comment ID = 6915380
2024-02-02 09:52:11,742 - INFO - Requesting API Request.POST /post/mark_as_read
Post ID = 9319139
Comment ID = 6915382
2024-02-02 09:52:11,916 - INFO - Requesting API Request.POST /post/mark_as_read
Post ID = 9334778
Comment ID = 6915379
2024-02-02 09:52:12,100 - INFO - Requesting API Request.POST /post/mark_as_read
Post ID = 9283396
Comment ID = 6915378

If I then pull the 5 latest comments again:

2024-02-02 09:52:12,238 - INFO - Requesting API Request.GET /comment/list
2024-02-02 09:52:12,380 - INFO - Requesting API Request.POST /post/mark_as_read
Post ID = 9335073
Comment ID = 6915381
2024-02-02 09:52:12,521 - INFO - Requesting API Request.POST /post/mark_as_read
Post ID = 9007864
Comment ID = 6915380
2024-02-02 09:52:12,673 - INFO - Requesting API Request.POST /post/mark_as_read
Post ID = 9319139
Comment ID = 6915382
2024-02-02 09:52:12,835 - INFO - Requesting API Request.POST /post/mark_as_read
Post ID = 9334778
Comment ID = 6915379
2024-02-02 09:52:12,977 - INFO - Requesting API Request.POST /post/mark_as_read
Post ID = 9283396
Comment ID = 6915378

Which is the same 5 comments - so what I'm looking for is a way to pull only previously "unseen" comments - that would reduce the amount of data returned from the api each time i check the list if there was only 1 or 2 comments rather than returning all 25.

Apps can indicate that there are new unread comments on a post, but I assume they're not doing this via the api and its a UI thing to do with caching?

I may not have explained myself clearly here, though!

I could entirely be wrong, but I dont see anything obvious in the api that indicates this is a function of the api. You could potentially use markPostAsRead after scanning each comment, but I don't see a way of pulling only new unread comments after that. Would love to be proven wrong though :)

I've pushed the change so operators can change those values in the env file or via docker. Btw let me know if you do start work on the megathread thing, it does pose an interesting challenge in terms of structuring posts and handling that data.