#social 2017-05-08
2017-05-08 UTC
dmitriz, dmitriz_ and timbl joined the channel
# 
cwebber moin moin
timbl joined the channel
# cwebber fff
# cwebber oops
# cwebber ssh connection wasn't working, typed some characters, then it came back up and I typed garbage on irc ;p
# cwebber hey aaronpk, I wonder if you could help me?
# cwebber aaronpk: ok, no worries... maybe ping me when you have a sec
# cwebber cool will do, thx
# cwebber :)
# cwebber wow, already
# cwebber 15mins goes fast
# cwebber aaronpk: so I'm trying to put together what I should make sure I support in the AP tests given https://github.com/w3c/activitypub/issues/191
# cwebber aaronpk: feel free to respond when you get time if you aren't here yet :)
# cwebber reading https://aaronparecki.com/oauth-2-simplified/#web-server-apps has lead me back to the question of why the multiple hops to get something from the server, then exchange it again
# cwebber is the purpose of exchanging the the code for a token to do with.. the expiry?
# cwebber or something else?
# cwebber aaronpk: partly I'm wondering if in the tests if you're asking to test the server's client to server side of things whether or not we should just pass in the bearer token directly
# cwebber presumably you're able to get a bearer token directly from your application, and you're really just trying to hand the tests access
# cwebber aaronpk: I see, it's basically to avoid a GET being loggged?
# 
aaronpk with micropub.rocks, I give people two options: https://media.aaronpk.com/Screen-Shot-2017-05-08-14-09-25.png and https://media.aaronpk.com/Screen-Shot-2017-05-08-14-09-40.png
# cwebber right ok
# cwebber ok cool, letting people paste in a token directly is what I've done currently, so
# cwebber I was feeling like I was doing the wrong thing that way
# cwebber but I guess since as you said, the oauth workflows aren't nailed down
# cwebber it's probably the right approach
# cwebber thanks aaronpk :)
# cwebber you helped save a lot of sanity :)
# cwebber cool ok
# cwebber that's one less rabbit hole to traverse while I work on the tests :)
# cwebber thanks again aaronpk !
# JanKusanagi FWIW, from a client/library developer perspective, I appreciate being able to skip looking into new auth flows at the beginning =)
# cwebber heya JanKusanagi
# JanKusanagi and I'd love to skip worrying about that in the first stages of QActivityPub :p
# JanKusanagi less frustrations that way, I think
# cwebber JanKusanagi: I've been thinking about that also while trying to think about what auth flows work
# cwebber and for stuff like QActivityPub, the whole "redirect" style workflows aren't going to work I think
# cwebber since we don't have any way to "redirect" back to the application I think
# cwebber in qt applications on a gnu/linux machine
# cwebber aaronpk: I think JanKusanagi wants to generalize a library so multiple applications can implement it
# cwebber so more of a client library, iirc
# cwebber since Pumpa and Dianara both use QT
# cwebber JanKusanagi can correct me if I'm wrong :)
# aaronpk looks like there's already a QT OAuth 2 client so you should be able to just use that eventually https://github.com/pipacs/o2
# cwebber aaronpk: interesting, I see it does an authorize thing using a browser... I wonder how it sends the info back
# cwebber maybe there *is* a redirect back to the application thing for qt?
# cwebber > In the screenshot above you can see some new URIs and the client_id and the client_secret. There is no need to use the JSON file, you can hardcode this information directly in your application.
# cwebber git commits a client secret straight to the repo
# cwebber oh whoa
# cwebber > Add a URI accessible by your Internet browser including the port if you are using a different one than 80. When the application is running, a basic HTTP server will receive information from the browser.
# cwebber o_O
# cwebber that's one way to do it
# cwebber it would be really nice if there were some standard that instead of doing appname:// had something like
# cwebber app://7d425619c6f94ef6bf6b-d902c498276f/foo/
# cwebber or something
# cwebber where you have an opaque, randomly generated identifier for the applictaion
# cwebber aaronpk: avoiding naming or port collisions
# cwebber closer to capabilities this way
# cwebber aaronpk: what if you're running something with multiple instances of the same application?
# cwebber aaronpk: eg on my desktop I've sometimes run multiple pump.io clients for different users at the same time
# cwebber right
# cwebber the other reason I like it better is I'm a little bit uncomfortable with applications being able to declare their own schemes
# cwebber especially because it's hard to know if you might conflict with something that's an actual protocol
# cwebber worries about name collisions again
# cwebber that's a nicer way to be less likely to collide
# cwebber throw in the process id at the end ;)
# JanKusanagi [8/5/17 23:31] <cwebber> JanKusanagi can correct me if I'm wrong :) ← you are wrong... it's called "Qt" xDD
# JanKusanagi but yes, both Pumpa and Dianara are Qt-based
# JanKusanagi [8/5/17 23:31] <aaronpk> looks like there's already a QT OAuth 2 client so you should be able to just use that eventually https://github.com/pipacs/o2 ← for the record, Qt 5.8 already provided native OAuth1/2
# cwebber JanKusanagi: lol
# aaronpk JanKusanagi: oh interesting. want to make a note of that here? that's where i found o2 https://oauth.net/code/
# cwebber aaronpk: what if you auth multiple things at the same time? :)
# JanKusanagi Choqok is also Qt-based and its main dev is also interested in upgrading to AP, of course =)
# JanKusanagi so QActivityPub would be useful for them too
# JanKusanagi I will aaronpk, thanks!
# JanKusanagi done; I also added the much older QOAuth (which Dianara uses) since I was at it
# JanKusanagi I now realized that list is only for Oauth 2.x, and I think QOAuth only supports 1.x; removing now :D
# JanKusanagi there, much better
# JanKusanagi [8/5/17 23:30] <cwebber> since we don't have any way to "redirect" back to the application I think ← for the record, Pump.io just gives you a token to copy-paste into your client's window; not the prettiest thing, but it works
# JanKusanagi a process you've obviously seen, of course :D
# JanKusanagi what I mean is, why would that not work here?
# JanKusanagi that can work with a desktop client? cool
# JanKusanagi because asking users to copy-paste tokens is not pretty :D
# JanKusanagi ah, nice
# JanKusanagi cwebber (or anyone, really), all I see in the spec is "inbox" and "outbox", and no matches for "major" or "minor" anywhere. Is there a concept of major/minor feeds, or should we just rely on a way to ask the server "send me inbox, filtered like so: ***"?
# cwebber JanKusanagi: it's not mentioned in the spec, you're right.. I've thought about implementing this as an extension. though it could be another collection, I've been thinking a query parameter is simple enough
# cwebber (for those that don't know, in pump.io there's a major and minor feed so you can get *all* the content from the firehose or just the stuff that probably is more important to you)
# JanKusanagi or, more importantly, I think, the ability to have one feed with "comments" and "likes" addressed to you, and a different feed (the 'major' side of the inbox) with the actual posts
# JanKusanagi there's no distinction between "a post" and "a comment" on systems like GNU Social or Mastodon, but still... :p
# JanKusanagi there's still a "conversation/thread starter" there, I guess
# cwebber JanKusanagi: there's also no distinction in ActivityPub now!
# cwebber JanKusanagi: it's just based off the inReplyTo
# cwebber but anything can be a reply.
# JanKusanagi yes, that's where I was going with that :D
# cwebber I think that's pretty valuable TBH
# JanKusanagi re: the query parameter... that could be enough, but how would that query work? ask for "type=note", "type=note|image"? there are many object types that could go in the "major" inbox
# JanKusanagi technically anything can be a reply in Pump.io too
# JanKusanagi Impeller is able to reply with 'note' or 'image' to any post
# cwebber JanKusanagi: I'm not really sure, it's also not well defined in pump.io either what's a major vs a minor :)
# JanKusanagi that's not that well handled by the server though, it has issues :D
# cwebber it's kind of "what pump.io thinks is major" right? :)
# cwebber or is major top-level only posts?
# JanKusanagi hm
# JanKusanagi now that I think about it
# JanKusanagi the disctinction is made at the activity verb level
# JanKusanagi (in part)
# cwebber Create and etc, but not Like and etc?
# JanKusanagi "share" activities are major, even if what you share is a comment (minor)
# cwebber JanKusanagi: that seems right
# JanKusanagi but "post" activities are not major when the posted object is a comment
# cwebber JanKusanagi: that's one reason I shied away from bringing this up in AP's definition
# cwebber it's pretty squishy
# cwebber and I think there are multiple routes to accomodate it as extensions or etc
# cwebber didn't feel like it was critical enough to be in the main spec, esp due to squishiness
# cwebber JanKusanagi: do you think that's the right call?
# JanKusanagi I don't know. You all had to consider many things while creating this specs
# JanKusanagi I'm just looking at them from a Pump.io perspective and thinking how my Pump.io client will manage certain things when it's upgraded to AP :D
# JanKusanagi currently thinking that I don't know if I'll be able to have a "Mentions" feed, an "Actions" feed, a "Meanwhile" etc :D
# JanKusanagi all very useful minor feeds
# JanKusanagi (IMHO)
# cwebber :)
# cwebber JanKusanagi: yeah I agree they're useful
# cwebber JanKusanagi: we have the option of defining more collections
# cwebber JanKusanagi: inbox and outbox were the core concepts though
# JanKusanagi sounds interesting
# cwebber JanKusanagi: there's also the question of how much we want to ask other implementations to implement X many collections too
# cwebber JanKusanagi: of course will an AP client really be general if it expects some of these and only a few servers implement them?
# cwebber tough!
# JanKusanagi after all, pump.io's "inbox/minor" and "inbox/major" could be considered collections built from "inbox", which is also reachable directly
# cwebber yep
# cwebber you could even do the filtering client-side
# cwebber but probably supporting some server-side filtering is better
# JanKusanagi well, I imagine a client that wants to be "AP general" would check for those extra feeds, and not show a pane or a tab for them if they don't exist :D
# cwebber that's true
# JanKusanagi so if Dianara 2.0 connects to a future Mastodon-AP server and there are no minor feeds, it will not create the "Meanwhile" pane, for instance
# cwebber yeah
# cwebber and that's fine!
# cwebber and you can negotiate with the mastodon people to add it :)
# JanKusanagi or in my case, I could continue to call Dianara a "Pump.io client", and not worry about that
# JanKusanagi one could still use it to follow people on GS or Mastodon
# cwebber JanKusanagi: but regardless, if we add those collections we probably want to add them to the activitystreams vocabulary proper as an extension
# JanKusanagi ok
# JanKusanagi if future Pump.io-AP supports those extensions, I'll be happy regardless :D
# JanKusanagi cwebber: btw, you're trying to get https://w3c.github.io/activitypub/#uploading-media out of the "risk" zone, correct?
# cwebber JanKusanagi: yup
# cwebber though I'm also the one that put it at risk :)
# cwebber but yes I'd like it out of at risk
# cwebber by implementation!
# JanKusanagi if I add an empty "QActivityPub::uploadFile()" to QActivityPub, does it count? :D
# JanKusanagi I guess there's not much point in mentioning in the spec anything about the server implementing space quotas or anything, right?
# JanKusanagi because looking at that part made me remember that Pump.io doesn't have such a thing, and a user could upload a 1 GiB video happily
# JanKusanagi maybe a short note about it with a "may" or a "should"?
# JanKusanagi something to think about :D
# cwebber JanKusanagi: hm that's interesting
# cwebber JanKusanagi: Some sort of error code if exceeding that quota?
# JanKusanagi that'd be good
# cwebber pulls up frequently referenced https://en.wikipedia.org/wiki/List_of_HTTP_status_codes page
# JanKusanagi but maybe that doesn't belong in the spec? IDK
# cwebber someone who wanted to edit wikipedia maliciously could really mess with me ;)
# JanKusanagi hehe
# JanKusanagi I've looked that up for several HTTP-error-related messages in Dianara
# JanKusanagi and to some extent, for their translations
# JanKusanagi "507 Insufficient Storage (WebDAV; RFC 4918)" is almost right :D
# cwebber 507 Insufficient Storage or 413 Payload Too Large perhaps
# cwebber probably 507?
# JanKusanagi returning "418 I'm a teapot (RFC 2324)" would be cooooool =)
# JanKusanagi 413 sounds maybe better than 507?
# JanKusanagi 507 suggests the server can't handle more, not "you're not allowed more", but either way, sounds good enough
# JanKusanagi thanks ajordan :D
# JanKusanagi why did I win the points? :D
# cwebber JanKusanagi: both sound slightly incorrect :)
# cwebber but yeah
# cwebber 413++
# cwebber teapot++
# JanKusanagi I'm a teapot is a great HTTP reply
# cwebber karma++
# JanKusanagi the best, probably
# cwebber JanKusanagi: :)