I have been using astronaut as my main gemini browser for a few weeks
now, and one thing has caught my attention. Many of the gemlogs I read
either provide an Atom feed or have indexes set up as a feed[1]. I would
like to be able to have astronaut subscribe natively to these and have a
"subscriptions page that displays updates like an rss reader would, then
let's me link to the new posts. I believe I could implement a bare-bones
version of this myself, but want to know if it's in scope for astronaut
to do this before I even begin. Thanks for the feedback!

On Dec 29, 2021 at 7:50:42 PM, ShockTohp wrote:
> I have been using astronaut as my main gemini browser for a few weeks
> now, and one thing has caught my attention. Many of the gemlogs I read
> either provide an Atom feed or have indexes set up as a feed[1]. I 
> would
> like to be able to have astronaut subscribe natively to these and have 
> a
> "subscriptions page that displays updates like an rss reader would, 
> then
> let's me link to the new posts.

Hi! I would be interested in seeing what an implementation of this would 
look like. However, I have a few questions about how it would work.

1. Would the subscriptions be checked periodically while astronaut is 
running, when astronaut is first launched, or manually (e.g. on page 
refresh)? Are users expected to keep astronaut running in the background?
2. How would the subscription state be stored? How do you expect to 
handle multiple concurrent instances of astronaut? We will likely need a 
lock file.

An implementation of this should support Atom feeds and Gemini feeds.

I'm still not sure if this should be part of astronaut. You may also be 
interested in gemreader[1], an RSS feed reader service. Perhaps gemreader 
can be modified to work locally.

Also, what do you mean by "link to the new posts"?

[1] https://sr.ht/~sircmpwn/gemreader

On Thu Dec 30, 2021 at 3:01 PM GMT, Adnan Maolood wrote:
> On Dec 29, 2021 at 7:50:42 PM, ShockTohp wrote:
> > I have been using astronaut as my main gemini browser for a few weeks
> > now, and one thing has caught my attention. Many of the gemlogs I read
> > either provide an Atom feed or have indexes set up as a feed[1]. I 
> > would
> > like to be able to have astronaut subscribe natively to these and have 
> > a
> > "subscriptions page that displays updates like an rss reader would, 
> > then
> > let's me link to the new posts.
>
> Hi! I would be interested in seeing what an implementation of this would
> look like. However, I have a few questions about how it would work.
>
> 1. Would the subscriptions be checked periodically while astronaut is
> running, when astronaut is first launched, or manually (e.g. on page
> refresh)? Are users expected to keep astronaut running in the
> background?
> 2. How would the subscription state be stored? How do you expect to
> handle multiple concurrent instances of astronaut? We will likely need a
> lock file.
>
> An implementation of this should support Atom feeds and Gemini feeds.
>
> I'm still not sure if this should be part of astronaut. You may also be
> interested in gemreader[1], an RSS feed reader service. Perhaps
> gemreader
> can be modified to work locally.
>
> Also, what do you mean by "link to the new posts"?
>
> [1] https://sr.ht/~sircmpwn/gemreader

I personally think this is way out of scope of astronaut. Astronaut is
pleasantly minimal and works almost perfectly for what is does. I
suspect implementing feed subscriptions will bring about many more
unforeseeable edge cases and degrade the astronaut experience, from
installation to configuration to usage.

It would make more sense to me to use a separate tool for subscriptions,
a daemon which presents a subscription feed as a gemini page (locally or
online, at the user's descretion) which astronaut can browse normally.
Thus, no problems with concurrency, cache, or conflicting configuration.

Maybe gemreader is that solution. I'm not familiar with gemreader, and
the project capsule is down for me for now.

This is why I asked. Not looking to implement something undesired and
out of scope.

> > 1. Would the subscriptions be checked periodically while astronaut is
> > running, when astronaut is first launched, or manually (e.g. on page
> > refresh)? Are users expected to keep astronaut running in the
> > background?

I would check on subscription page load and reload, that seems
reasonable. No point in checking if the user isn't navigating to that
page after all. No need to keep astronaut running, as the state would be
stored locally.

> > 2. How would the subscription state be stored? How do you expect to
> > handle multiple concurrent instances of astronaut? We will likely need a
> > lock file.

Likely the subscription state would be stored in an xml document or
similar on the users hard drive. Each subscription would be a block with
a title, link to the atom or gemini feed, then a sub block of posts with 
their title, link date and read status. Multiple instances of astronaut
was not something I have considered yet, but it is a prickly problem.

> > Also, what do you mean by "link to the new posts"?

Letting the user navigate to a post they wish to view, and marking it as
read.

> It would make more sense to me to use a separate tool for subscriptions,
> a daemon which presents a subscription feed as a gemini page (locally or
> online, at the user's descretion) which astronaut can browse normally.
> Thus, no problems with concurrency, cache, or conflicting configuration.

Newsboat, my preferred rss reader, has MIME type mapping for exactly 
this case, but doesn't understand the gemini protocol itself, so I 
can't add links to gemini://foo/bar/atom.xml. 


I agree with the feed back, astronaut really isn't the place to to be
handling subscriptions. It would be simpler to get all my
RSS/Atom/Gemini feeds in one place, and parse out handling rendering
those to the proper program. I will give gemreader a look and see, but 
I am not a huge fan of adding more programs to do the same job. Likely,
the answer is adding the gemini protocol to newsboat or similiar. Though
that has it's own issues.

Thank you for the feedback so far!

--
Cheers,
	ShockTohp

On Thu, 30 Dec 2021 22:37:12 -0600, ShockTohp <shocktohp@shocktohp.xyz> wrote:
> It would be simpler to get all my RSS/Atom/Gemini feeds in one place, and
> parse out handling rendering those to the proper program.

If I may suggest, astronaut could implement a 'dump' feature: say if a
flag -dump is passed before the url, then astronaut prints the plain
content to stdout (unless there is an error etc), and then you can use
this as a generic gemini-getter for anything, including doing the
network bit of downloading feeds.

> the answer is adding the gemini protocol to newsboat or similiar.

I don't know about newsboat, but this (or any other similar tool for
gemini) could work painlessly with sfeed:

in your sfeedrc:

    #!/bin/sh

    fetch() {
        case "$2" in
            http*)
                curl -L --max-redirs 0 -H "User-Agent:" -f -s -m 15 \
                    "$2" 2>/dev/null
            ;;
            gemini*)
                astronaut -dump "$2"
            ;;
        esac
    }

    feeds() {
        feed "ddevault https"  "https://drewdevault.com/blog/index.xml"
        feed "ddevault gemini" "gemini://drewdevault.com/feed.xml"
    }

On Sun Jan 9, 2022 at 9:58 PM EST, phoebos wrote:
> If I may suggest, astronaut could implement a 'dump' feature: say if a
> flag -dump is passed before the url, then astronaut prints the plain
> content to stdout (unless there is an error etc), and then you can use
> this as a generic gemini-getter for anything, including doing the
> network bit of downloading feeds.

gmni [1] might be better suited for this. It offers a curl-like utility
for fetching Gemini content.

[1] https://sr.ht/~sircmpwn/gmni