"We put the exploit in a picture. The AI code reviewer never opened it."
This line from the article:
CodeRabbit ships with a default configuration that excludes image files from review outright (!**/*.png)."We put the exploit in a picture. The AI code reviewer never opened it."
This line from the article:
CodeRabbit ships with a default configuration that excludes image files from review outright (!**/*.png).@silverpill i don't know about anyone else, but the thing i'm personally bumping up against now is people trying to post about events without being able to properly model events in the fediverse.
a good question! one and the same thing for me. i'm just tired of having to go "somewhere else" to interact with events. fwiw, my personal bar is pretty low, but i increasingly think this is a major missing piece.
how widely adopted/supported/implemented is FEP-8a8e? is that a safe direction to converge for federated events?
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?!?
@silverpill what's the entry point for trying this out? consuming portable objects?
Before creating and publishing FEDERATION.md for #ktistec I wanted to understand what existing practice looked like across the Fediverse.
FEP-67ff describes the requirements of the FEDERATION.md file in loose terms and provides a non-normative template. I scraped the URLs of FEDERATION.md files from FEP-67ff itself and confirmed I could fetch them. The FEP listed 30 accessible projects (31 total, but one project—FIRM—does not appear to exist).
If a file had a section with the heading "Supported FEPs" per the non-normative template, I only looked there for supported FEPs. Otherwise I scanned the entire document.
Implemented FEPs, ranked by the number of implementations that attest support, are:
FEP Name # ---- --------------------------------------------------------- -- 67ff FEDERATION.md 18 f1d5 NodeInfo in Fediverse Software 16 8b32 Object Integrity Proofs 7 044f Consent-respecting quote posts 7 2677 Identifying the Application Actor 7 e232 Object Links 6 1b12 Group federation 6 3b86 Activity Intents 6 521a Representing actor's public keys 5 2c59 Discovery of a Webfinger address from an ActivityPub actor 5 7888 Demystifying the context property 5 5feb Search indexing consent for actors 5 4adb Dereferencing identifiers with webfinger 4 d556 Server-Level Actor Discovery Using WebFinger 4 fb2a Actor metadata 4 ef61 Portable Objects 4 8fcf Followers collection synchronization across servers 4 844e Capability discovery 4 7628 Move actor 3 61cf The OpenWebAuth Protocol 3 c390 Identity Proofs 3 400e Publicly-appendable ActivityPub collections 3 c0e0 Emoji reactions 3 0151 NodeInfo in Fediverse Software (2025 edition) 3 fffd Proxy Objects 2 f228 Backfilling conversations 2 fe34 Origin-based security model 2 eb48 Hashtags 2 171b Conversation Containers 2 a5c5 Web Syndication Methods 2There are obvious flaws in the methodology. Or maybe in the data. Only 18 out of the 30 projects I could access had a FEDERATION.md that attested FEDERATION.md support. Only 19 mentioned "FEDERATION.md". Only 21 mentioned "67ff". The remaining projects clearly did support FEP-67ff—the file itself was evidence. (FEDERATION.md is not meant to be machine readable—there's an issue about that).
It was more difficult to rank implemented federation protocols. I extracted keywords from documents with a "Supported federation protocols and standards" section and created a dictionary of terms. If a file had a section with the heading "Supported federation protocols and standards", I only looked there. Otherwise I scanned the entire document.
Feature # ---------------- -- activitypub 26 webfinger 24 http_signatures 21 nodeinfo 19 json_ld 2 ld_signatures 2 ostatus 2 authorized_fetch 1 atproto 1If time allows, I'm going to try to rank these documents by "utility", though I haven't yet determined the exact metric. These documents clearly provide valuable information, but their lack of standardization makes them harder to analyze systematically.
sometimes i wish #activitypub and servers/clients supported both Like and Love activities, for when liking something isn't strong enough...!
I wonder if you could use/abuse Mastodon polls (FEP-9967) to distribute posts that provide near-real-time status updates (I'm thinking about severe weather alerts but I'm sure there are other use cases)?
Create a poll with an expiry far in the future and a token set of options (ideally just one—"Do you opt in?"—but poll implementations seem to require at least two).
Nothing seems to prevent the content of a poll from changing—and this is the key insight. The FEP says, "The type of a poll (single choice / multiple choices) and its options might be changed at any time. In that case the author of the poll MUST reset the vote counts." So broadcast updates via the content.
It would be a lightweight way to follow a single item without following the actor, built on top of implementations that already exist.
With the addition of the @ktistec account, Ktistec (the server) now supports multiple users.
I still have a few rough edges to fix, but there's a good chance official multi-user support will be included in the next release.
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.
sometimes the world is just breathtaking...
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.