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?
#activitypub 13 hashtags
I just released v2.4.0 of Ktistec. This release encompasses a few things that I've been working on for a while: improved support for operating without JavaScript available/enabled and support for running scripted automations.
Except for a few items, Ktistec now works without JavaScript. Obviously, things like WYSIWYG editing of HTML don't work—I plan to add support for Markdown to compensate. Running in Lynx is a stretch, but...
Since the early days, most controller actions supported both text/html
and application/json
. I cleaned up support for the latter and have officially documented the Ktistec API in the README.
In addition, I've added support for running bots/automations (prior announcement). The Ktistec server will periodically run any executable script in the etc/scripts
directory. These scripts have access to the Ktistec API and can post, follow, share, like, etc. This is experimental and obviously introduces an attack surface, though that shouldn't be a problem on correctly configured hosts.
Here's the full changelog:
Added
Fixed
Changed
formaction
. (fixes #101)Other
I've been thinking about the demise of botsin.space. Running a site for bots is hard (and expensive) but writing and running an ActivityPub-based bot should be easy.
To prove this was the case I added experimental support for bots/automations to Ktistec in the form of scripts that the server periodically runs. These scripts can be in a programming language of your choice. The server provides credentials for its API in the process environment (if you can use curl you can publish posts), simple interaction happens via stdin/stdout/stderr, and the complexity of using ActivityPub is abstracted away.
The code is only available on the following branch for the moment:
https://github.com/toddsundsted/ktistec/commits/run-scripts/
There are a couple example shell scripts here:
https://github.com/toddsundsted/ktistec/commit/4982925a...
I have a few enhancements in mind, but it's already proven useful as a means to periodically log data from my server host, and I'll use it, when finished, to publish release notes.
TIL scripting media queries... gone are the days of the no-js
class on the body
tag...
i'm working on improving the ktistec user experience when javascript is disabled.
ktistec uses trix as its rich text editor. of course. trix doesn't work without javascript. behind the scenes, however, trix uses a hidden textarea
to hold the body of the post being edited. using scripting media queries, ktistec can now show (or hide) either the editor or the textarea
based on the availability of javascript (2030b26b).
I just released v2.3.0 of Ktistec. It fixes a few bugs introduced in the previous release. In particular, it handles a case I've observed a few times in production where the fetching of followed content hangs. The fix adds a monitor that periodically checks for "running" tasks without a backing fiber and sets socket timeouts to ensure requests eventually terminate (I believe the latter actually fixes the problem, but belts and suspenders...)
#ktistec #crystallanguage #crystallang #activitypub #fediverse
this chart shows inbound activitypub messages to my server. over time fediverse instances seem to receive increasing numbers of messages, many not addressed to anyone on the instance, so this represents an increase in that passive traffic, replies to other people's posts, as well as announcements/boosts/shares.
n.b. you can see all of the inbound messages to your ktistec server on the /everything endpoint.
among other improvements, document how rules work.
it's now possible to customize how ktistec processes ActivityPub inbound and outbound activities without having to write crystal language and recompile the server.
i'm still making lots of small changes/improvements to ktistec: upgrading dependencies, fixing bugs, and cleaning up. i'm laying the foundation for improvements to the experience of reading posts on your ktistec instance—a reactive user interface with streaming updates/notifications, the ability to follow arbitrary collections of objects, and a timeline that can flexibly highlight content you find interesting (vs. displaying posts in chronological order). underpinning all of this is a flexible, scriptable, rule-based language for customizing the experience.
it would be nice to have a way to federate users around topics or areas of interest, without having to join a specific server. it would make it easier for people to discover each other based on interests, regardless of the server they join. federated interests...?
i don't know about this decision:
It is suggested that LitePub implementations supply a locally hosted version of the LitePub JSON-LD Context as their @context.
what i see in practice (N > 100) is the same "litepub-0.1.jsonld" context but different URLs. all of these identical contexts have to be fetched, parsed, cached (hopefully).
it seems wasteful.