Untitled attachment

Notices where this attachment appears

1. Embed this notice
   ZOP (zop@7td.org)'s status on Wednesday, 07-Jan-2026 02:34:35 JST ZOP

   For anyone backing up a pleroma instance DB, if you're using an sql backup (all variants of pg_dump) - YA DON'T HAVE A WORKABLE RESTORE WITHOUT SOME MASSAGING! You MUST have indexes pre-created to load data. Post creation of indexes effectively won't work...unless your DB is small.

   Soooo I think I know what causes the restores to basically never complete, maybe...I'm near the limits of my psql debugging capability because I've never hit this so I actually don't exactly know how to see what the CREATE INDEX is actively doing... But tl;dr; 1.8T rows. One Point Eight TRILLION rows. But...HOW?!

   The dump+load upgrade method I tend to use causes this. In the default mode it creates the schema (sequences setup, all the functions, that sort of thing, BUT NO INDEXES), loads the data, then creates the indexes.

   The index it's never finishing creating is calling this function:

   CREATE OR REPLACE FUNCTION public.activity_visibility(actor character varying, recipients character varying[], data jsonb) RETURNS character varying LANGUAGE plpgsql IMMUTABLE PARALLEL SAFE SECURITY DEFINER AS $function$ DECLARE fa varchar; public varchar := 'https://www.w3.org/ns/activitystreams#Public'; BEGIN SELECT COALESCE(users.follower_address, '') into fa from public.users where users.ap_id = actor; IF data->'to' ? public THEN RETURN 'public'; ELSIF data->'cc' ? public THEN RETURN 'unlisted'; ELSIF ARRAY[fa] && recipients THEN RETURN 'private'; ELSIF not(ARRAY[fa, public] && recipients) THEN RETURN 'direct'; ELSE RETURN 'unknown'; END IF; END; $function$

   Well. users is ~500k rows, and this function would be called for the ~3.7M activities rows....at a point in time where users has no indexes! So each invocation of activity_visibility would scan ~500k rows, times 3.7M rows in activities, and .... that's ~1.8T rows.

   Why did I footgun myself like this when pg_upgrade exists? Well, binary incompatibilities, index collation differences, in the past causing Major Heartburn. I'm not going to dive into how it might be possible to fix the dump+load procedure, since, well, yeah. But for anyone backing up a pleroma DB be warned. Either take a binary copy (f/ex pg_basebackup) or dump schema and data seperately so you can load the data with indexes. Or find another workaround!

   cc @feld

2. Embed this notice
   silverpill (silverpill@mitra.social)'s status on Wednesday, 24-Dec-2025 04:41:05 JST silverpill

   I think this is too complicated. Also, Move is meant to be used when origin and target are collections, but in the FEP they are both actors.

   Why not Update?

   Or, if you want to be explicit, consider introducing a new activity? For example, UpdateAudience:

   { "id": "https://example.social/update-audience" "type": "UpdateAudience", "actor": "https://example.social/uid/1", "to": ["https://www.w3.org/ns/activitystreams#Public"], "cc": [ "https://example.social/audience/1/followers", "https://example.social/audience/2/followers", ], "object": "https://example.social/context/1", "prevAudience": ["https://example.social/audience/1"], "nextAudience": ["https://example.social/audience/2"], }
3. Embed this notice
   silverpill (silverpill@mitra.social)'s status on Tuesday, 02-Dec-2025 18:27:07 JST silverpill

   in reply to

   @phnt C2S API has always been a solution looking for a problem, but it is similar enough to FEP-ae97 API, so I have no issue with people devoting their time to fixing C2S.

   However, almost nobody actually works on it. There is a lot of cheap talk, but anyone who actually tries to implement C2S quickly realizes how broken it is and gives up. Most progress so far has been made by a single developer (btw: I began to document some aspects of his implementation in FEP-9f9f: Collections).

   >fixing the complete mess of a specification and making a v2 spec that isn't ambiguous and open-ended as a typical corporate privacy policy

   The working group is too busy renaming https://www.w3.org/ns/activitystreams#Public to as:Public

   @julian @django

4. Embed this notice
   Phantasm (phnt@fluffytail.org)'s status on Friday, 07-Nov-2025 19:45:02 JST Phantasm

   in reply to
   @sun @SuperDicq @mint Yes... and there are people pushing for banning usage of https://www.w3.org/ns/activitystreams#Public entirely in favor of as:Public just for JSON-LD reasons, because apparently JSON-LD parses can't cope with the URI.
   
   Have fun: https://github.com/w3c/activitypub/issues/404 and third in point in https://www.w3.org/wiki/ActivityPub_errata/Proposed
5. Embed this notice
   Phantasm (phnt@fluffytail.org)'s status on Friday, 07-Nov-2025 19:28:22 JST Phantasm

   in reply to
   @mint @SuperDicq @sun Yeah, it's the JSON-LD brain damage that nobody supports and some idiot in the GitHub issue is still pushing for this and banning https://www.w3.org/ns/activitystreams#Public
   
   My example is taken from the DB.
6. Embed this notice
    (mint@ryona.agency)'s status on Friday, 07-Nov-2025 19:25:59 JST 

   in reply to
   @phnt @SuperDicq @sun Theyl iterally put "as:Public" instead of https://www.w3.org/ns/activitystreams#Public.