#social 2017-09-01
2017-09-01 UTC
timbl, xmpp-social, JanKusanagi and jankusanagi_ joined the channel
# 
Gargron cwebber2: how's the context doc lookin'?
# Gargron tuesday :O
# Gargron i mean, so i can't tag a RC until tuesday
# Gargron i kinda wanted to do it asap already
# Gargron unless i manually edit my cache of the context document to include what i want
# Gargron if you give me a pointer of what its going to look like
# 
ben_thatmustbeme i don't believe context docs require any sort of schedule to publish
# ben_thatmustbeme as i remember
# Gargron \o/
# 
cwebber2 maybe I shouldn't be engaging but I'm lost https://octodon.social/@cwebber/6081775 https://octodon.social/@cwebber/6091483
jankusanagi_ joined the channel
# saranix he makes perfect sense if you think of him as an NPC in a MUD
eugr joined the channel
# eugr cwebber2: take a look, i compiled a list: https://github.com/tootsuite/mastodon/pull/4764
# xmpp-social [ajordan] > And I intend to break the rules so that the walls come down. Deal with it.
# xmpp-social [ajordan] So dramatic. Wow
# cwebber2 eugr: btw the one concern I have is those "blank node properties" is 1) in the bulleted list on https://github.com/w3c-dvcg/ld-signatures/issues/9
# eugr cwebber2: https://hastebin.com/iwivetosot.json
# eugr maybe we could put atomUri and inReplyToAtomUri into some kinda ostatus namespace
# eugr ostatus:atomUri
# eugr i just dunno about putting these potentially valuable properties into a willy nilly context?
# eugr no
# eugr no, ostatus has nothing to do with json
# eugr if i make it toot:locked then every AP implementation will have to adopt the silly "toot" context henceforth
# eugr that's a big responsibility
# eugr you know i think i wanna push for "locked" (or a synonym) to be put into AP. it's just so on its own. i can't make up an "extended profile" extension with one single property
# eugr given Accept/Reject is in, surely it would be useful to convey the information of "auto-accept"?
# eugr call it autoAccept, i wouldn't mind
# eugr i'm willing to do stuff with atomUri because i think those are throw-away properties that will go away after we remove ostatus support in the eventual future
# eugr but locked is more core i feel
# eugr essentially if you are rendering an actor, "locked" would control whether you're displaying a lock icon on the profile or not
# eugr if you can think of a better way to serialize such information, i'm ears
# eugr just one thing really, the accept/reject thing.
# eugr visibility defaulting is more granular in our system
# eugr i'm sorry i realize this is a headache. i am open to alternative suggestions. but i feel quite strongly that not being able to encode this info at all would be a UX regression
# eugr json-ld contexts are all called very important things like "identity", "security", "activitystreams". i cannot imagine what a context encompassing just one property that depends so heavily on AP behaviour (Accept/Reject) would be called
# eugr i am well aware that atomUri and inReplyToAtomUri are thematically different and also, as i said, throw-away
# cwebber2 if you did "as:locked": true it would still render as https://www.w3.org/ns/activitystreams#locked
# eugr if i use it as toot:locked now and it eventually becomes AP after all, would that break signatures between masto releases?
# cwebber2 it would "expand" to https://json-ld.org/playground/
# eugr the expanded thing gets signed tho. so if the expansion is different between masto versions, signature verification will fail
# eugr it's from the LDS github issue. our rule of thumb "don't use a property until it's defined in the context"
# eugr ok what's the worst thing if i manually, explicitly define locked as AS on my own inside @context?
# eugr because i think if i do that, and locked does become part of AS, there will be no signature mismatch
# eugr sorry can you help me with the syntax for that again? so i want the definition inside @context and just "locked" in the json itself
# eugr righto
# eugr that's good, but ideally json handlers wouldn't need to think about "as:locked" vs "locked" vs "blahblah:locked" so i'd prefer the @context version
# eugr so that it's just "locked"
# eugr i was asking for the syntax for that
# eugr aight thank you
# eugr i will do that for "locked" and for "sensitive", then i won't need to wait for tuesday
# eugr (btw yes the AS context was updated with sharedInbox but not sensitive)
# eugr (oh yes also Hashtag is missing, do i need to define it that way too?)
# eugr yep i agree
# eugr the other contexts also do this
# eugr identity/v1 etc
timbl joined the channel
# eugr aight, now just to sort out atomUri and inReplyToAtomUri.
# eugr would i do
{ "atomUri": "ostatus:atomUri" }? what else do i need?# eugr funnily enough i am against putting atomUri etc into AP/AS. bridging ostatus posts has been the only actual nightmarish headache with this whole endeavour. i've kept my sanity by 1) accepting that ostatus posts will not be fully AP-conforming 2) ostatus support will go away eventually and ostatus posts will fade away so the problem will disappear by itself
# eugr cwebber2: i just created a w3 account
# eugr can't login to the wiki tho
# eugr cwebber2: https://hastebin.com/maqaqagafa.scala good?
# eugr cwebber2: also how's this for the ostatus definition: https://hastebin.com/uperawajeg.php
# eugr a bit of boilerplate in each payload but at least it'll work quickly eh
# eugr cwebber2: well, ostatus as a spec is dead, isn't it
# eugr nobody is actively developing it
# eugr so i might as well?
timbl joined the channel
# eugr cwebber2: https://github.com/tootsuite/mastodon/pull/4767 :V