How to consume various indieweb building-blocks:
Use cases for consuming feeds
- reading posts from people I follow
- "here's a microformats feed, mind the values for category x and property y" from Beeminder - Allows them to avoid writing OAuth integration with every provider's proprietary API
Multiple feeds on one page
It’s fairly common  (examples needed) to have a feed page with one “main” feed on, and then other auxiliary feeds, e.g. recent tweets
This forces feed readers and any other app which consumes feeds to present the user with a UI asking them to choose which feed to subscribe to.
- As soon as this choice is made, the feed content no longer has a URL (requires extra non-URI state to be stored), complicating things for the feed reader and meaning that the user can’t seamlessly move that feed to another reader (portability) or recommend it to others, as it has no URI.
Possible solution: give the h-feeds id attributes so they all have URLs
- I don’t like this much as it requires publishers to put poorly-understood attributes on all h-feeds, otherwise they’re useless. It also requires all microformats2 parsers to understand parsing from an ID element, which is not currently part of the spec. IDs are intangible — users can’t look at a HTML document and see what each ID means. URLs are tangible, it’s obvious what they represent. --Waterpigs.co.uk 14:39, 21 October 2013 (PDT)
Previously discussed in #microformats on IRC, result of discussion was “consume first h-feed found”