#social 2017-10-30
2017-10-30 UTC
rowan joined the channel
# 
nightpool cwebber2: just like, to close the loop on #256: I'm really not trying to be an asshole about content-types or anything it just feels really weird that AP explicitly contradicts AS2 here.
# nightpool and I know that I'm approaching this from the pure-json perspective and nearly everyone else is in the LD camp and that's always going to cause conflict and I'm sorry about that, for what its worth.
# nightpool in the interest of getting to CR, yes.
# nightpool From the broad scope I think that making things "easiest" for pure-json implementations is always going to be the right way to err--from a real-life performance perspective, from a adoptability perspective and viral adoption, barrier to entry: all of these things weigh themselves in favor of catering more to pure-json folks
# nightpool because when you're thinking about partial implementations for existing systems, small projects built by enthusiasts, large existing projects adding some AP functionality (cf. twitch), all of that stuff is going to be easier if you don't have to think about LD stuff.
# 
cwebber2 the reason the content-type/accept header ended up the way it was is because we were already interop'ing with existing linked data systems which could support what we were doing at almost no extra effort by using the ld+json mimetype... that ended up being a convincing argument so it became the default. was it right? I dunno
# nightpool and like, the content type is a small part of that, and useful to think about symbolically--but it's also a non-negliable part of that, in that getting profile attributes to work right in ""normal"" frameworks is basically a non-starter.
# nightpool mastodon throws the profile attribute away, for example, and will just assume that if you're sending it ld+json it's ld+json; profile="https://www.w3.org/ns/activitystreams"
# nightpool because rails has no way of parsing or exposing that profile to us and patching it is way beyond the maintenance burden we want to take on at this point.
# nightpool yeah LGTM
JanKusanagi, cdchapman, xmpp-social, jankusanagi_, timbl and rowan joined the channel
# 
csarven Unless I misunderstood as:proxyUrl's definition, it is not quite what I need ( https://github.com/linkeddata/dokieli/issues/230 )
# csarven https://github.com/solid/vocab/issues/26 explains what I need.
# puckipedia csarven: right, so the way the AP proxyUrl works is a POST with application/x-www-urlencoded value id=asdf, not basically a prefix
rowan joined the channel
# puckipedia I threw the ORM out of the window
# puckipedia 100% hand-crafted SQL statements
aaronpk, timbl and rowan joined the channel
# Gargron hey the PeerTube developer has told me they're interested in ActivityPub, i invited them here
bengo joined the channel
# puckipedia yep I have a bunch of SQL commands now
# puckipedia down to about 160ms for GETting one object. which isn't amazing, but it's better than 3 whole seconds
JanKusanagi joined the channel
# puckipedia woop
# puckipedia I'm trying to fix up CollectionTools so I can do stuff again with Kroeg
# puckipedia once that works I'll merge the entier PR into master branch (aka wooo, quad store!)
# puckipedia though I am not very good at SQL queries and am hitting an issue
# puckipedia so if I have a SQL table e.g. main_table (id int primary key, name text) and another table sub_table (id int primary key, main_id int references main_table(id), other_value int, other_other_value int)
# puckipedia and I want all entries in main_table that have an entry (4, 5) and (7, 8) in sub_table
rowan joined the channel
# puckipedia the giant query works. who cares, push it
# puckipedia cwebber2: I just merged the giant triple store PR as I need some active testing
# puckipedia oh wow I got this to be Fast(TM)
# puckipedia an outbox containing one (1) public object and one (1) private object
# puckipedia Request finished in 93.6208ms 200 application/ld+json; profile="https://www.w3.org/ns/activitystreams"
# puckipedia ... /creating/ an object is 1.2 seconds. this is speed
# puckipedia so. I try to get the v1.8 activitystreams context. this has a header Vary: negotiate,origin -- but also a Cache-Control: max-age=31536000, public
# puckipedia and an access-control-allow-origin equal to the origin
# puckipedia ... so now only the first origin that loaded this context can use it
# puckipedia thanks, internet
# puckipedia release build, debugger attached: 1164ms. debug build: no debugger: 30ms
# puckipedia suddenly remembers "don't profile on a debug build"
# puckipedia though tbh this is "don't profile with attached debugger"
rowan and timbl joined the channel