#social 2019-03-21
2019-03-21 UTC
# 
fr33domlover Hey people
# fr33domlover Suppose there's an object about which you have a conversation using Note objects
# fr33domlover Say, comments on a software issue/bug
# nightpool[m] sure
# fr33domlover Notes that aren't a reply to another note, how would you specify on which issue/bug they comment? inReplyTo, context, other property?
# nightpool[m] i would say they're inReplyTo whatever you would consider the "root" object, whether that's a commit or a pull request or whatever
# fr33domlover I wonder if using inReplyTo would cause trouble because it usually points from a Note to its parent
# jdormit[m] I've found it helpful to think about how other federated systems would treat your content for decisions like this
# fr33domlover nightpool[m], hmmm and what if in a Note that is a reply to another, I additionally want to specify the issue URI
# nightpool[m] that would be `context`
# nightpool[m] in the same way that the root "conversation" is the context in a threaded post system.
# jdormit[m] e.g. in Mastodon, if the commit/issue/PR/whatever is an object in someone's timeline, I would expect that clicking through to the thread for that issue would show me comments on the issue (in Mastodon)
# fr33domlover jdormit[m], it's useful but often hard for me to find! Digging in Mastodon and Pleroma source code etc.
# jdormit[m] So comments on the issue would have to be inReplyTo for that to happen
# nightpool[m] i think jdormit means more how you would want them to treat it
# jdormit[m] yeah exactly
# fr33domlover jdormit[m], well, it could as well be 'context' instead. jdormit[m], nightpool[m], how about the following: All Notes have both context and inReplyTo; when a Note's context and inReply to are the same, then it's a top-level Note directly commenting on the context object (issue/MR/whatever)
# nightpool[m] yeah i mean that sounds like what i would expect
# fr33domlover :)
# nightpool[m] (although nota bene that in the actual version of the world, mastodon doesn't use context for displaying the thread, it just resolves inReplyTo recursively)
# jdormit[m] ^ that is what I meant above
# jdormit[m] So for blocks, I think it is sufficient to just drop incoming activities from a blocked actor without persisting or forwarding them
# fr33domlover nightpool[m], jdormit[m], that's totally okay: My software will use the context for its own grouping purposes, and Mastodon can handle plain Note trees not caring about context, just using inReplyTo
# jdormit[m] Say Alice blocks Bob, and both of them follow Carlos
# jdormit[m] Alice posts something, and Carlos replies
# jdormit[m] Then Bob replies to Carlos's reply
# jdormit[m] So Bob's activity goes to Carlos's inbox and Alice's inbox
# jdormit[m] If alice's server just ignores Bob's reply, then her server won't forward it to her followers, so only followers of hers who also follow Bob will see it
# jdormit[m] But carlos and all of his followers will see Bob's message
# jdormit[m] But I think all of that is probably fine? That way Alice never sees any messages from Bob no matter what, and neither do her followers unless they explicitly follow Bob
# jdormit[m] The question is, what happens if someone who Alice follows responds to Bob's post, and that gets sent to Alice's inbox? Then from her inbox's point of view it will look like an activity that is inReplyTo an object that doesn't exist
# jdormit[m] I feel like the whole Block thing is really underspecified...
# fr33domlover jdormit[m], note that blocking is probably a weird case anyway, it's socially complicated (both on the internet and AFK) to really ignore someone. You'll see weird comment trees in which stuff is missing, you'll see Notes quoting lines the blocked person wrote etc....
# jdormit[m] Yeah, I never even implemented it in pterotype v1, but I feel like if i'm claiming to make an activitypub library I should probably handle it...
timbl joined the channel
# fr33domlover jdormit[m], iirc Mastodon supports muting/ignoring people? I wonder how it does it, and do people like the way it does it
# jdormit[m] I'm more worried right now about introducing bugs where something expects an activity to exist in the local database but its not there because it was blocked
timbl joined the channel
# jdormit[m] that'd be a good tree to bark up. I have briefly looked at the mastodon source but not in any sort of depth...
# fr33domlover jdormit[m], what if you store the activity anyway, just hiding it when Alice observes the conversation, and showing it to everyone else
# fr33domlover jdormit[m], like, don't put it in her inbox but do store it
# jdormit[m] yeah I think that's what I'm going to do
# jdormit[m] I'm like 65% certain that's what Mastodon does too
# jdormit[m] Yup, mastodon just filters out posts from blocked actors in the timeline: https://github.com/tootsuite/mastodon/blob/bcfff65195f557dc086470f91b4c90b15c004cf7/app/lib/feed_manager.rb#L155
# nightpool[m] jdormit: that class of bug you mentioned sounds unlikely, considering that anything that would expect the post to exist in the local database could also be confused by like, network conditions selectively messing up delivery
# nightpool[m] mastodon user blocks are handled when preparing the post to be viewed by the user, yes
# nightpool[m] if someone from server a blocks someone from server b, and they send a message tagging me to servers a and c, the fact that bystanders on server c and server a would see the post differently based on MY block is pretty weird and unexpected
# jdormit[m] yeah that makes sense
# jdormit[m] also point taken about network conditions, I guess there's never any guarantee you'll be able to get a local copy of an activity unless you are currently handling it
Guest84_, xmpp-social and decentral1se joined the channel
# cjslep[m] Also, the receiving instance can still change the public view of its representation of a thread containing blocks. Example: For my personal website, Blocks will prevent my website from displaying the blocked user or blocked instance's users' comments below the blog post Articles.
dmitriz, timbl, englishm, decentral1se, tantek, heimdal, _xmpp-social and gobengo-irc-bot joined the channel