benwerdkylewm: I'll loop back and think about heuristics for this. Makes sense, I think, for p-in-reply-to with a u-url inside it to be effectively conflated to u-in-reply-to behind the scenes.
KevinMarksso will this show as POSSE to bridgy? I reposted the New Clues on my own site so that Webmentions and fragmentions can be used on it: http://www.kevinmarks.com/newclues.html ”ª#”Žindieweb”¬
LoqiFacebook is a popular content hosting silo and activity aggregator most well known for being the largest centralized social network on the web https://indiewebcamp.com/Facebonk
aaronpkI don't know if this is something you were expecting, but I made a point of never adding css rules to microformat classes, I always add a separate class if I need to for CSS
aaronpki did that for about 5 pages of comments, then realized there were 50 more pages and stopped, and just deleted them from the database with a SQL query
kylewmsnarfed: had an FB API question for you, I can't seem to get any information about my friends or their posts through the API anymore. including facebook-atom is empty
snarfedso, re twitter profile pictures changing…i give in. i'm switching bridgy to use the unofficial url that permanently redirects to the current picture
aaronpksnarfed: yay! I think that's a good start. But probably we should all be better about storing profile photos on our own sites, especially since we have to in order to not get ssl warnings
snarfedthe resulting images will be the same; the only change is that the img src will now point to a url that redirects to the current image, instead of directly to it
snarfedbtw aaronpk, hopefully the mixed mode warnings are caused by native wms (if at all), not by bridgy. it tries hard to always return https profile picture urls
snarfedlooking at my pictures as a sample, my "original" 512x512 one is ~30K, and the "normal" 48x48 one is ~2K. so, bigger, but not actually big per se
KevinMarks_So if I don't find a webmention endpoint, call them instead, then in the future if they add the webmention.herokuapp.com markup, they get the older ones.
snarfedmore importantly though, those image fetches don't block fetching and rendering your page. the only thing that blocks is filling in the avatar images. so the slow "feeling" is probably mostly just seeing the "Connecting to twitter.com" bar in the bottom
KartikPrabhu<sigh> I can't do responsive images then I use JS to load the correct size image and avatar loading then blocks content images from loading
tantekKevinMarks: it's not an absolute good/bad thing, it's more like a flexibility of engineering, reducing unintended maintenance connections/burdens
kylewmtantek: that's fair. i guess my question is: is there general consensus that PuSH is the mechanism indiereaders should try first before inventing something new?
tantekNo other alternate mechanism has been proposed, and we haven't had sufficient pushback (no pun intended) against PuSH by people trying to implement PuSH consuming.
KartikPrabhubut if everyone implements their own PuSH hub, then my site would have to keep records of all of those subscribing to send them notifications no?
kylewmno, your site says "I'm using hub XYZ", and then when someone wants to subscribe to updates from your site, they subscribe to it on the hub you specify
KartikPrabhuwell. I don't want to rely on a third-party hub. Then I have to run my own hub which makes me keep records of all subscribers. I just don't see the advantage over readers polling my h-feed to get updates. They can do so without me tracking who is subscribed
KartikPrabhui mean why should I build this large plumbing just to not rely on third-party hubs, when readers can use an existing mechanism ( polling h-feeds ) to get updates?
tantekkylewm: I had said: 15:25 kylewm: thus I think the current consensus / passive opinion is to *try* consuming real-time via PuSH and see how easy/hard it is.
tantek15:28 KevinMarks: in answer to your question - in order to fix a *one line* microformats2 error in *one file* in idno / Known, I had to also touch *four* other style sheet files, since they were depending on the previous/wrong microformats2 class name.
tantek15:28 Thus 5x the amount of work that would otherwise be necessary for a microformats markup bug fix, caused *purely* by depending on that/those microformats2 class names for CSS rules.
tantek15:33 Thus, "styling microformats classes" causes more maintenence work when you make microformats related fixes / changes / updates / improvements, real world example ^^^
tantekso far the evidence is anecdotal, but it does seem like having a set of classes specifically for styling rather than microformats allows for a more easily maintained overall system.
KartikPrabhukylewm: I get those things. But again is there any advantage over my reader polling you h-feed instead of doing all this round about trickery?