This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady
What I Built
I built devto-digest, a small ...
Some comments have been hidden by the post's author - find out more
This is great inspiration for stuff we can try and fold back into the core product 😄
Great stuff
Thank you Ben!
I know we already get daily and/or weekly digest emails, but they're either too relevant or not relevant enough, and I'd like to discover more, whenever I want! ✨🧙♂️
The
tags=vstag=trap is brutal, and it's exactly the kind of thing that only shows up in production. I've hit similar issues with APIs that silently ignore parameters when you add a second one — the request "succeeds" but returns garbage.The Discover section being almost empty is the part I find most interesting. 31 out of 2,150 posts having zero of your 119 tags means your bubble is basically the whole site. That's not a bug in your code — it's a bug in how dev.to's tag system works.
Curious how you'd fix it if you had more time: would you weight by "least similar" tags, or just add a manual "explore these specific tags" list?
Thanks for reading my article, Oleksandr! There used to be a tag weighting system, but I don't see it on the current page anymore. 🥹
But you can hide some tags in this page
"That used to be a tag weighting system, but I don't see it on the current page anymore" is the most honest thing I've read about dev.to's API today. It's not that the feature is broken, it's that it silently disappeared.
Curious if you've found a workaround. If the API doesn't support weighting, does your script just treat all tags equally, or do you have a hardcoded "these tags matter more" list?
The script doesn't apply any weighting, but that should be easy to do. On another similar project, I assigned weights to each tag. Here in this project, I can specify in the configuration file whether to add an additional tag or remove a tag (GitHub).
ignoreAuthorsis the feature I didn't know I needed. Some authors post 10 times a day, and even if the content is good, they flood the feed.Curious how you handle the "I want to see this author sometimes, but not every day" case. Is there a "mute for a week" option, or is it a hard block?
That's not in the project. Feel free to contribute and add that!
Brilliant and bookmarked!
Thank you Earl! 🧙♂️
Okay, this is epic. Good stuff :D
Thank you Francis!
This is really nice! 😸 I starred the repo too! ⭐
Thank you² ! 😁
Haha, less scrolling, more discovering! 🦥📩 Love this lazy genius!
Aha thank you !
“A screenshot found what no test did” is such a real lesson. You can test contrast and escaping all day and still miss text running off a phone screen. Also love that the email still ships with dev.to’s own descriptions if the model is down. The AI makes it better but never decides if you get it. Starring the repo!
Thanks you!
A neat practical open‑source utility. It solves a common social‑media pain point: following hundreds of tags does not equal better discovery; you still miss great posts outside your existing interests.
Thank you for your feedback! 😁
With 119 followed tags, I'd try measuring novelty against the last few digests instead of only the followed-tag list. I'd want Discover to avoid giving me another version of a topic I just read, even if the tags differ. A small explanation beside each pick would help me tell whether that experiment is working.
This is such a clever and practical solution to feed fatigue!
The Discover section logic and weighted scoring system (giving more weight to niche tags like htmx) are brilliant design choices. Also, huge props for documenting the actual API traps like the plural tags= parameter ignoring top=—that's a super valuable heads-up for anyone working with the Forem API.
Love that you kept accessibility (WCAG AA contrast tests) and prompt injection safety as top priorities from day one. Great submission for the challenge, star-ing the repo!
Thank you for your feedback!
Nice Idea
Thank you!
I'd keep a couple of Discover slots independent of clicks when you add that feedback. Otherwise, a few clicks on familiar topics could slowly turn it back into the feed you were trying to escape.
Super inspirational thank you for sharing!
thank you!
If you're interested in this automated job, you can check out the latest Actions on GitHub 😄
The reviver-as-a-transform-layer idea works well, but the case it quietly
breaks is numbers: by the time your reviver runs,
9007199254740993isalready
9007199254740992. The reviver sees a double, not the literal.Hello! Can you explain more about this problematic? Maybe you found a bug, don't hesitate to contribute to the project 💚
The boundary I like most is keeping the model's summary as untrusted article content, then escaping it before the email render. A regression fixture with an “ignore prior instructions” blurb plus HTML-like text would make that safety claim repeatable. Have you added an end-to-end digest fixture that asserts the rendered email, not just the model response?
The tags= vs tag= trap is the nastiest kind of API bug: silent wrong data instead of an error. I have been burned by the same shape of problem, where a plural parameter quietly drops a constraint and the response looks identical to a correct one unless you are specifically watching for it. The fix I now apply on my own APIs is a response-side canary: when I request a time window, I assert that at least the newest returned item falls inside it, and fail loudly instead of shipping a digest full of stale posts. Cheap, and it catches exactly this class of bug. Do you run any validation on the collected pool before it gets scored, or does the recency weighting just silently absorb whatever the API hands back?
Topic diversification should be evaluated as more than novelty: readers still need relevant and coherent recommendations. A useful report would show diversity, click-through proxies, and a small blinded relevance sample before and after the open-model change.
the line telling the model that everything inside an article is untrusted data is the one most digest tools skip. the html escape on the blurb is what actually saves you though, since prompt level rules fail eventually and escaping fails closed. we treat summarizer output as hostile text at the render layer no matter what the prompt says. one thing i would watch is the score of reactions plus twice the comments, it tends to boost heated threads over useful posts. have you looked at what the discover section surfaces after a few weeks?
No for the moment
Hello! it is possible to get more about this problematic? Maybe you found a bug, don't hesitate to contribute to the project