publish: iterate over all h-entrys on a page (not just one)

[tantek]

Recently I started clustering adjacent lightweight interaction posts of the same type, e.g. likes, which then link to a separate page that lists them individually. E.g. http://tantek.com/2015/002/f

It would be handy to be able to use Bridgy Publish to automatically POSSE those all those likes to FB with one Bridgy Publish call/curl, rather than calling Bridgy Publish once per h-entry on that page.

If there's a worry of accidental misuse, the "publish all h-entrys on a page" feature could be constrained to:

• must be all same "type" (Bridgy already has some notion of post type in its logic that uses to say what's going to happen in the Bridgy Publish UI)
• must all be to same silo

[snarfed]

thanks for filing!

see irc snippet below for my concers about the complexity. the key thing i'd want to wait on for a bit is to see what common indie like flow emerges. do most people like one or two things individually? do they cluster, then try to posse the cluster? or do they like and posse a bunch of things, then cluster afterward in presentation? etc.

discussion from irc:

snarfed 10:46 tantek: honestly i don't know. i suspect it would add a fair amount of complexity, at least to get the behavior "right" for all cases tantek 10:46 it's not "just" a loop over the h-entrys on the page? snarfed 10:46 …which i don't have to do, but i'd rather not have a bunch of undefined behavior at edges 10:47 it might be, i just have a feeling it will result in surprises 10:47 i'd need to think about it more 10:47 e.g. if a new user accidentally plugs in a feed permalink, and bridgy happily goes and posts 20 new tweets for them tantek 10:48 got it snarfed 10:48 i detect when people put in their home page, and other obviously wrong inputs, but still tantek 10:48 yes I was thinking of more scoped use-cases like http://tantek.com/2015/002/f snarfed 10:48 feel free to file an issue so we can discuss though! 10:48 definitely, i totally get your use case. it's just uncommon tantek 10:50 snarfed, uncommon for now ;) snarfed 10:50 sure! 10:50 i try not to predict the future too much :P tantek 10:50 I see clustering of same-kind adjacent posts as natural step forward 10:50 which then implies a page for such clusterings aaronpk 10:50 me too. I try to create the future. Easier to predict that way. snarfed 10:50 definitely! clearly better ui. i just don't know that people would naturally want to bridgy publish those clusters instead of individually 10:51 the clustering seems more appropriate to do afterward, purely as presentation

[kylewm]

I'm uncomfortable with Bridgy publishing an entry where the source parameter is not the permalink being published. I feel like the one input → one output (source url for syndication url) is a nice guarantee/sanity-check, and it feels more in line with the way webmentions are used elsewhere.

Also this would add complexity in other places, not just for sanity checking inputs:

• Preview UI would need to show multiple syndicated posts
• API users that depend on the return value of the POST would need to check for a syndicated URL or a list of syndicated URLs

[snarfed]

thanks for the input, @kylewm! agreed with the simplicity and robustness of one input -> one output, as well as the two complexity examples.

[snarfed]

tentatively closing this, at least for now.