#social 2017-08-09
2017-08-09 UTC
xmpp-social, tcit, timbl and JanKusanagi joined the channel
# 
Gargron cwebber2: has the follow/accept dynamic already been formalized?
# Gargron ah i don't need you to rush anything but i'm at the stage where i should code this behaviour
# Gargron i suppose there's gonna be a UX regression though - the follow from the user will always show up as "pending" in the API response, since even the auto-accept would come in asynchronously :thinking:
# puckipedia I have a (WIP-ish, under a flag) implementatino for accept/reject follow
# puckipedia I was gone for previous week because of SHA2017
# Gargron puckipedia: if you got your local mastodon you can now try sending it stuff to the inbox
# Gargron err, well, with this branch anyway https://github.com/tootsuite/mastodon/pull/4565
# Gargron because otherwise only the acct: keyId is supported
# Gargron also the Digest header is verified but not mandatory and currently im thinking if maybe it should be mandatory
# Gargron when there's a request body
# puckipedia I'd say mandatory for non-public requests
# puckipedia and for all inbox POSTs
# Gargron have you already implemented it?
# puckipedia wait woops
# puckipedia I assumed just general authorization
# puckipedia I don't do Digest: yet
# Gargron hm. is your response different to that then?
# Gargron i mean i dunno. http sigs might be secure even without payload digest
# puckipedia hm, I would say don't require it
# puckipedia like, you're taking a risk by not passing the digest header
# puckipedia also some systems might not support calculating the digest in the proper way
# Gargron in any case - do try out my inbox code
# Gargron * o *
# Gargron but yeah i dunno what to do about follows UX. i feel like from the user's perspective it should be low friction as possible. so maybe i'll keep current behaviour - simulate instant-follow if the :_locked attribute is false, then asynchronously re-check the :_locked attribute and erase the follow and re-do it as a follow-request if the value is suddenly true
# puckipedia _:locked I guess? :P
# Gargron oh yeah
# puckipedia (also technically for json-ld, "_:locked" and "locked" are equal)
# Gargron well i'm just doing what you did with _:conversation
# puckipedia I really just did that because I expected _:conversation to never be a part of the spec
# puckipedia (I did think about how to implement this; and how about:)
# puckipedia
{type: Note, tag: ["https://example.com/conversation"], content: "hello"}# puckipedia
{type: Conversation, object: https://example.com/initial_post, posts: [possible collection of all posts in this conversation?]}# Gargron conversation isn't an object in AS tho, i'm really not sure. i mean this might be the way forward if conversation becomes an official object, but we in ostatus land have to deal with that problem where old URIs are all tag: ones
# Gargron ensuring that ostatus/activitypub content does not get duplicated because of differing URIs is still giving me a lot of worries
# puckipedia you could use a "transition OStatus ID" property
# puckipedia like, a _:atomId property if the ostatus URI doesn't equal the activitypub one
# Gargron yep but it's still a matter of remembering where to put it and remembering where to check it ;;;
# Gargron i'll start working on that last imo
# puckipedia probably
# puckipedia like, old IDs will stay working forever I guess? I mean, it has to interoperate with GNU social
timbl joined the channel