#ktistec

@benpate@mastodon.social @mro@digitalcourage.social i have the advantage of running my own server software (#ktistec) so i have lots of levers. right now it comes down to mostly 1) liberal blocking and 2) effective "algorithmic" feeds (that just means flexible hashtag, mention, keyword filtering and they're still work in progress). so far i haven't had to resort to blocking instances. it's a good question though. like i said, i came here as a refugee myself and my goal is to build my own "safe space" on the fediverse. i just don't think anyone should be the arbiter of anyone else's definition of "safe space".

There are two significant new additions in release v3.8.0 of ktistec. First, the actor cards on the followed/following pages show relevant actor status. On the followed page, it tells you how long it has been since that actor published an activity (create, announce, like, etc.) that was sent to your server. It's a proxy for how active they are (or are not). On the following page, it tells you how long it has been since you have been able to send to that server. It's a proxy for whether that server is reachable or that actor is still alive. Second, the backend for user-defined algorithmic feeds is in place, along with a keyword/hashtag/mention feeds implementation. You can't set up a feed via the user-interface, but the feeds work if you set one up directly in the database—which is how I've been previewing them. I plan to release the frontend next week. Here's the full changelog: Added Display activity status on actor cards.Back-end support for user-defined algorithmic feeds.Apply community-relayed moderator deletes received as a Group's wrapped Announce.Follow a web page's rel="alternate" link when searching. Fixed Avoid loading entire has_many collections when constructing child records.Evaluate the same-origin fetch gate against an embedded node's own identifier.Accept a delete of an uncached object or actor without verification.Catch MIME::Multipart::Error in local file-upload handling.Map malformed request-body parse failures to Bad Request. #ktistec #crystallang #activitypub #fediverse

This release fixes a small number of bugs found in recent releases. The full changelog: Fixed Prevent runaway recursion when handling filtered posts.Ensure profile header and header_static images are always present.Render the inline replies collection for local objects.Exclude blocked actors from object statistics and notifications. Changed Return 410 Gone instead of 404 Not Found for missing actors. Removed Tag counts on public pages. This release fixes a hard-to-exploit but potentially server-crashing bug. If you're running v3.3.9 or v3.4.0, you should upgrade. #ktistec #crystallang #activitypub #fediverse

Release v3.3.9 of Ktistec continues the security hardening work from recent releases, with further progress on the Mastodon-compatible API. Of note: all network connections now go through a new Ktistec::Network module. This allows Ktistec to limit the size of HTTP bodies it reads, on both inbound and outbound requests, and ensures it only opens connections to valid remote IP addresses. Here's the full changelog: Added New Mastodon-compatible APIs. Fixed Close DNS rebinding window for outbound HTTP requests.Limit the size of HTTP bodies the server reads.Sanitize RSS feed output to prevent CDATA breakout.Destroy all sessions and access tokens on account termination. Changed Ensure all GET and POST requests utilize Ktistec::Network.Process local recipients in-process in inbox/outbox activity processors. As always, it's worth upgrading for the security fixes! #ktistec #crystallang #activitypub #fediverse

I’m working on handling OAuth token expiry as part of #ktistec Mastodon API support. Is my understanding that Mastodon issues OAuth tokens with no expiration correct?!?