Loqi[tantek] I think yes (really need a "tweetstorm") and here's the two key reasons why:
1. **Lowest switching cost.** Tweetstormers would easily be able to switch to using the Known tweetstorm UI instead of their existing behavior on Twitter. Lowering that fri...
Loqitweetstorm is a series of tweets, each replying to the previous, often each numbered so the sequence is clear, as a method of expressing a longer series of related thoughts as a single thread on Twitter https://indieweb.org/tweetstorm
aaronpktantek: the notes on the Instagram page have been updated since it first launched and it appears that the posts are discrete units now rather than each image having its own commetsn for example
tantekand I'm willing to be that that "can't have their own comments" is just a "there's no UI for them to have their comments". you can't actually determine that their data structure disallows comments
LoqiA gallery is a deliberately curated set of photos, that may itself be a post, or an archive view, or potentially dynamically created via tags https://indieweb.org/gallery
aaronpkalso actual radio has been doing essentially microcasts long before podcasts so it's kind of interesting to see it starting to turn back into that
schmartyaaronpk: also curious what you use to make your percolator posts. I am looking forward to making some improvements to screech and am looking for feedback from users :)
tantekyou have to keep updating it whenever the silo adds features because there is an implication that the service will pass along whatever is on to the receiver
LoqiReact (also called ReactJS) is an open source web framework created by Facebook that can be responsibly used (simultaneous client and server support) yet often abused for js;dr pages and sites https://indieweb.org/React
tantekand consider moving it higher up in the markup, perhaps right after the h-* that it applies to, just to make it more obvious which object the <a class="u-url" hidden ... > applies to
tantekthat's a pretty big change but it shouldn't break any existing working content, because such relative URLs outside of URL attributes don't work today anywa
tantekdefinitely mention the use-case of wanting to use <data> for a relative URL instead of a hidden <a href> which is undesirable for all the usual semantics / screen reader etc. reasons
tantekwell then now that barryf's pull request is depending on that data u-url relative URL resolution, we ought to get at least one parser implementation to implement it
Loqi[jonnybarnes] In the spirit of keeping things simple I’d have bridgy HEAD request the image linked to in `src`, if that can be POSSE’d then just abuse that. Even if a “better” valid image exists, in the `srcset`.
Then maybe we could reuse the code and d...
Loqi[snarfed] sure! HEADing to check for size is easy. not all servers support it, sadly, but that's a separate question.
the main question here still seems whether and how to get the `srcset`'s image URLs into the parsed mf2 that bridgy and granary use interna...
aaronpk"if there is a video property and photo property and they each have only one value, then display as a video using the photo as the poster image"
tantekand yes, building readers is hard, that's no surprise, and there are many other more important challenging problems for a reader far beyond any kind of parsing minutiae
aaronpkmy point is it's not theoretical when building a reader because you have to make some decision about what to do, even if what to do is treat it as an error case
tantekif there's stuff missing from PTD on how to handle existing real world case, definitely file an issue for those with links to those real world cases
[cleverdevil]Okay, I'm exploring doing a sponsored open source plugin for Discourse to support Webmention (and potentially a few other things). My goal is to get DreamHost to pay to have it implemented. Are there any Ruby developers in the IndieWeb group that may be interested in working on such a project?
tantekI for one would trust someone with multilingual programming experience that has webmention receiving implementing experience to be able to pick up the "rubyisms" fairly quickly
aaronpkalso starting to think it might be useful to have a way for micropub clients and servers to know about what features are supported automatically
tantekbetter to try to see if you can design the interactions with fallbacks so that things "just work" with existing implementations, and if there's richer content, the implementations can upgrade and get it as they see fit
tantekconneg waas supposed to be simpler than arbitrary capability negotiation, and it's still kind of a joke on the web because nearly no one supports it or handles it well outside of obscure formats
tantekaaronpk if I Bridgy Publish a multiphoto of say 8 photos, it only sends the first four to Twitter, and the first one to Flickr, and the first one to FB
aaronpkmy site supports multi-photos via micropub, but not collections via micropub. and micro.blog supports multi-photos via micropub as well, and has no concept of collections
LoqiA multi-photo is like a photo post, except just with multiple adjacent photos, either in a series, or tiled / arranged in some layout https://indieweb.org/multiphoto
tantekor rather, always better to answer the " is " question with the proper capitalization since Loqi search will find it regardless of how you ask the next time, but links on the wiki require the proper capitalization
tantek.comedited /Instagram (+645) "/* Features */ collections, limitations, note stories support various tags/labels/stickers and pinning them to moving things" (view diff)
tantekaaronpk heads-up because it seems maybe you noted off the top of your head: swarm checkins limited to 7 photos, IG multiposts limited to 10 items