SIM-based solutions on their way out is a non-issue. For eSIM to support that use case, political will only is needed: the EU got Apple to abandon the lightning cable, this is not any different.

Instead they could have mandated the use of eIDAS 1 to all countries + extend it with attribute/credential support, and let countries choose their implementation (cards, SIM, server-side).

Instead we’re back to the drawing board with the big shortcomings highlighted in this thread.

Especially considering that mobile-ID has been around since 2007.

I built SimplePDF 7 years ago, with the vision from day one to help get rid of bureaucracy (I'm from France, I know what I'm talking about)

Fast forward to this week where I finally released something I had on my mind for a long time: a repository of the main US forms that are ready to be filled, straight from the browser, as opposed to having to find a PDF tool online (or local).

I focused on healthcare, ED, HR, Legal and IRS/Tax for now.

On the tech-side, it's SimplePDF all the way down: client-side processing (the data / documents stay in your browser).

I hope you find the resource useful!

NiP

Comments URL: https://news.ycombinator.com/item?id=47051156

Points: 13

# Comments: 0

Then came mobile phones with their small screens and touch control which forced the web to adapt: responsive design.

Now it’s the turn of agents that need to see and interact with websites.

Sure you could keep on feeding them html/js and have them write logic to interact with the page, just like you can open a website in desktop mode and still navigate it: but it’s clunky.

Don’t stop at the name “MCP” that is debased: it’s much bigger than that

Want to do that with web technologies? You’ll need a browser AND a server or build an app using electron or tauri.

I know this is self-deprecating humor, but you do NOT have a smol brain: MCP servers are not as needed anymore now that Claude Code supports "Skills". They are also very token hungry as their spec is not lazy-loaded like the skills.

It was / and still is very useful if you collaborate with other engineers or want to perform operations in a non-stochastic fashion.

MCP servers are a way to expose a set of APIs (openAPI spec) to an LLM to perform the listed operations in a deterministic fashion (including adding some auditing, logging, etc). LLMs are fine-tuned for tool calling, so they do it really well and consistently.

Examples:

- Documentation / Glossary: MCP server that runs somewhere that reads a specific MD file or database that is periodically updated: think "what are my team members working on" / "let me look up what this means in our internal wiki".

- Gating operations behind authentication: a MCP server that is connected to your back office and allows you to upgrade a customer's plan, list existing customers, surface current. Super useful if you're a solo-founder for example.

Yet you omit to acknowledge that the remaining 99.99999% logic written that powers Cloudflare works flawlessly.

Also, hindsight is 20/20

Last week, Joe Barrow released CommonForms [1], a set of open models for automatically detecting form fields in PDFs.

He trained two models, FFDNet-S and FFDNet-L, on a dataset of 55k documents. You can read more about his approach in the arXiv paper [2].

As someone who's been searching for reliable models to auto-detect form fields (one of the last hard problems in PDF form filling), I was seriously impressed by the quality of these models. I wanted to give them the attention and distribution they deserve, so I created a fully browser-based implementation that handles both detection and field addition.

My implementation relies on his models and onnx runtime web + some post-processing. I plan on publishing a small browser library to encapsulate it in the coming days to make it easier to deploy anywhere (currently you'd have to fork / copy my code)

Happy to answer any questions about the browser-based implementation!

Questions about the models themselves should be directed to Joe, who I believe is also on HN [3]

[1] https://github.com/jbarrow/commonforms [2] https://arxiv.org/abs/2509.16506 [3] https://news.ycombinator.com/user?id=jbarrow

Comments URL: https://news.ycombinator.com/item?id=45635530

Points: 26

# Comments: 3

Additionally, keep in mind that controversial laws or proposals, at least in France, are often announced or passed during summer vacation when people are away, limiting scrutiny and attention.

Expect to hear more outrage come September

I'm all in with Postgres, but the job isolation + built-in dashboard seem really appealing. I'll definitely give it a try!

Keep up the great work, love to see such high quality codebase / documentation / tooling!

If you have heard of pg-boss [1], how does sidequest compare to it? I’m about to embark on some « jobification » on some flows and I’d love to have your opinion (possibly biased, but still)!

[1] https://github.com/timgit/pg-boss

Two times a week, the weekly standup is extended by an hour, from 15min to 1h15.

People are welcome to jump in and out of that open zoom that acts as a water cooler corner: any topic goes, from work to personal hobbies, etc

We’re fully remote (US / EMEA / APAC)

From another fellow « pdf’er »

My point is about the need for a spec of this mechanism: without a spec, every company / org will roll out their own and result in 500 flavors of the same concept.

That’s where MCP shines: tool calling and tool discovery is already 1.5 years old (an eternity in ai land).

The MCP spec ensures that we can all focus on solving problems with tool calling rather than wasting time in cobbling together services that re not interoperable (because developed without a common spec / standard)

Many come to HN also for the comments

Excellent write-up and understanding of the current state of MCP

I’ve been waiting for someone to point it out. This is in my opinion the biggest limitation of the current spec.

What is needed is a tool invocation context that is provided at tool invocation time.

Such tool invocation context allows passing information that would allow authorizing, authentication but also tracing the original “requester”: think of it as “tool invoked on behalf of user identity”

This of course implies an upstream authnz that feeds these details and more.

If you’re interested in this topic, my email is in my bio: I’m of the architect of our multi-tenant tool calling implementation that we’ve been running in production for the past year with enterprise customers where authnz and auditability are key requirements.

We're building an enterprise platform to develop, deploy, and run AI agents at scale — from local dev to production. Founded by ex-Hortonworks, Docker, and Cloudera folks, Sema4.ai is a well-funded startup with deep infra and OSS roots.

We're looking for a fullstack engineer to join our platform team. You'll help shape the core infrastructure that powers agent-based workflows for enterprises.

Technologies we use include:

- K8s, Helm, OTel

- Node.js, React

- AWS

- Snowflake SPCS

What we're looking for:

- Strong builder mindset — pragmatic, self-driven

- Comfortable in startup environments

- Clear communicator in distributed teams

- Bonus: experience with observability / infra / developer platforms

If you're interested, reach out to ben@sema4.ai with a short intro and (ideally) your GitHub or past projects.

This is a great way to:

- Have a fail-safe / fallback in case the software does not work as intended

- Allow them to continue training the already immense dataset using real data (as opposed to synthetic data)