My co-founders and I are building an AI assistant that helps immigrants navigate Finnish bureaucracy. As immigrants, we've experienced firsthand how fragmented and inaccessible essential information can be, scattered across Migri, Kela, the tax office, and municipal websites, often only in Finnish and Swedish.
We're using RAG (Retrieval Augmented Generation) to create a multilingual chat interface that connects people to official resources rather than replacing them. The system reduces "failure demand" - support requests that arise because people can't achieve their goals through existing resources.
The technical approach is a multi-agent system in which specialized AI agents handle different domains (immigration law, employment, housing, healthcare, etc.). We've named the agents after Finnish mythological figures (such as Tapio, Ilmarinen, and Sampo) to create a cultural connection while providing practical assistance.
Interestingly, this addresses a systematic problem - government agencies spend significant resources on repetitive support that could be automated. At the same time, immigrants get frustrated trying to piece together information from multiple sources.
We're exploring B2B opportunities (companies relocating employees, municipalities, healthcare systems recruiting internationally) and EU funding for integration technology.
Happy to share more details or get feedback from anyone who's worked on similar multilingual AI systems or government-facing tools.
I've had good success with the Context7 model context protocol tool, which allows code agents, like GitHub Copilot, to look up the latest relevant version of library documentation including code snippets: https://context7.com/
We just launched an alternative called Docfork that just uses 1 API call and wraps up the request (Context7 generally uses 2) since speed was a big priority for us: https://docfork.com
I wonder how necessary that is. I've noticed that while Codex doesn't have any fancy tools like that (as it doesn't have internet access), it instead finds the source of whatever library you pulled in, so in Rust for example it's aware (or finds out) where the source was pulled down, and greps those files to figure out the API on the fly. Seems to work well enough and also works whatever library, private or not, updated 1 minute ago or not.
Agreed. No reason to show more than 100+ entries on a single table. Event sourcing isn't about UI patterns but rather one level beyond it: the "back of the frontend" [1]:
Hopefully, we'll converge on a standard, product-agnostic file naming convention, similar to .editorconfig. Are there any existing/emerging generic conventions, like .llm-instructions, that products like Cursor and GitHub Copilot support? This could be useful for teams and orgs with diverse LLM usage.
While it's truly a great ongoing effort and I am grateful to all the contributors, it's not nearly complete. You may think you're using the correct type until, surprise, you are not.
As an aside, I can't praise the Wagtail CMS highly enough. It sets a high bar for usability and accessibility of the auto-generated content management UI.
The developer experience is top notch with excellent documentation and many common concerns already handled by Wagtail or Django. A significant amount of Wagtail-specific code is declarative, essentially describing data model, relationships, and UI fields. The parts that you don't need stay out of the way. It's also agnostic of the type of front-end you want, with full and automatic support for headless mode with JavaScript client, using traditional Django templates SSR, or using a dynamic approach like HTMX.
ty! We have no plans to rewrite Wagtail in Rust but I hope there’s ways in which we can make the developer experience better, particularly around dependencies management
They mention "other browsers" in addition to Firefox that will continue to support Manifest v2, but I can't find a list. Does anyone know off-hand the additional browser options for Manifest V2 and multiple-OS support?
I think some Chromium-based browsers like Brave have pledged that they'll keep v2 around for as long as it's practical? Though IMO, people who depend on Manifest v2 with Chromium forks are running on borrowed time, Chromium moves fast and I can't imagine that keeping the Manifest v2 code working will be very easy. Especially if Google takes advantage of the limited access extensions now have to the HTTP request flow to do major refactors in that area.
Chromium browsers can't make that pledge and those that promised have red flags in my book.
1. These browsers can barely add their own functionality on top of upstream, and maintaining Manifest v2 compatibility may be expensive. Consider that the development of Chrome exceeds 1 billion per year.
2. They all use Chrome's Webstore as a distributing channel, except for Edge, but IMO, Microsoft has an even bigger interest in seeing uBO die.
Brave itself has ad-blocking built-in, which won't be affected, and it's fairly capable, but promising that they'll keep compatibility with uBO is a lie, if they ever made that promise.
> For as long as we’re able (and assuming the cooperation of the extension authors), Brave will continue to support some privacy-relevant MV2 extensions—specifically AdGuard, NoScript, uBlock Origin, and uMatrix
I'm no fan of Brave, but it's nice to see that they at least somewhat acknowledge that they likely won't be able to support v2 forever. Only time will tell how long they're "able".
Dollars, current estimates ranging between 1 and 2 billion.
Firefox is currently developed with half a billion, but IMO, that is why there are only 3 browser engines left, with all the “forks” depending on the upstream.
Yep, currently brave (and others I assume) switch it on at build time, when Google removes that from chromium they may move it to their patch set, but who knows how long they’ll keep that once it starts breaking.
I've tried to understand what makes this so incredible impossible to maintain by asking people, I feels like FUD from the FF community (which I'm a part of) because it's all just wishywashy statements that it'll be impossible to maintain.
The reason all the statements are "wishywashy" is because it's impossible to say anything concrete here, we don't know what Google is planning to change in the future. But we know that Chromium is a huge, fast-moving code base, and that dynamic web request hooks require support from core parts of Chromium. If Google refactors or rewrites those core parts in a way which makes them incompatible with per-request dynamic hooks, keeping around v2 support means carrying huge patch sets against core parts of Chromium, forever. That's likely going to be a very large ongoing maintenance burden.
But Google haven't made those changes to how web requests are performed yet, so it's impossible to say how difficult it will be to add back whatever functionality is necessary to add back dynamic web request hooks. Maybe it'll turn out to be relatively easy, and maybe Google will leave that part of Chromium relatively unchanged for a long time. Only time will tell.
The best thing for Brave to do would just be to build it into their own ad blocker because Google is going to intentionally make it more and more impractical to support older extensions that interfere with their business model.
Brave and Vivaldi will continue to support it for some time. Brave also does not really depend on MV2 as they have their own adblocker (which is about as effective as uBO, I believe).
Original comment: Brave's built in blocker is OK for what it does but I believe that it only replaces a subset of all uBO's features. For example I don't think that Brave's built in blocker has an element picker that lets you create cosmetic filters on the fly. I use that feature all the time in uBO.
You're right, I just found the option on desktop in the right-click context menu. According to some posts I've just found in the community forums, the feature was launched years ago but for some reason I had never noticed it even though Brave used to be my default browser until recently
In case it helps, at least on desktop browsers, there is a toggle switch to disable autoplay.
I agree about shorts. I’ve repeatedly “removed” them by clicking “less like this” under the ellipsis next to the Shorts heading, but they keep coming back. I’ve also submitted UX feedback about this customer hostile (I pay for YouTube premium) pattern. It’s frustrating when features like this are force fed to you.
I wish HN had automated TLDRs or allowed a TLDR bot. One of the main reasons I view the HN comments is to get the article's meta in addition to insightful discussion.
https://finntegrate.org
My co-founders and I are building an AI assistant that helps immigrants navigate Finnish bureaucracy. As immigrants, we've experienced firsthand how fragmented and inaccessible essential information can be, scattered across Migri, Kela, the tax office, and municipal websites, often only in Finnish and Swedish.
We're using RAG (Retrieval Augmented Generation) to create a multilingual chat interface that connects people to official resources rather than replacing them. The system reduces "failure demand" - support requests that arise because people can't achieve their goals through existing resources.
The technical approach is a multi-agent system in which specialized AI agents handle different domains (immigration law, employment, housing, healthcare, etc.). We've named the agents after Finnish mythological figures (such as Tapio, Ilmarinen, and Sampo) to create a cultural connection while providing practical assistance.
Interestingly, this addresses a systematic problem - government agencies spend significant resources on repetitive support that could be automated. At the same time, immigrants get frustrated trying to piece together information from multiple sources.
We're exploring B2B opportunities (companies relocating employees, municipalities, healthcare systems recruiting internationally) and EU funding for integration technology.
Happy to share more details or get feedback from anyone who's worked on similar multilingual AI systems or government-facing tools.
GitHub: https://github.com/finntegrate/tapio