#social 2019-03-07

2019-03-07 UTC
Guest84 and vitalyster joined the channel
#
fr33domlover nightpool, it doesn't have to be a dedicated message, just return a non-200 status on messages you aren't storing and aren't delivering. But yeah, if that isn't done on the Fediverse... it's something worth fixing
xmpp-social joined the channel
#
rialtate[m] fr33domlover: a lot of impl separate accepting and delivering much the same as smtp, requiring a bounce
#
rialtate[m] In ours it even http sigs are verified by work queue
#
fr33domlover Hmm I see
#
fr33domlover Yeah good point
#
JasonRobinson[m] same here, I just dump everything into queue and return 200 :P
#
nightpool[m] fr33domlover: it can't be synchronous because we don't process messages synchronously.
#
nightpool[m] ah sorry I see other people pointed that out already
#
fr33domlover nightpool[m], ah I see, so I guess some kind of reject message could work. nightpool[m], JasonRobinson[m], may I ask why you do the processing asynchronously? Just curious because I'm about to face this decision, how to process, and I'm curious :)
#
fr33domlover I guess one reason is to do the delivery to other servers asynchronously, I'm wondering why the signature checking and DB update happen async too :)
#
cjslep[m] sent a long message: cjslep[m]_2019-03-07_08:59:56.txt <https://matrix.cybre.space/_matrix/media/v1/download/cybre.space/jrDRteccZvNOFBWNsmeJxemF>
#
JasonRobinson[m] > <@irc_fr33domlover:cybre.space> nightpool[m], ah I see, so I guess some kind of reject message could work. nightpool[m], JasonRobinson[m], may I ask why you do the processing asynchronously? Just curious because I'm about to face this decision, how to process, and I'm curious :)
#
JasonRobinson[m] It's nicer to all the senders to end the transaction quickly. If a sender is sending to 1000 domains, it's unfair that each of them does sync processing before returning ok. The whole network scales better if sending is fast.
#
JasonRobinson[m] Also, socialhome does a bunch of things on save like fetching oembeds, prerendering, precalculating streams etc, it would be unacceptable for senders to have to wait all that and would increase timeouts.
#
JasonRobinson[m] I guess as a follow-up comment the scaling issue probably only affects sync senders only. But well, socialhome sends in sync 🙈 Just in many workers.
dmitriz and Guest84_ joined the channel
#
fr33domlover JasonRobinson[m], cjslep[m] I agree reducing response time is nice and maybe even important for the network :) I suppose all the non trivial stuff and followup action can be done async harmlessly
#
fr33domlover But even the very first step, verifying the HTTP sig, may involve an HTTP request, so I guess it makes sense to do it async too
#
JasonRobinson[m] how do people feel about sending back a Reject for the object that was ignored? AP spec at least indicates this is perfectly valid to do, mentioning "Offer" as an example.
#
fr33domlover JasonRobinson[m], I like the idea
timbl, Guest84, epoch_ and Luke_ joined the channel
#
aaronpk i'm up to about 5 minutes of delivering my posts to all my followers. it happens synchronously but still.
#
aaronpk a lot of the servers i'm posting to time out for various reasons or take a long time to acknowledge the post
#
nightpool[m] you're not delivering in parallel?
Guest84 joined the channel
#
aaronpk No, for Reasons
#
aaronpk i need to split this out into its own queue but it was easier to use the same queue everything else uses, and I need some other background work to happen sequentially
timbl joined the channel
#
fr33domlover I started with OCAP-LD. Then looked at macaroons. Then JWT. I think I'll just pick a plain HMAC and later can easily expand to support those standards if needed
timbl joined the channel