#social 2017-07-30
2017-07-30 UTC
xmpp-social joined the channel
# 
puckipedia hm. I think I'll accept "invalid" Accept/Reject on Follows
# saranix what makes it invalid?
# puckipedia well, there's a few situations
# puckipedia like
{type: Accept, actor: userA, object: {type: Follow, object: userB}}# puckipedia (userA accepting a follow for userB)
# puckipedia I consider those invalid
# puckipedia hm, this is getting interesting
# puckipedia I think I'll accept them and assume signatures do the job
# saranix yeah all objs have to be validated regardless
# saranix let validation fail
# puckipedia yep
# puckipedia except I will just refuse the above situation
# saranix I'm trying to decide whether to implement my client UI as an activity stream or a doc stream. I've done doc stream in the past, but I can't figure out what to do with all of the activity objects (UI-wise) if I do that with AP
# puckipedia hm, what would doc stream look like?
# saranix looks ugly no matter how I picture it
# saranix trying to tack on activities that is
# puckipedia I mean, I don't have any reference for doc stream
# puckipedia like, would that just be a stream of e.g. Notes?
# saranix in many cases yeah
# saranix it's more fun when it's all different types
# puckipedia ah, right
# saranix it's more of a UI gimmick than anything else
# puckipedia so emh, what you could do, is kinda split it up? Like, have two columns/pages, one for all notes and one for all follows/delete/etc
# saranix oh yeah I forgot about negative actions
# saranix hmm... I think I'm trying to be too fancy
# saranix I'm really just procrastinating finishing my parsers :-P
# puckipedia I'm working on building a test implementation for Accept/Reject of Follows
# puckipedia ehm, how long should a Follow request be valid for?
# saranix forever
# puckipedia well, I need to implement a thing that you can only 'redeem' a follow request once, I think
# puckipedia so one Follow can only be Accepted once
# saranix check for an existing Accept/Reject action?
# puckipedia that's my plan :)
# puckipedia I got a bit of code already for that
# puckipedia (needed for OStatus support)
# saranix What about changing an accept to a reject?
# saranix or vice versa
# puckipedia I don't need to check for that
# puckipedia I guess?
# saranix probably Undo Accept is more semantic... I think that's what we decided on before
# puckipedia
{type: Undo, object: {type: Accept, object: {type: Follow}}}# puckipedia lol
# saranix parse that!
# saranix :-P
# saranix this protocol is a bit rediculous at times
# puckipedia I think Reject follow is good enough?
# saranix thing is, people can theoretically spin it 100 different ways and they're all "valid" according to the really loose spec
# saranix be conservative in what you send and liberal in what you accept
# puckipedia well, you can also Reject a Follow before it's Accepted
# puckipedia anyways, bbiab
# saranix [
{type:Undo, object: {type: Reject, object: followid}}, {type:Accept, object: followid } ]timbl joined the channel
# 
ben_thatmustbeme wonder how systems would handle an undo of an undo of an undo of an ...
# puckipedia ben_thatmustbeme: once undone, you can't un-undo
# puckipedia You'd just repeat the original activity
# ben_thatmustbeme Well, that's what you are supposed to do
# saranix what if... userA's software sends [
{type:Undo, object: {type: Reject, object: followid}}, {type:Accept,object: followid } ], but userB's software does not accept the Accept, that is, it is no longer interested in following because of the Reject it already got# saranix haha
# puckipedia saranix: so, implicitly, the reject already happened
# puckipedia you can't undo a reject and then accept it
# puckipedia because the Follow has already been 'redeemed', so to say
# saranix but some software might decide you can
# saranix it's ambiguous
# saranix both behaviors are valid
# puckipedia actually I think this is actually in the spec
# puckipedia > There are some exceptions where there is an existing and explicit "inverse activity" which should be used instead. Create based activities should instead use Delete, and Add activities should use Remove.
# saranix but that doesn't really apply because there is no Unfollow
# puckipedia it's follow/undo follow
# puckipedia and [accept/reject] follow
# saranix still doesn't disallow what I said above
# saranix and I'm pretty sure that there's still quite a bit of disagreement over this issue amongst the group
# saranix with most disagreements ending in "we'll just do whatever mastodon wants" :-/