Conversation

Notices

1.  (mint@ryona.agency)'s status on Wednesday, 03-Apr-2024 04:08:45 JST 

   • :blank:
   @i Do you think the database can be slimmed down a bit by purging all Announce activites from relays?
   •  (mint@ryona.agency)'s status on Wednesday, 03-Apr-2024 04:10:22 JST 

     in reply to

     • :blank:
     @i Yeah, I might be a bit desperate, but I think doing that and then patching pleromer to mark repeats received by relay as transient activities might improve performance a bit. For reference:
     pleroma=# select data->>'type', count(data->>'type') as count from activities group by data->>'type' order by count desc;
     ?column? | count
     ------------+----------
     Create | 17634612
     Announce | 15515144
     Like | 3522886
     EmojiReact | 1121150
     Update | 211598
     Undo | 82408
     Listen | 32560
     Follow | 6570
     Accept | 5663
     Remove | 2043
     Delete | 2037
     Block | 1040
     Add | 950
     Reject | 765
     Flag | 130
     Move | 55
     (16 rows)
   • :blank: (i@declin.eu)'s status on Wednesday, 03-Apr-2024 04:22:22 JST :blank:

     in reply to
     @mint yeah i've done it plenty of times because i'm retarded and follow 2000 relays, i've though about doing the same but never bothered
     
     delete from activities where inserted_at < now() - interval '30 days' and local = 'f' and data->>'type' in ('Delete','EmojiReact','Like','Announce');
      likes this.
   • :blank: (i@declin.eu)'s status on Wednesday, 03-Apr-2024 05:15:06 JST :blank:

     in reply to

     • munir
     @munir @mint the point of the relay is to receive a url so we can fetch it, and nothing else
      likes this.
   • munir (munir@fedi.munir.tokyo)'s status on Wednesday, 03-Apr-2024 05:15:07 JST munir

     in reply to

     • :blank:
     @mint @i doesn't that defeat the entire purpose of a relay
   •  (mint@ryona.agency)'s status on Wednesday, 03-Apr-2024 05:15:55 JST 

     in reply to

     • :blank:
     • munir
     @munir @i Relays are just special hidden accounts that repost all public posts. This adds a bunch of bloat after the post has already been fetched.
   •  (mint@ryona.agency)'s status on Wednesday, 03-Apr-2024 06:50:16 JST 

     in reply to

     • :blank:
     @i >i've though about doing the same but never bothered
     I think it can be tackled down with an MRF as well, just make it do fetch_object_by_id and then reject the Announce activity from relay.
   •  (mint@ryona.agency)'s status on Wednesday, 03-Apr-2024 07:16:57 JST 

     in reply to

     • :blank:
     @i This'll work. I think.
     https://gitgud.io/ryonagency/pleroma/-/commit/c8ec4e37476e8493860960c8a0cfcda19cf26d9a
   • :blank: (i@declin.eu)'s status on Wednesday, 03-Apr-2024 07:34:43 JST :blank:

     in reply to
     @mint :reject feels like asking for redelivery amplification trouble, there really should just be a silent drop option :drop where it lies that the activity was accepted without error
     
     but yes, mrf works best when the rest of the codebase is a mess
      likes this.
   •  (mint@ryona.agency)'s status on Wednesday, 03-Apr-2024 07:38:36 JST 

     in reply to

     • :blank:
     @i ** (ArgumentError) invalid right argument for operator "in", it expects a compile-time proper list or compile-time range on the right side when used in guard expressions, got: FollowingRelationship.following_ap_ids(Relay.get_actor())Retarded a bit with that, so replaced it with a regular if and force-pushed. Anyway, I think MRF rejected requests still return "ok", the refetch bug only applies to, well, refetches.
   • :blank: (i@declin.eu)'s status on Wednesday, 03-Apr-2024 07:57:55 JST :blank:

     in reply to
     @mint maybe it's just natural overlap on the non pleroma relays i've noticed, since i can see some stuff getting fetched more than a dozen times, still seems to be working fine, i'll refine it a bit later in the morning, but your version as is seems good enough for most
      likes this.
   •  (mint@ryona.agency)'s status on Wednesday, 03-Apr-2024 08:01:59 JST 

     in reply to

     • :blank:
     @i Maybe. When I was still using standalone relays, some instances were smart enough to drop their posts right into my inbox, bypassing the relay itself. fetch_object_by_id should first try to get the object from DB/cache before trying to fetch it, so I don't think it's at blame. Using RemoteFetcherWorker might be smarter, though.
   •  (mint@ryona.agency)'s status on Wednesday, 03-Apr-2024 08:12:43 JST 

     in reply to

     • :blank:
     @i handle_incoming in transmogrifier handles Like/EmojiReact/Announce activities, which then get passed to ObjectValidator.fetch_actor_and_object, Object.normalize and finally the same Fetcher.fetch_object_from_id. Unless I missed something, the MRF simply bypasses some of those calls.
   • :blank: (i@declin.eu)'s status on Wednesday, 03-Apr-2024 08:14:30 JST :blank:

     in reply to
     @mint reached the same conclusion reading over the code, i'll still do the RemoteFetcherWorker bit just so there's a retry to ddos flaky instances even further
      likes this.
   •  (mint@ryona.agency)'s status on Friday, 31-May-2024 03:49:26 JST 

     in reply to

     • :blank:
     @i Apparently the referenced objects get fetched before the Like/Announce/whatever gets filtered by MRF, just saw that behavior when adjusting the nonce filter. So, separate fetch_object_from_id is unneccessary, unless you also do this (which I did as it's needed for proper functioning).
     https://gitgud.io/ryonagency/pleroma/-/commit/a78c8aeb0bee0287c368a7b145de79a23cb6e351
   • :blank: (i@declin.eu)'s status on Friday, 31-May-2024 04:35:26 JST :blank:

     in reply to
     @mint good catch, though i just {mrf_tag:force-unlisted} instead
      likes this.