#social 2017-08-25
2017-08-25 UTC
# 
xmpp-social [ajordan] cwebber2: as in type vs standard prop name?
# xmpp-social [ajordan] I thought Actor as a type got dropped
# xmpp-social [ajordan] :P
# Gargron why would they collide if the casing is different?
# Gargron variable names/class names/type names are not case insensitive as a rule, in programming languages
# xmpp-social [ajordan] cwebber2: are fragments case-sensitive?
# xmpp-social [ajordan] I mean I guess duh, I just never thought of that lol
# xmpp-social [ajordan] cwebber2: what do you mean they don't have to be? Either the HTML spec says they are or it says they aren't?
# xmpp-social [ajordan] Or it says "whatever we'll punt to implementations"
xmpp-social joined the channel
# 
cwebber2 PDF edition if you prefer https://gitlab.com/dustyweb/talks/raw/master/activitypub/rwot/even_more_distributed_activitypub.pdf
# Gargron cwebber2: https://github.com/tootsuite/mastodon/pull/4687
# Gargron of course, once again mapping to storage is tricky since we're not using document storage. our signatures will probably be generated on the fly, and if we need to forward payloads, we will forward them immediately rather than storing the signatures somewhere
# Gargron btw i think there might be an issue where https://www.w3.org/ns/activitystreams does not return the actual json-ld document even with the right Accept headers, unless you use https://www.w3.org/ns/activitystreams.jsonld instead
# Gargron not me, the ruby json-ld gem
# 
rhiaro curl -H"Accept: application/ld+json" https://www.w3.org/ns/activitystreams gave me JSON-LD
# Gargron hmm, okay. then some problem with the gem.
# Gargron in any case i am intending to use json-ld-preloaded (which also has a bug i already reported and was promised to be fixed today)
# Gargron basically i don't want my code to fire up any http requests while parsing json, because that's unpredictable and slow and i'd rather not
# Gargron json-ld-preloaded has all of the popular contexts cached
# Gargron cwebber2: yes i read your paper
# Gargron i almost finished implementing both verifying and signing with LDS
# dlongley Gargron: see? :)
# Gargron nice
# dlongley mostly just lurk in here though.
# xmpp-social [ajordan] cwebber2: am I missing some standard internet joke? I've no idea what botsnack is
# xmpp-social [ajordan] Side note I love how indignant you are lol
# xmpp-social [ajordan] Ahhhh
# xmpp-social [ajordan] pumabot also doesn't know that
# xmpp-social [ajordan] I souls teach them
# xmpp-social [ajordan] s/souls/should/
# Gargron you can probably just define a text response?
# Gargron its not a complicated function, its keyword -> static response
# puckipedia oh no I'm gonna have to implement LD signatures now :<
# Gargron you don't have to
# Gargron they have a limited use case
# Gargron use case 1) once you receive a reply to one of your posts, forward it to all your followers
# Gargron use case 2) if you receive a delete for a remote post, and you have reblogged that post, forward the delete to all your followers
# puckipedia hm. though you do sign the entire document
# Gargron oh sure, but you can just ignore that?
# Gargron its just an extra signature property.
# puckipedia eh. I think if we do proper JSON-LD signatures we'll probably have to figure out a consistent way of signing
# Gargron its in the spec
# Gargron it's pretty definite actually
# Gargron but again, the primary authentication is still with http sigs
# puckipedia I don't think LD signatures are in the spec already?
# Gargron you can ignore LDS for most purposes
# Gargron they dont have to be in the spec
# Gargron they are json-ld, and AP is json-ld
# Gargron you add an extra @context, and a signature property
# puckipedia well then we have to determine how flattening should work
# puckipedia I mean. generating LD signatures for an object
{type: Create, object: {type: Note, content: Hello}}# puckipedia is different than generating LD signatures for
{type: Create, object: objectId} and {type: Note, id: objectId, content: Hello}# puckipedia there's pros and cons to both of these approaches
# puckipedia e.g. the pro to signing the entire document is that you sign that you created *that* content at that point in time
# puckipedia con: you have to keep previous versions of the object, and you have to restore the objects into the exact same document
# Gargron signature goes on the entire json document, not any subset
# Gargron afaik.
# puckipedia it does. though with JSON-LD api you can easily split up the documents into its constituent objects
# cwebber2 - probably not gonna be done by Masto, but seems like the Best Design from a structual standpoint: when you store an object, actually store a "revision" of that object and do content addressed hashing of that object. Then when you're storing the object you can pull up an old revision, with that version of its signature, even if your reference to it mutated. Unfortunately unlikely to work nicely with a design like Masto's relational
# puckipedia hm. I could try storing revisions once I move to a tuple database
# cwebber2 puckipedia: did you read https://github.com/w3c-dvcg/ld-signatures/issues/7 ?
# puckipedia Salmon just signs the entire object as it is passed through, right?
# puckipedia though you still can't pass it on because of the way the attribution works
# puckipedia ehm, audience*
# puckipedia bbiab
ben_thatmustbeme and wilkie joined the channel
# cwebber2 I updated the paper to clarify decentralized / distributed terminology and add a bit about great being the enemy of good and pointing towards incremental improvement https://gitlab.com/dustyweb/talks/blob/master/activitypub/rwot/even_more_distributed_activitypub.org https://gitlab.com/dustyweb/talks/raw/master/activitypub/rwot/even_more_distributed_activitypub.pdf
timbl joined the channel