The last two releases of Ktistec added backend and frontend support for algorithmic feeds. This release adds polish and links it into the navigation alongside posts, drafts, and bookmarks.

Algorithmic feeds are feeds that include (and exclude) posts with certain keywords, hashtags, and mentions. They are built on top of the materialized views that I introduced a few months ago. And they're fast!

The implementation will evolve toward something that looks like Mastodon's advanced web interface, Misskey antennas, or Friendica channels.

Here's the full changelog:

Added

• Link to feeds index page from secondary menu.
• Garbage collect abandoned feed drafts and orphaned feed state.
• Backfill feeds with historical posts.

Fixed

• Quote post request, authorization, and release fixes.
• Recognize a swipe anywhere in the image viewer.

Changed

• Feed editor usability improvements.
• Bust the asset cache when a bundle's contents change.

I'm currently deep in adding shared inbox support. A few servers insist on delivering to /inbox (whether or not Ktistec actors advertise a shared inbox).

#ktistec #crystallang #activitypub #fediverse

I shipped back-end support for algorithmic feeds in the last release. In this release I shipped front-end support. The feature needs testing and polish, so it's still not possible to navigate to the feeds editor, but if you know where to look, you can try it 😉.

"Algorithmic feeds" currently means support for custom hashtag, mention, and keyword feeds (e.g everything that mentions "#fediverse" and "#activitypub" but not "x" or "facebook").

Here's the full changelog:

Added

• Front-end support for user-defined algorithmic feeds.
• Allow editing optional properties on published posts.
• Support undoing a dislike.

Fixed

• Handle concurrent duplicate inbox delivery.
• Don't apply custom themes on the drafts and posts pages.
• Adapt duration units in thread analysis.
• Restore the spinning loader.

Changed

• Restrict theme overrides to color and reduce reliance on !important.
• Render the homepage description in a basic segment.

Removed

• The deliver_to state and the recipients fallback.

In the next release, algorithmic feeds get wired into the navigation!

#ktistec #crystallang #activitypub #fediverse

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

the backend for ktistec algorithmic feeds just landed in commit 627c9292.

it's a proof-of-concept implementation of hashtag-mention-keyword feeds popular in other servers with any/all/none clauses—not very algorithmic but it gets the plumbing right and tested. it builds on top of the materialized views support i implemented a few releases ago.

#ktistec #fediverse

i'm sure inline json-ld contexts with server extensions seem like the wrong thing, but they're preferable to identical copies of the same context hosted externally and served by a dozen or more instances of a server or family of servers.

i could be persuaded to change my mind if a server allowed meaningful customization. but if a server is publishing a canonical vocabulary of extensions for that server, it should be hosted in a single, well-know location.

#fediverse #activitypub

I started to work on algorithmic feeds but was side-tracked by interoperability work. No complaints. It turned out to be a productive detour.

Here's the full changelog for release v3.7.0 of Ktistec:

Added

• Support FEP-2c59: Discovery of a Webfinger address from an ActivityPub actor.
• Support ActivityPub Update activities for actor profile changes.

Fixed

• Disambiguate reblog IDs from status IDs. (fixes #151)
• Correct the quote_policy mapping to public/nobody values.
• Ignore malformed pagination parameters instead of raising.
• Treat "cannot be reconnected" errors as connection failures.
• Infer a media attachment's type when mediaType is missing.
• Faster, case-insensitive, actor username lookups.
• Faster statuses_count using an approximate count.

Changed

• Resolve JSON-LD contexts by matching their digest against a bundled copy.

The first version of algorithmic feeds won't be very algorithmic—it will let you create a feed that filters by keywords, hashtags, and mentions. That covers a lot of ground for me personally, and lays the groundwork for future enhancements.

#ktistec #crystallang #activitypub #fediverse