3 ms·

I think this is the same thing I was trying to address with this paragraph at the end: > Another suggestion: provide browser extensions and iOS/Android sharing

I think this is the same thing I was trying to address with this paragraph at the end: > Another suggestion: provide browser extensions and iOS/Android sharing menu items so that it's easy to open an web page in the reading app. If there's one or more RSS feeds detected, throw in a subscribe button with checkboxes for each feed. The "shareable subscribe links" should include a link to the original RSS feed in the page metadata. Then if I click on the subscribe link but want to subscribe with a different RSS reader, I can do so easily. i.e. we should be sure to provide smooth user experiences both for people who don't yet use a feed reader and for people who do. Agreed that Mastodon does this nicely, and I think adding in some browser extensions/mobile apps would help to automate things a bit more.

cxr 4y ago
Suppose someone registered a vendor-neutral, collectively owned* domain `feedme.example`. A static site would be hosted there. Instead of everyone being compelled to do one-off integrations with the most popular commercial services, they would instead link to their own feed e.g. as <https://feedme.example/#!/https://meta.discourse.org/posts.rss https://feedme.example/#!/https://meta.discourse.org/posts.r...>. The user's preferred reading app would be accessible in client-side storage for the feedme.example origin, and when the user actually lands on <https://feedme.example/#!/https://meta.discourse.org/posts.rss https://feedme.example/#!/https://meta.discourse.org/posts.r...>, it redirects to the appropriate service, assuming the user has already set it up. If they haven't, the feedme.example SPA prompts them to set it up. Client software will be free to hardcode support for this well-known name and provide native equivalence to the purpose that the softcoded feedme.example serves. A sort of lame re-invention of Web Intents; alternatively, basically the same as registering a new URI scheme with IANA, except there's a web-based fallback. * or collectively managed, at least; in the vein of w3id.org, for example

cxr 4y ago

Suppose someone registered a vendor-neutral, collectively owned* domain `feedme.example`. A static site would be hosted there. Instead of everyone being compelled to do one-off integrations with the most popular commercial services, they would instead link to their own feed e.g. as <https://feedme.example/#!/https://meta.discourse.org/posts.rss https://feedme.example/#!/https://meta.discourse.org/posts.r...>. The user's preferred reading app would be accessible in client-side storage for the feedme.example origin, and when the user actually lands on <https://feedme.example/#!/https://meta.discourse.org/posts.rss https://feedme.example/#!/https://meta.discourse.org/posts.r...>, it redirects to the appropriate service, assuming the user has already set it up. If they haven't, the feedme.example SPA prompts them to set it up. Client software will be free to hardcode support for this well-known name and provide native equivalence to the purpose that the softcoded feedme.example serves. A sort of lame re-invention of Web Intents; alternatively, basically the same as registering a new URI scheme with IANA, except there's a web-based fallback. * or collectively managed, at least; in the vein of w3id.org, for example