radicaledlaptopDoes anyone in here know enough about dbus to know whether my attempt to apply it is in scope for it or not? I want to use it to fire an event whenever rsstail picks up a new rss entry. Then multiple scripts on the server could be listening for rss entry events and do processing.
KartikPrabhu, tantek, renem and [cleverdevil] joined the channel
tantek.comedited /reply-context-examples (+239) "permalinks and in-stream, merge new Twitter in-stream example with existing Twitter examples since they were in-stream as well, keep fragment as ID" (view diff)
danq.meedited /RelMeAuth (+452) "/* Consolidated identities do not carry inherent trust */ Added support for rel="auth" so long as rel="me auth" and rel="me" are still good" (view diff)
KartikPrabhu, [mrkrndvs], Zegnat and [gerwitz] joined the channel
[gerwitz]Does anyone have a “best practice” for detecting the source of a POSSE post? E.g. the posts from OwnYourGram could be auto-tagged based on including instagram.com URLs, or based on the poster’s network address, or … ?
[gerwitz]indeed, I could parse that for domain name, or I can use the client id from token redemption. I’m at a loss for reasoning between depending on “instagram.com” vs. “ownyourgram.com”.
[gerwitz]not necessarily, but I want to “route” those posts for some processing based on source. So while I lean towards syndication, if my routing needed to fix something because I disagreed with a choice (e.g. tag/category mapping) from an intermediary, maybe I’d regret that.
sknebelif you want to fix a specific thing with how ownyourgram sends you the posts, going by client_id seems to make more sense, although I guess it's a bit moot if nothing else creates instagram posts, so go with whatever is easier I guess
aaronpk[gerwitz] I also recently added a field to ownyourgram that will let you set one or more category values that it will send along with each post, in case that helps with things
eli_oat, KartikPrabhu1 and [kevinmarks] joined the channel
LoqiIt looks like we don't have a page for "detecting the source of a POSSE post" yet. Would you like to create it? (Or just say "detecting the source of a POSSE post is ____", a sentence describing the term)
tantek.comedited /reply-context (+474) "/* Minimal text reply contexts */ special cases for github issues and comments since those are URL inspectable" (view diff)
tantekyes it's a lot of info packed into that header: who retweeted, original post author, dt-published, then reply-context, then tweet content, then link-preview, then reply/retweet/like webactions with counts!
tantekwhat's annoying about twitter's in-stream reply contexts is that the "Replying to" doesn't link to anything, and the @-name in the reply context just links to that profile - which is not really useful. None of it actually links to the thing being replied to (the in-reply-to URL)
snarfedwow, interesting. discovered a meaningful difference in mf2py output based on the underlying html parser: html5lib omits the contents of <noscript> tags; lxml includes them.
www.boffosocko.comedited /Twitpic (+133) "Twitpic.com URLS for photos apparently still resolve directly to the photo though the prior UI for the service is gone" (view diff)
tanteke.g. right now when you're looking at a Pull request on GitHub, the Files changed tab in particular, there's a "Review changes" drop-down in the topright of the view of the diffs. Clicking it shows a "Review summary" text field, as well as radio group for ( ) Comment / ( ) Approve / ( ) Request changes, and then a "Submit review" button
LoqiA review is an evaluation of a product or service, usually involving a written description, but can also be limited to a numerical scale https://indieweb.org/review
snarfedtantek: yeah PRs are way more complicated than issues. they include git commits (a big new can of worms), comments can be on the PR or individual commits or arbitrary diff lines, etc.
snarfedi'm still reluctant, since reviews often include a bundle of commit- or diff-level comments, which i doubt we have good enough indieweb prior art for
snarfedanyway, the commit- and diff-level comments are what hold me back. those we have not thought through in indieweb yet afaik. and they're important enough to code reviews that i'd be reluctant to ship support without them.
tanteksnarfed, I can't POSSE GitHub reviews manually currently as my code will automatically POSSE any such attempt as a comment using Bridgy Publish :)
tantek.comedited /review (+2720) "move indieweb examples from /h-review to /review, expand silo examples, add GitHub review example, stub Why, How to, How to publish" (view diff)