Pasture: Friendica joins, in the scenarios and the town

Friendica 2026.05 on the shared MySQL and Redis, with its worker daemon as a sidecar. friendica_settle repairs what
its install leaves: the system user has no name, so the system account that signs its fetches is never made; the web
container cannot see the sidecar's daemon, so a queued job waits for the five-minute cron unless the daemon is
declared running; its log needs a file and debugging on. Accounts are saved through its API with locked=0 (a number:
"true" reads as 0, unlocked), which makes them soapbox pages that take followers without following back, and each
one's outbox is read once: a Follow that reaches an account Friendica has not cached makes it fetch the account from
itself, signed, and checking that signature recursed for five minutes, holding PrivaPub's first follow past its timeout.

scenarios/friendica.sh passes its 25 checks from a clean install: follows and unfollows, posts (a titled one with its
title), comments, likes, Friendica's dislike as a downvote, boosts, edits (through its web editor: its Mastodon API
never federates one) and deletes, both ways.

The town gets a Friendica driver (HTTP Basic, its MySQL read through mysql_json, edits in the web editor, no bookmark
on a reply) and specs/friendica-pair.json, which passes its 275 checks. On the way:
- the checker knows Friendica's thread model: a non-public reply reaches an account only under posts it holds, and a
  Friendica account's non-public reply in a thread another server owns reaches nobody else there;
- the seeder answers a follow request the target still holds whatever the follower's server says: Friendica reports a
  follow of someone already following its account as made at once (and shows that persona's followers-only posts
  while a locked persona still holds the request);
- the selftest skips polls where a platform has none; the shared MySQL helpers move to peers/shared.sh.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LsXgEaXee4GCU1hwYgPJXw
This commit is contained in:
thepraandClaude Opus 5.5 committed 2026-10-05 10:14:02 +02:00
1 parent e485f7bd47
commit a5d493a8c9
17 files changed
+513 -31

No files matched your search

+28
View File
@@ -592,6 +592,34 @@ What it showed:
- `instrument{Service}` names the software.
- It sends **`Follow` with a post as the object**, meaning "include me in this thread". Answer that with `Reject` or
ignore it, without an error.
- It **forwards every activity in its threads** (comments and their deletions, other servers' included) to the
thread's followers, signed with the thread owner's key. PrivaPub answered them 401 until 2026-10-05; it now takes a
forwarded Create or Update as the object reads at its origin, and a Delete once the origin says it is gone
(`Forwarded`).
- An edit made through its Mastodon API never federates: `Statuses::put` leaves `edited` alone, and only a changed
`edited` notifies. Its web editor's edits do.
- Its own accounts' actors are cached only once something reads them. A Follow that reaches one first makes it fetch
the account from itself, signed as that account, and checking that signature builds the actor again: the request
recurses for about five minutes and holds the sender's Follow past a 15-second timeout (PrivaPub's retry gets it
through). Seen on a fresh install in the pasture, 2026-10-05.
- An incoming boost is kept with ActivityStreams' verb (`as#Announce`); its own are `/share`.
- Its activity ids are `uniqid()`, a three-character prefix and the microsecond: two of its processes answering two
follows at once gave both Accepts one id (town, 2026-10-05). PrivaPub queues an id that comes back carrying another
activity apart, so the second follow is not left pending.
- **It counts a follow as made before the Accept** when the target already follows its account (its "friend"
relation): its API answers `following: true` at once, and it shows the target's followers-only posts to that
account while a locked PrivaPub persona still holds the request (they reach Friendica's shared inbox for the
persona's accepted followers there, and Friendica hands them out by its own relations). PrivaPub refuses that
account's likes on them until the persona accepts. Town, 2026-10-05.
- It shows a reply to an account only inside a thread that account holds, and counts on the thread's owner to relay
the replies in it: a followers-only reply under a post the account cannot see never reaches it, from any server.
- Its "automatic friend" page type follows every follower back; the pasture's accounts are "soapbox" pages, which
take followers without asking and follow nobody back, as an unlocked Mastodon account does. Its Mastodon API makes
them so from `locked`, read as a number: `locked=true` unlocks an account.
- **Pasture evidence (2026-10-05, Friendica 2026.05, `tools/pasture/scenarios/friendica.sh`):** 25 checks pass,
from a clean install. Follows and unfollows both ways; posts both ways, a titled one arriving with its title;
comments both ways, threaded; likes both ways, Friendica's dislike as a downvote, alice's boost counted; edits and
deletes both ways; statistics.
- **Gaps:**
- **P1:** W2 for NodeBB Articles (`privapub.excerpt`).
- **P2:** Groups without `followers`; Announces from an Application; context Move/Remove; paged `context` with ETag;