#GWGI did, yes. But, my question was more...people who have it set up, how often do they use it.
#GWGI added the javascript protocol handler shown off at IWC UK last year. So, that is working. I just need to add a few more features for it to work properly.
#kylewmGWG: I use webaction endpoints multiple times a day
#kylewmvoxpelli's javascript magic, I've only gotten to use a couple of times for testing
#GWGkylewm: Any tips? I did see your indie-config page.
#GWGkylewm: I bolted it on already. I've moved on to improving the actions themselves.
snarfed, emmak, KartikPrabhu, wolftune, kylewm_, j12t and lukebrooker joined the channel
#aaronpkokay well 28 mentions of this post (since I didn't POSSE it anywhere myself) is now motivating me to improve the display of non-comment mentions
#ben_thatmustbemehmm, folowing a discussion on w3c about heade fields like to, cc, bcc, bto. If we do start indiemessaging, how do we specify who we are sending to?
#rhiaroben_thatmustbeme: also note that possible conflation of tags and mentions just now (maybe it's fine, I don't have enough brain to devote to working that out right now)
#ben_thatmustbemepresentation wise I wouldn't want everything to be a note with a metion of the person in there, and person-tags could work but would seem to obfuscate things
#snarfedben_thatmustbeme: u-in-reply-to right? if it's a new msg, maybe set it to their home page
#snarfeddisplay: none it if you don't want it visible
#rhiaro^ where by ben_thatmustbeme I mean your homepage
#ben_thatmustbemethe only issue that once i post my reply-to /2015/04/msg4ben I need to remember that that post is a direct message and any reply-to that would be rendered as a direct message
#rhiarobut I probably wouldn't want direct messages to people showing up in my main/homepage feed, and filtering them out by parsing the url they're in-reply-to seems a bit heavy
#rhiaroit depends if the direct message is meant to be public or private
#ben_thatmustbemewhere as dropping the threading you can say that all messages from a specific person on in precisely one thread
#rhiaroin my head everything I post on my site is public at the moment, because not is too hard right now
#ben_thatmustbemeahh, true, with public its rather important to keep the thread
#rhiaroand I'm a fan of threading, and I can still collect all messages in-reply-to a particular person in one place, and keep threading
#Loqiindieweb-messaging is a suggested protocol for combining microformats2, WebMention, and IndieAuth to convey private posts between two people or between groups of people https://indiewebcamp.com/indieweb-messaging
#ben_thatmustbemeactually the simplest way might be i create a post that either mentions, tags, or in-reply-to rhiaro's homepage (undecided on this yet)
#ben_thatmustbemehere is another issue, A wants to add to that message thread with a second message (not uncommon to do)
#ben_thatmustbemeif A does in-reply-to B.com its seen as a new message, if it is in-reply-to A1, B doesn't get a webmention
#ben_thatmustbemeas far as B13 not having a reference to A12, i wonder if thats not more of just a UI issue. B.com knows that B13 is part of a direct messaging thread and can show the entire thread in the context
#ben_thatmustbemeI almost wonder if its better if the original message can have people "subscribe" to it
#ben_thatmustbemei like the idea of u-in-reply-to an h-feed. that would certainly work for messaging and chats... can subscribe to the h-feed by any reader that way
#tantekben_thatmustbeme: rather than thinking about it as "first", instead, use <body> for the "type" of page, e.g. <body class="h-card"> or <body class="h-entry"> etc.
#fkoomanaaronpk, the only issue is that the introspection also expects a form post, just like exchanging the code for the access_token
#aaronpkfkooman: those requests will contain a lot of parameters, none of which are called "token", so the endpoint would still be able to determine if a request is an introspection request vs a grant request
#fkoomanaaronpk, ah, i guess that was added in later drafts
#ben_thatmustbemerhiaro: aaronpk: it works for me "sometimes" to redirect to the page i was on
#fkoomanaaronpk, but it will be a bit tricky for e.g. the micropub endpoint to get credentials to verify the token... you need to manually do that or something
#ben_thatmustbemeaaronpk: rhiaro: ahh, interesting, if I'm on https:// on the wiki before login it stays on the page... if i'm on http:// it goes back to home page on login.... losing some post values in an http -> https redirect i'm guessing
#aaronpkalso i think that spec says client authentication is optional
#cweiskebut are ruby and python fine with &hub.url=&hub.url=&... ?
#aaronpkeven if they are, the fact that PHP can't understand it is kind of a dealbreaker, since that means any code written in PHP is going to have to use a custom query string parsing library instead of relying on $_POST, at which point you might as well just use JSON input
#aaronpkfkooman: ok yeah, it says the endpoint must require some sort of authorization from the client, but it doesn't specify that it has to be client id+secret
#fkoomanaaronpk, true, but i guess at least some kind of shared secret with the server or something
#kylewmcweiske: python is fine with hub.url=&hub.url=&...
#voxpellihub.url=&hub.url= is an anti-pattern imho
#aaronpkhm, are you intending on using this to allow clients to check tokens, or for your micropub endpoint to check tokens?
#voxpellior rather – there has been concerns about the possibility for query params to be both strings and arrays because getting an array when you expect a string can cause exceptions
#fkoomanso only for protected resources that need to verify the access tokens that the client send it
#aaronpkfkooman: for the micropub endpoint, i think it wouldn't be unreasonable to require people first sign up at tokens.indieauth.com to be able to use it, at which point a shared secret can be established (basically an API key)
#voxpelliKevinMarks_: true, no anti-pattern in the query params themselves – but even some new parser are handling it very shitty, making it possible to more or less crash them on demand by providing multiple values when they only expected a single one
#fkoomanaaronpk, a multipart parser can't be worse than a mf parser ;)
#kylewmKevinMarks_: I think that snarfed actually wrote a wiki entry summarizing it, one sec
#rhiaroI guess most people parse external posts once and store contents themselves? Is anyone grabbing posts every time they need to be rendered?
#rhiaro(and not needing to worry about if it gets edited / deleted, wrt updating own store)
#rhiarowait, maybe someone wrote about this on the wiki already
#aaronpki have a two-step process, first i fetch and store the HTML, then I parse the HTML and store that as JSON. when my site renders comments, it loads the JSON
#tantekrhiaro: typically yes webmention sources can be cached
#rhiaroconsiders storing other people's posts as rdf
#tantekcache the procssed form in whatever works best for your system!
#rhiarodoesn't feel like writing a mf2 to rdf converter right now
#tantekthen you could cache the JSON parsed result like aaronpk
#rhiaroI don't expect there would be massive speed advantages to caching, but maybe I'm wrong. But another reason would be to reduce polling of other people's sites? How much does that matter?
#aaronpkyou really don't want to make an http request on each view of your page
#aaronpkcaching the parsed json may be over-optmized, you can probably get away with parsing the HTML each time
#aaronpkthe reason I store the original HTML is so that if I change how I consume HTML, I don't have to re-fetch all the URLs, Ican just update my parser
#aaronpkpeople change their display name on twitter all the time as a joke, which might be more appropriate to keep displaying the name at the time of posting
#rhiaroI would definitely want to err on displaying current name as opposed to name at time of posting
#rhiarogiven the number of people I know who have (often distressing) problems with people/orgs calling them by their old names, I wouldn't want to increase the amount of old-name-occurences lurking on the web
#tantekand your reader has a PuSH subscription to their home page, and updates the nickname cache accordingly
#rhiaroanyway, I'm still interested in updates for h-card changes given that silos do that, and commenting on/liking an profile update is also possible on silos
#tantekrhiaro: it's merely an "h-card" follow, perhaps the lightest form of following
#rhiaroyeah. You can do a h-card follow without needing a full reader
#rhiarobut they need to publish their changes as posts still right?
#KevinMarks_right, I should cache old twitter images on my static site, not the company worth billions
#LoqiIndieArchive is a project to collaboratively grow an archival copy of pages replied to (possibly also mentioned) in indie web posts https://indiewebcamp.com/IndieArchive
#tantekno KevinMarks_ you should cache them in free space on gihutb per /IndieArchive :P
#rhiarotantek: yes, will document. This conversation *is* beginngin research (which means it's a bit frustrating when you say "implement!" and I say I will and you say "reaearch!", or at least that's what' I'm getting)
#KevinMarks_thank you middleware people for making my site better, whoever it was
#tantekrhiaro: nonetheless you drew new insights into what can/should be cached and what should be updated
#aaronpktantek: one problem i've encountered with storing files on disk that match URL paths is this (and this is what's keeping me from implementing indiearchive right now)
#aaronpkwhen someone has two URLs such as aaronparecki.com/tag and aaronparecki.com/tag/indieweb, I can't save them on disk because the first expects "tag" to be a file, and the other expects "tag" to be a folder
#tantekI feel like this is the kind of thing someone would have solved
#aaronpki had to solve it for spiderpig but it is not an ideal solution for indiearchive
#aaronpki force every web page to be called index.html and be served from a folder that ends in /
#aaronpkso on disk, i would actually have aaronparecki.com/tag/index.html and aaronparecki.com/tag/indieweb/index.html
#aaronpkand the web server ends up sending redirects from /tag to /tag/ and such
#aaronpkwhich works fine when you're intending on flattening a dynamic site into HTML as a static archive of it
#LoqiA nicknames cache is a way indieweb sites store information about people to improve the user experience of the site owner referring, mention, and/or linking to those people https://indiewebcamp.com/nicknames-cache
#tantek.comedited /nicknames-cache (+438) "/* Better Person Icon Display */ note that showing the icon as of the time of a post is also valid, add tweet citations from benward and kevinmarks" (view diff)