Skip to content

Not built yet

Charcha is a v1 in progress, and this is the list of things it does not do. Read it before you wire comments into your templates rather than after.

Every entry names an open issue on withsetu/charcha, so you can follow the ones you care about. There are no dates here. An issue being open means the work is not done, and nothing more than that.

There is no importer. #15 is the issue. Disqus exports a documented XML format and nothing in Charcha reads it, so moving a decade of comments across today means moving them by hand.

If your archive matters to you, weigh this entry heaviest.

The embed is a script. With JavaScript switched off it never runs, and there is no form already on the page for it to have enhanced.

#80 tracks the floor, and it is two missing pieces rather than one. Markup on the page before any script runs, which is the server-rendering work planned for v1.1. And an endpoint that accepts a native application/x-www-form-urlencoded submission and redirects, because POST /comments reads JSON and answers 400 to anything else.

The same gap is why a crawler that does not execute JavaScript sees no comments on your posts, and most AI crawlers do not. If comments showing up in search results or in a crawl is part of why you want them at all, this is not the release for you yet.

All eight layers are built, classifier and third-party provider included. What is missing is any control over them, and two holes in what they catch.

#66: every threshold is a constant in the source. The per-address limit, the link count, the two-second timing floor, the score at which the classifier speaks. Changing one means editing the code and redeploying, and the dashboard cannot even show you what they currently are.

#41: the lookalike-domain check catches a label mixing Latin with Cyrillic or Greek, and misses whole-script confusables, where nothing is mixed. It does not decode punycode either, so a label that already reads as ASCII goes through unexamined.

#28: marking a comment spam moves the replies underneath it to the same status, and nobody read those replies. That mattered less when the label was only a status. Now that the classifier trains on your moderation decisions, a machine-made verdict wearing a human’s name is one wiring mistake away from being training data, and replies to spam are disproportionately good comments, so the error would not average out. Charcha trains only on the comment you actually clicked, which is what keeps the two apart today.

#81 is relative time in the reader’s own timezone, and it is not built. What the renderer emits instead is a real <time> element with a full-precision datetime attribute and visible text in UTC, which is correct as it stands. Rewriting it needs the reader’s clock, and that is bytes against a 10 KB embed budget, so it is planned as a separate opt-in entry point rather than a branch inside the core embed.

You cannot set a display timezone for your site either. That is #45.

None of it. A reply written on somebody else’s site does not appear in your Charcha thread, and there is no endpoint to receive one.

#82 is the epic. Its children are the schema (#83), the endpoint and its SSRF surface (#84), microformats2 parsing (#85), putting mentions through the spam pipeline (#86), rendering them (#87) and a webmention.io source (#88). Sending webmentions is out of v1 on purpose, #89.

If IndieWeb interop is what you came for, use something built for it and check back.

#109 is bulk actions. One decision, one request, one comment. A loop over the existing write would throw at around fifty comments, where the per-request query budget ends, so the fix has to be set-based rather than a faster loop.

#131: you cannot reply from the queue. The renderer already emits charcha-comment-by-owner and nothing produces such a comment.

#163: undo does not restore the replies a spam or delete decision took down, and cannot, because nothing records what the cascade moved. The dashboard is at least honest about it and tells you before and after.

#121: a session lasts 12 hours and does not renew, so a long triage can end in a sign-out.

#43: nothing tells you when a new Charcha release exists. You find out by looking.

You get an email when somebody comments, if you set the Resend secrets. Nobody else gets anything.

#127: commenters are not notified of replies. The composer’s email field is optional and its hint mentions reply notifications, the address is stored, and nothing sends to it yet. The only address Charcha ever mails is CHARCHA_NOTIFY_TO.

#128: a notification that failed to send says so in the Worker’s log and nowhere the dashboard can show you.

#159: Resend is the only provider. There is no EmailProvider seam, so Cloudflare Email Sending, SES and plain SMTP are not options.

#108: Cloudflare Access is not honoured. The session endpoint already reports how you signed in, so the shape is there and the path is not.

#164: nothing checks your dashboard password against a breach corpus. The Setup tab does tell you when it is shorter than 15 characters, which is a much weaker question answered.

#124: whether the ratelimits binding the login throttle depends on is available on the Workers Free plan. Cloudflare documents it in none of the four places it would be, which is different from nobody having looked. One real deploy to a Free account settles it, and the issue is where to say so if you make one.

#149: GET /health proves migration 0001 ran, not that the whole migration set did.


Anything filed since this page was last checked is at github.com/withsetu/charcha/issues, and the v1 plan is #1.