Roadmap#

Schemas & Config#

• Add notify top-level variables - allow notification channels to be added and configured, e.g. slack message or email
• Secret storage Allow users to store encrypted secrets in their config, e.g. protect webhook endpoint
• Stabilize config API for existing features

Crates#

• The top-level __tera_context object (for templating) is weird and sort of mysterious. There should be a __r3ply_context object within it that can be documented. It will be easier to remember plus __tera_context could still be useful for other things in the future and it might be bad design to expose the full context and not have a more focused option.

Library#

• Add ability to "replay" comments through different stages of the pipeline as starting points. This could be very helpful if people need to do migrations. E.g. Let's say you've made changes to your comment template, but you need to make sure all the old comments have those changes as well. You should be able to reprocess the old comments and then diff them with version control to check that everything worked as expected.
• Add support for email attachments (this could be a good path towards allowing sites to implement user icons)
• Add other comment sources. Perhaps a magic link or even a POST comment source?
• Add support for testing with localhost as the email address' local part of the address

Commenting Sources#

• POST + Magic Link?
• ActivityPub?
• AT Protocol?
• Text??
• Each commenting source's shared config should be broken out in the config's schema (see how moderation is done for inspiration)

CLI#

• For re simulate email make sure that only valid Subject lines are generated by default. To do this will require the intersection of the site's sitemap.xml and the site's [comments.path*] config variable.
• Add synonyms for the stage names to be used by the --filter/--quiet options. For example, currently comment is used instead of processed but it should technically permit both.
• Rewrite in rust

Public r3ply.com instance#

General#

• Dedicated email server
• Better error messaging, possibly by responding directly to the commenter

Moderation Channels#

• Email based moderation (Approve/Add to block*/approve* lists) from within email
• Add the cache as a moderation channel?

GitHub Moderation#

• Add support for public repos via a fork + new PR flow in the GitHub bot. (note: that at the moment this is not quite so straightforward. You can create a public user for a bot and use the rest api to fork a repo and then create a PR. The problem is that forking is async and the current cloudflare worker can't live that long. One solution would be to pay for cloudflare and use their queue solution. Another would be to create a jobs table and use a cron job to poll it every x minutes for any pending work. For the time being people should just know they need to install the r3ply bot github app and if they want to help fix this then the situation and the pros and cons should just be documented somewhere.)

Webhook#

• Better testing

Notification Channels#

• Build library support
• Email notifications to site

Site/Docs#

• Add search
• Tutorial section: for example, how to allow people to support aliases (will also be good for when attachments are supported)
• Add links in FAQ to relevant docs for each point
• Make demo comments content a little more relevant
• Add ability to pin comments, so people may comment on the demo section but the key ones that demonstrate important functionality stay at the top