1) Work towards a more advanced system that addresses the issues (for example, RDF/Turtle – expands XML namespaces to define classes and properties, represents graphs instead of being limited to trees unlike XML and JSON)
2) Throw it away and start from scratch. First, JSON. Then, JSON schema. Jq introduces a kind of "JSONPath". JSONL says hi to XML stream readers. JSONC because comments in config files are useful. And many more primitives that existed around XML were eventually reimplemented.
Note how the discussion around removing XSLT 1 support similarly has two ways forward: yank it out or support XSLT 3.
I lean towards Turtle replacing XML over JSON, and for XSLT 3 to replace XSLT 1 support in the browsers.
> And many more primitives that existed around XML were eventually reimplemented.
Don't miss that they were reimplemented properly.
Even XML schemas, the one thing you'd think they were great at, ended up seeing several different implementation beyond the original DTD-based schema definitions and beyond XSD.
Some XML things were absolute tire fires that should have been reimplemented even earlier, like XML-DSIG, SAML, SOAP, WS-everything.
It's not surprising devs ended up not liking it, there are actual issues trying to apply XML outside of its strengths. As with networking and the eventual conceit of "smart endpoints, dumb pipes" over ESBs, not all data formats are better off being "smart". Oftentimes the complexity of the business logic is better off in the application layer where you can use a real programming language.
I've been using Migadu for a low-moderate throughput inbox (within their micro tier limits) in the US and the IMAP4 performance is kinda awful sometimes. I'm not sure why :(
Ended up dropping migadu. Lots of things I liked like the configuration but it was fairly expensive for what you got. After 3 years of paying, I once went over my outbound quota and couldn't send email for the day.
How would I share Quadlet files for my repo? Today I have a docker-compose.yml in my repo, the instructions to try it out are usually `docker compose up --build -d`.
I read about the recently released CLI support for quadlets [0] and the ability to install Quadlets from a URL but still cannot wrap my head around it (as in, no matter how I look at it, Quadlets seem to require non-trivially higher knowledge to use and more steps/files).
Quadlet is only for managing containers. If you need to build images too, you need to use the "buildah" CLI tool. If you know what a systemd service file is, a quadlet is essentially just that. It's a service file that automatically handles the annoying details of creating a systemd service to start/stop your container properly.
But Quadlet needs a container image before it can create a container. The example compose file you linked includes steps for building Dockerfiles. Quadlet doesn't do that. Instead, you'll need to do it as a separate step using buildah (https://www.redhat.com/en/topics/containers/what-is-buildah)
Compose does a lot of stuff, so migrating away from it isn't always easy. In this case, you'd probably need to bring in a build system like Make or some custom scripts to build all the container images you need. Once you rebuild an image, you can restart your quadlet-managed containers with `systemctl restart my-container` and they'll automatically use the new image.
I don't do much web development these days, so I'm definitely not an authority on container-based development workflows. Maybe there are better tools out there, or maybe compose is still the best tool for that job. But quadlets are definitely the better choice when it comes to deploying/orchestrating your containers without getting into a full blown kubernetes setup.
Quadlet supports ".build" and ".image" files, and ".container"s can have an auto-update policy (supported by manually invoking `podman auto-update` or the daily timer.)
It sounds interesting, but with some caveats / things that require other tooling, maybe migrating all my services from compose to quadlets would end up a fairly lateral move.
1. Why is tracking access rights "on a per user basis or [...] along with the content" is not feasible? A few mentions: Google Zanzibar (+Ory Keto as OSS impl) - makes authz for content othoronal to apps (i.e. possible to have it in one place, s.t. both Jira and a Jira MCP server can use the same API to check authz - possible to have a 100% faithful authz logic in the MCP server), Eclipse Biscuit (as far as I understand, this is a Dassault's attempt to make JWTs on steroids by adding Datalog and attenuation to the tokens, going in the Zanzibar direction but not requiring a network call for every single check), Apache Accumulo (DBMS with a cell-level security) and others. The way I see it, the tech is there but so far, not enough attention has been put on the problem of a high-fidelity authz throughout the enterprise on a granular level.
2. What is the scale needed? Enterprises with more than 10000 employees are quite rare, many individual internal IT systems even in large companies have less than 100 regular users. At these levels of scale, a lot more approaches are feasible that would not be considered possible at Google scale (i.e. more expensive algorithms w.r.t. big-O are viable).
Because the problem is not "get a list of what user can access" but "the AI that got trained on dataset must not leak to user that doesn't have access to it.
There is no feasible way to track that during training (at least yet), so only current solution would be to learn AI agent only on data use can access and that is costly
Who said it must be done during training? Most of the enterprise data is accessed after training - RAG or MCP tool calls. I can see how the techniques I mentioned above could be applied during RAG (in vector stores adopting Apache Accumulo ideas) or in MCP servers (MCP OAuth + RFC 8693 OAuth 2.0 Token Exchange + Zanzibar/Biscuit for faithfully replicating the authz constraints of systems where the data is being retrieved from).
As I understand it, there's no real way to enforce access rights inside an LLM. If the bot has access to some data, and you have access to the bot, you can potentially trick it into coughing up the data regardless of whether you're supposed to see that info or not.
MCP tools with OAuth support + RFC 8693 OAuth 2.0 Token Exchange (aka OAuth 2.0 On-Behalf-Of flow in Azure Entra - though I don't think MCP 2025-06-18 accounts for the RFC 8693) could be used to limit the MCP bot responses to what the current user is authorized to see.
