Conversation
Notices
-
@meowski @lain
> a post on a microblog site isn't a personal email to your inbox. it also gets fetched in the future by others.
Yes: a mail server doesn't necessitate a quadratic deliveries table to track who has fetched what so that the edits actually do arrive at the servers that have the post. Different message contents mean a different message, which ought to (but on most servers does not) mean a different message ID.
> i was a resister for a while but do edit them sometimes now
Did games get better or worse once day-one patches became common practice?
resist.jpeg
-
@p @meowski @lain Just type your posts carefully in a nice text editor. Compose your thoughts and express yourself, like an adult. When you still fuck up, write a short apology in response.
Are we not all gentlemen? Let us conduct ourselves accordingly.
-
@pwm @meowski @p @lain I agree.
oldchad.jpg
-
@p @meowski @lain >Yes: a mail server doesn't necessitate a quadratic deliveries table to track who has fetched what so that the edits actually do arrive at the servers that have the post
Neither does Pleroma, I believe, it delivers Update activities to the same recepients it has delivered the initial Create activity, that being followers and thread participants.
-
@p @meowski @lain Still, it's no more complex than making a reply in the first place. Here's the part that determines recepients in the initial commit, then it goes through the same pipeline that gets the full list of servers to deliver to as the rest of outgoing activities do.
https://git.pleroma.social/pleroma/pleroma/-/commit/b613a9ec6b68972c81dfe2f0175572bc7bd547f9#289f15f85a249dd0412330335c37fa668a79c814_225_229
>Unless something has changed
Might have; deliveries table on all five instances I host have zero rows. Though that also might have something to do with either signed fetches being off or the caching on reverse proxy.
-
@mint @lain @meowski
> it delivers Update activities to the same recepients it has delivered the initial Create activity,
O(n*m).
> that being followers and thread participants.
Unless something has changed, deliveries also includes signed fetchers, for the sake of deletes at least.
-
@mint @lain @meowski
> Still, it's no more complex than making a reply in the first place.
The fedi version of the handshake problem was a problem to begin with. It's especially bad with deletes, but this isn't any good.
> Might have; deliveries table on all five instances I host have zero rows.
Yeah, I truncated it and then gutted the code that writes to it and that eliminated a big performance sink.
> caching on reverse proxy.
Something must have changed, because it used to add a row for every "POST /inbox".
-
@p @meowski @lain Now I'm thinking, this could improve performance by a little bit if pleroma keeps fetching signed fetch actors even when their enforcement is disabled.
location /objects {
proxy_set_header Signature "";
proxy_pass http://pleromer;
}
-
@mint @lain @meowski Does that override the header or just tack another one on? Duplicate headers are allowed, I'm not sure what nginx does. Try pointing it at something that dumps the incoming headers.
-
@p @meowski @lain Overrides the header, completely removing it if empty.
https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_set_header
pistolero
† top dog :pedomustdie:
All ０７６萌ＳＮＳ content and data are available under the 
