This action will delete this post on this instance and on all federated instances, and it cannot be undone. Are you certain you want to delete this post?
This action will delete this post on this instance and on all federated instances, and it cannot be undone. Are you certain you want to delete this post?
This action will block this actor and hide all of their past and future posts. Are you certain you want to block this actor?
This action will block this object. Are you certain you want to block this object?
Are you sure you want to delete the OAuth client [Client Name]? This action cannot be undone and will revoke all access tokens for this client.
Are you sure you want to revoke the OAuth token [Token ID]? This action cannot be undone and will immediately revoke access for this token.
#ktistec 209 hashtags

every so often i crank inbox logging up as loud as it will go and then spend the next two weeks fixing federation bugs. this is apparently the start of those two weeks.
fixing issues with http signatures now...

Release v3.12.1 patches a bug that's been present for about two years and fixes issue #163 in the process. Looking at FediDB, it appears most servers on v3.X.X made it through the upgrade to v3.5.0, which is where the bug would have bitten, but the consequences of the bug are annoying enough that a patch is warranted.
Changed
Up-to-date query statistics ensure that the expensive migration in v3.5.0 completes in seconds or minutes, instead of hours!

This release encompasses two broad sets of changes: widening the pool of candidates for feeds and more carefully checking the origin of inbound activities (broadly FEP-fe34, Origin-based security model).
Candidates for feeds were originally limited to posts in the actor's mailboxes. This decision made authorization easy but omitted clearly acceptable posts (for example, posts addressed to the public collection) that arrived via other means (for example, filling in a thread).
Prior to this release, inbox processing did not consistently define an object's origin nor did it apply consistent rules to what it admitted based on the origin.
FEP-fe34 is still not fully enforced, and truth be told, I'm still reviewing some of its mandates, so I'm not yet listing it in Ktistec's federation documentation.
Here's the full list of changes:
Added
Fixed
Create and Update to update objects.Changed
Removed
proxyUrl property from the actor document.I am still working hard on the feed deck. Both notifications and feed ordering now work. It's now my preferred reading interface, and should be ready by the next release!

Despite the fact that a shared inbox is an optional actor endpoint, some servers assume Mastodon and deliver to /inbox instead of the actor's inbox. Okay, fine. This release of Ktistec includes support for shared inboxes.
🖐️🎤
Here's the full changelog:
Added
Fixed
closed namespace, and treat closed and endTime interchangeably.highlighted CSS class.Changed
My current passion project is the Ktistec feed deck—multiple, parallel panes in the same window, each displaying an algorithmic feed. It will be in usable shape in time for the next release.

The culmination of my recent work on algorithmic feeds is a #fediverse feed reading machine for all of the topics I care about.


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
Fixed
Changed
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).

i just released it and i'm already pretty happy with #ktistec hashtag/mention/keyword feeds. i created an "ActivityPub Talk" feed and i have most/all ActivityPub/Fediverse/FEP/etc. etc. etc. talk in one place.

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
Fixed
Changed
!important.Removed
deliver_to state and the recipients fallback.In the next release, algorithmic feeds get wired into the navigation!

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
Announce.rel="alternate" link when searching.Fixed
has_many collections when constructing child records.MIME::Multipart::Error in local file-upload handling.Bad Request.
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.