mkoppmann / eselsohr Goto Github PK

We use Nix and can leverage the benefits of its caching abilities: https://www.cachix.org/

Don’t use WithError inside the infrastructure layer. Let the errors return to the controller, where appropriate error pages can be loaded.

Currently, some IO functions like reading or writing a file, or scraping a website, are throwing exceptions that are not handled. At least the common ones should be catched and converted into app specific errors.

Thanks to our web keys it should be no problem to add authorized feeds to RSS aggregators.
If tags are supported (#37) then feeds could be customized to only display read/unread articles or articles with specific tags.

The current implementation does not need it. It would still be useful for the test suite so it’s easier to verify state changing actions.

We could use Tailwind as CSS framework.
Their CLI tool looks for Tailwind CSS class names, so it can work with our Lucid HTML functions.

Here is an example how one can use Tailwind CLI with Haskell: https://github.com/srid/tailwind-haskell

It can be used for adding a new bookmark or creating a new accesstoken for example.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog

In addition to the HTML-only frontend, a separate JSON API would be handy so that other clients could get developed.
This should also showcase the chosen architecture as commands can be reused while queries are optimized for their specific output format. The main challenge will be the transportation of accesstokens. HATEOAS should be the solution for this.

Generating CSS with Clay doesn’t give us clear benefits, but it has some drawbacks:

• Its current version does not support GHC 9.2+ although its master branch already supports 9.4
• It’s not really easier to read or write than plain CSS
• CSS generated by Clay always ends with a footer referring to the Clay website

See: https://docs.servant.dev/en/stable/tutorial/Authentication.html#what-is-generalized-authentication

It would be great if the CI could also provide binaries for FreeBSD. GitHub Actions do not support FreeBSD directly, but apparently it’s possible to run FreeBSD in a VM in macOS runners: https://github.com/marketplace/actions/freebsd-vm

We already have a Dockerfile. For easy deployments, Eselsohr should also be available on Docker Hub for people who prefer containers.

It should be possible to add the current page to an article list via a bookmarklet.

The project currently only uses documentation sporadically. This needs to be improved.
Some tips can be found here: https://kowainik.github.io/posts/haddock-tips

This should be possible with a library like minio-hs or amazonka-s3.

When a web application is recognized by browsers as a progressive web app it can be installed and used similar to a native application.

These features are currently missing according to the PWA criteria list:

• Register a service worker with a fetch handler
• Reference a web app manifest

This would unlock additional features. For example, new articles can be added with the native sharing functionality of the operating system. (see Web Share API)

Currently Eselsohr binaries are only provided as CI artifacts. It would be great if binaries would be provided for each new GitHub Release.

Requires #27.

Eselsohr currently does not support migrations for the persisted data. This is absolutely necessary.

It should be possible to add notes or annotations to articles to capture some thoughts.

Adding some linters and other automated checks to the CI would be great. A list of possible options:

• hlint
• stan
• hadolint
• fourmolu

For example “expires in 3 days”

I wonder if we can use this to massively increase the speed of the GitHub Actions.
Building the Haskell binary every time is just slow.
Especially with the Trivy job where we don’t use the GitHub Actions cache.

https://determinate.systems/posts/magic-nix-cache

Similar to Indiepaper.

Currently, running Eselsohr is basically a blackbox.

A separate way to create collection has to be provided.

The sharing menu and the collection overview does list accesstokens but with no information about the embedded permissions.

It should be possible to add a recovery email address in case one forgets their collection unlock link.
The address could be stored as a hash.

This could be for example a TOTP token, as they do not require JavaScript to work.

We need this, everybody knows that.

Correct versioning is necessary for GitHub Releases, using Cachix (#4), and adding Eselsohr to Docker Hub (#3).

Requires #26.

Currently, timestamps are displayed for UTC. Two possible ways to fix this:

1. use JavaScript (built-in support)
2. add support for server-side storage of user settings. Timezone would then be one of the settings.

Solution 1 would be the easiest and the original timestamp would be displayed if JavaScript is disabled in the user’s browser.

It should be possible to add tags to articles to categorize them.

This allows us to use the new dot notation. This should be done first before the module structure is refactored again. With the removal of Clay (see #157) all remaining dependencies should have support for 9.2.

It would be very nice if one could add an article by sending it via email.
Similar to Evernote or Instapaper.

The current UI and UX is certainly not the best.

It should be possible to migrate between Eselsohr instances. An import/export feature is required for this.

Having a place where people can paste in their collection unlock access token could teach them that it’s OK to do so.
This then would make it easier for attackers to try some phishing attacks.
Maybe it’s better to say right away that the token and the URL should stay together.

When we generate a new unlock access token from the command line the correct URL should also be displayed.
For this we would need our BASE_URL config option back.

Haskell can be distributed as binary. We should provide one, at least with every release. Ideally, they would be completely statically-linked, so they have no dependencies on the system, but I’m not sure if this is currently possible with GitHub Actions.

In case someone wants to regenerate their collection unlock link (maybe the link was leaked in some way) this should be possible.
The old token then should be removed.

Currently, expired capabilities are bit-rotting in the persisted state. Some cleanup job should take care of this.

This project was once part of a private monorepo with its own CI. Now, with the release on GitHub, we should provide a configuration file for GitHub actions. A simple CI that just builds the projects and runs the test suite would be a good start.

It should be at least possible to toggle between read and unread articles.

We are currently using the old one which has less guarantees.

https://gitlab.haskell.org/haskell/filepath/-/blob/master/README.md#what-is-a-filepath

In addition to expiring capabilities, caps that can only be used a certain amount of time would be nice.