#social 2017-08-10

2017-08-10 UTC
xmpp-social, jungkees and jankusanagi_ joined the channel
#
puckipedia let's fix up the changes and publish the accept/reject thingies
#
puckipedia there's not even any code that's specially ran when rejecting :D:
timbl and xmpp-social joined the channel
#
Gargron puckipedia: just merged the accept/reject stuff into master
#
Gargron just need to finish my other PR by writing the code for distributing Delete activities
#
puckipedia hm, nice
#
puckipedia I should probably build a thing where fragment IDs that can't be resolved should be passed when federating
#
Loqi yea
#
puckipedia now I wonder who I should verify that
#
puckipedia how*
#
Gargron puckipedia: the big question is, have you already tried interacting with master-masto using your AP implementation?
#
puckipedia nope
#
puckipedia gonna try now I think
#
puckipedia I have a really wonky mastodon setup
#
puckipedia using WSL
eugr and timbl joined the channel
#
eugr cwebber2: is there some sort of support for batching inbox POSTs, i.e. multiple activities in the payload? thinking of cases like mass-deletes
#
cwebber2 eugr: nope, though maybe HTTP 2 would be useful for that
#
eugr couldn't i just post a primitive array of activities?
#
eugr oh well
#
cwebber2 eugr: It's a reasonable suggestion but I think it would have to be an extension... I think it's too big of a feature to get in within the time we have and safely test it
#
xmpp-social [ajordan] I don't think you really need HTTP/2, just Connection: Keep-Alive?
#
cwebber2 it would add some other complexities, such as how do you report if one submission succeeded and some otehrs failed
#
cwebber2 would require a more complicated response type than we have right now
#
eugr even without http re-connection overhead you might lose some benefits of batched processing if you still have to reset the request-response cycle in the application
#
cwebber2 is it really so common, except when someone trashes their account?
#
cwebber2 and mass creates are probably undesirable for other reasons
#
eugr i can only think of mass deletes right now
#
xmpp-social [ajordan] eugr: yeah you're right, I forgot you had to wait for a response. HTTP/2 then?
#
cwebber2 I mean, the application might still have the state that it sets up / tears down in the application
#
cwebber2 sessions need to be checked, etc
#
cwebber2 but I think batching introduces maybe more complexity than it fixes at present
#
cwebber2 at the very least, it introduces a lot of questions that would need to be explored
#
eugr i dont reeeeeeally see why, if the actor is the same
#
eugr but shrug
#
cwebber2 eugr: well I gave two concerns at least right now:
#
cwebber2 1) how do you handle a response for some succeeding and some failing
#
xmpp-social [ajordan] cwebber2: you can optimize your HTTP/2 stack to have a delay for tearing down that data then
#
eugr ok, true
#
eugr WebSub can deliver an arbitrary number of entries in a single payload and they didn't care about that
#
cwebber2 2) mass creates/likes/etc would also need to be rate-limited; not all applications might really be set up to be able to handle that many actions at once
#
cwebber2 hm
#
cwebber2 eugr: want to write up a suggestion on how it works on the wiki or etc?
#
eugr maybe
#
cwebber2 (are you part of the CG? I'm not sure I recognize your username)
#
eugr ...i'm gargron
#
xmpp-social [ajordan] Lol
#
cwebber2 ha
#
cwebber2 I didn't notice that username
#
eugr i am trying to finish BatchedRemoveStatusService right now
#
cwebber2 eugr: anyway, I mean I'd be down for exploring this
#
cwebber2 I'm just nervous about adding new complicated things this late in the game
#
cwebber2 eugr: want to file an issue making your case for it at least?
#
eugr idk if it's worth it tbh. we'll see once it's live in action, tho i'm worried about how we're actually gonna measure this stuff
#
eugr man, i really hate BatchedRemoveStatusService. it's that case when you optimize something so much it becomes soooo hard to change
#
cwebber2 yeah that happens sometimes