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:
1 parent
e485f7bd47
commit
a5d493a8c9
17 files changed
+513
-31
No files matched your search
@@ -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;
|
||||
|
||||
Reference in new issue
Block a user