Have you looked at the W3C's SOLID standard? I haven't looked deeply into what you're doing, but it sounds like a less interoperable version of what SOLID already does. https://solidproject.org/TR/protocol
Yes I've checked it out recently. From my understanding of the solid project it is focused on end users while linkedrecords is focused on enterprise collaboration scenarios.
Here is a small piece of text regarding this I've pulled from my notes:
Both the Solid project and LR share a foundational vision: decoupling data storage from software vendors and enabling interoperability across applications. In both approaches, data is stored in a vendor-independent backend.
However, the two systems differ in their focus and technical priorities. Solid is primarily concerned with personal data sovereignty. It empowers individual users to host their own “data pods” and control access on a per-resource basis using access control lists. In contrast, the LR architecture is tailored to enterprise-level SaaS scenarios, where data collaboration across roles and teams is essential. It supports fine-grained, logic-based access control policies embedded directly in a triplestore backend, enabling rich authorization scenarios without requiring domain-specific backend logic.
Solid prioritizes decentralized identity and personal agency, aiming to let users choose where their data is hosted and who can access it—typically across diverse web applications. LR, on the other hand, assumes a centralized or semi-centralized backend under customer control (e.g., an organization’s IT department or a trusted third party), while still preserving vendor independence.
LR provides a flexible API that enables single-page applications (SPAs) to dynamically query all resources a user has access to, based on the authorization logic encoded in the triplestore. In contrast, the Solid project addresses this challenge through the use of typed indexes—explicit data records maintained by each application to list identifiers (URLs) of resources relevant to the user. While this mechanism enables some level of resource discovery, it introduces overhead: applications must create, update, and sync these index records manually. This approach becomes particularly cumbersome in multi-user scenarios where different users have access to different subsets of resources.
I've been working on a similar product. Started working on it 14 years ago and pivoted it to vibe coding. https://saasufy.com/
I'm thinking to open source it but I want to see some traction before doing that since I don't want to open source then someone else takes my code and I get nothing out of it.
It supports attribute-based access control (similar to RLS but more granular) and also Group-based access control for more advanced situations.
Authorization is enforced based on CRUD rules that are defined on the control panel on each Model. For Create, Read, Update or Delete actions, the permission can be either "block" (don't allow anyone to perform this action), "restrict" (only allow if the user has a token which matches the resource) or "allow" (anyone can perform this action on the resource without authentication).
Permissions are enforced at the Collection and row/record level by default but can be overridden on a per-field basis so you could, for example, have a record which could be read by anyone but only the owner can edit a specific field. You could also make it so that a specific set of users is allowed to read a resource but only one of them (or perhaps a third one) is allowed to edit.
When the user authenticates themselves, they are issued a signed JWT token.
From the control panel, you just need to specify which property of the JWT to match against which field of the model; it can be the same for all CRUD actions or different for each one. The token contains an accountId property. You just need to select the corresponding field on the model and the backend middleware will match both values to decide whether or not the 'restrict' condition is met. If the accountId in the token does not match the one on a resource, then the user will be blocked. In 'restrict' mode, if fetching a list based on a filtered view, the user will be blocked if the list/page contains a resource which does not match their accountId from their JWT. The views can be parameterized with an accountId field from the client when applying an indexed filter so you can easily define views which meet the restrict criteria for any given user.
You don't really need to know any of this though because you can just ask your AI to define these rules for you and you can ask it to run tests as it can call all the CRUD actions with HTTP and you can make your AI agent impersonate any accountId you want by associating it with the API credential of your AI agent via the control panel.
You can also enforce group-based access control for handling large dynamic groups but the default attribute-based access control is quite versatile and you can optionally have multiple owners on a resource with comma-separated accountIds but you have to update the resources individually. It's good for simple sharing scenarios where one user wants to transfer ownership of a resource to another user. They could add a second owner and then the second owner could later remove the first owner to gain exclusive ownership.
This approach is also useful for simple private chat scenarios where two users are allowed to read a private message but only the sender is allowed to edit it. You can have different properties on the Model to enforce access for read vs update... For example a field readerAccountIds (Read) and senderAccountId (Update).
This is especially interesting for API products. The tricky part is not just where user data lives, but where logs, traces, backups, and billing metadata live too.
Anything that explores triple stores in production more is interesting to me, nice one!
That said, the load test immediately stuck out to me as being too small scale. Triple stores can have performance issues, and the amount of operations in the load test isn't enough to exhaust a single node, let alone a multi-node setup. If you're looking to make a more convincing case I'd benchmark where one node falls over and get some sense of the ability to horizontally scale.
That is true. The load test is now at a scale which supports the app I'm running with it.
I also know that the bottleneck is the triblestore which is currently a simple postgresql table with three columns (to put it simply). Now the system has to check in with the triplestore for each operation to find out if the operation is authorized. I'm thinking that it might be possible to replace this kind of auth check with a Zanzibar based system.
Sounds cool, but you never got around to explaining how “users control where their data is stored “, which is odd because that’s the title of your post.
So if I’m a user of an app built with your thing, how do I go about controlling where my data is stored? What’s the experience like for the end user to set this up and connect it to an app?
Thank you for pointing it out. Maybe the website does a better job in this then the GitHub repo: https://linkedrecords.com/
But even on the website I guess it could be explained a little bit better.
the first question is where is the "user". It could be the end user like you and me who want's to use some app (e.g. calorie tracker). Or it could be a company subscribing to a SaaS. In this case the user would not be the end user but the company.
The later is the more interesting use case in my opinion. Now the user/company can subscribe to a linkedrecord based SaaS and let it point to a linkedrecord backend this company trusts. the company itself does not need to operate neither the SaaS app (which is a simple SPA) nor the backend.
One interesting open question now is: It is easy to say how the backend provider would bill the company for its services. It is harder for the app provider (the SPA) to bill their services?
Yeah, you definitely should have linked to that instead of a Github repo (or copied the text across to the repo readme).
The copy is still pretty focused on the Developer experience building something that uses your thing. But I can't imagine anybody choosing to use this for a product until they know for sure that the end-user experience is painless and frictionless.
I'm actually in the market for something like this. I'm building a game that could benefit from letting people store their savegames in the cloud, but I don't see any particular reason for it to be _my_ cloud. I'd rather not store user/pass information or data at my end, and I'm sure players aren't interested in making an account on my site just to play the game.
If there was something like this that was sufficiently frictionless (on the order of magnitude of going through a "Log in with Google" flow) to set up, I'd be keen to give it a shot. But if there was anything user facing that felt "Open Source", that would kill the idea dead.
the login flow is quite straight forward and much of the expirience depends on the OpenID connect provider the backend is trusting.
You can go to https://monsterwriter.com/ and see the system in action. When you click on login you will be redirected to a login provider, which in case of MonsterWriter is auth0. But it could also be an open source (e.g. KeyCloak) or any other commercial OIDC provider. Then it is up to the OIDC provider to display the "login with Google"
The hello world example on the website provides a dummy OIDC provider, If you try out the hello world example I guess this is the best place to really get an idea: https://linkedrecords.com/getting-started/
I tried your monsterwriter site (nice looking app, by the way), and logged in with google. I don't see any option to "control where my data is stored". As far as I can tell as an end user, I've just created an account on your site.
Reading the Getting Started code, it only shows me configuring storage as a developer. Nothing about users doing any sort of bring-your-own storage, let alone firing one up from scratch with a friendly workflow.
The initial idea for linkedrecords was: I never want to write backend code and I want to build real time collaboration app. The realization that this way the user can choose its own backend came later. The idea never made it into MonsterWriter. But it would be very simple to add.
So the current implementation of MonsterWriter just hard codes the linkedrecords backend instead of prompting the user to pick one.
But also the first scenario is possible where the user is and end user. The App provider could allow to let the user pick the backend. So when the user opens the app in the browser, he will be asked to select a preconfigured backend or specify a custom linkedrecords backend URL. Once the user made this choice the app will trigger a login flow at the choosen linkedrecords backend and the app will send all request to this backend.
I had a similar idea but with a much lower-brained approach of security through purely uuid uniqueness (to some degree, similar to the initial writer controlling access), and without any actual constructs built into it:
Have you considered adding an llms.txt for linkedrecords? I'd love to be able to just tell my agent to build something and point it at your llms.txt and have it just build it out on its own reliably without having to clone the repo, go through the docs, etc.
This reminds me of the sister project of linkedrecords. It is called DJAPI. And API for Data and Jobs.
It was a public API without authentication. Everybody could upload a blob and received an access and encryption key which the client can use to access this particular object. The the client could also trigger a job using the data and producting an outcome. The outcome could then be downloaded and decrypted by the client with the keys.
While linkedrecords is the BaaS part of serverless DJAPI was the FaaS part of it. I've used DJAPI to upload LaTeX files and create a PDF out of it. The actual plan is to merge those projects at some point.
This sounds cool, but how do you protect your product from pirating?
If your entire product is turned into a frontend app, and all of the infrastructure is stored on the users backend, doesn't this effectively mean they can just use your service for free?
And if you try and gate it in the frontend, obviously that can just be stripped out with an LLM in 3 seconds.
Am I missing something?
Also curious about how payments would work in a system like this.
That is a very good observation.
see a comment below:
> One interesting open question now is: It is easy to say how the backend provider would bill the company for its services. It is harder for the app provider (the SPA) to bill their services.
Maybe this aligns with the current direction we are moving with AI. The frontend app itself becomes more and more worthless and in the future every frontend is custom made. linkedrecords makes this very possible especially if you combine it with some form of upper ontologies where apps can collaborate on the same data.
Maybe it is not as big of a problem as pirating the app would be against the companies SLA and serious businesses who pay the most money would just not do it.
It's a very interesting idea. You've given me food for thought. Maybe the payment model becomes purchasing access to the frontend, instead. But then you're back to square one with traditional infrastructure to accomplish the gating. It could be lighter weight though.
I'm curious about the encryption side as well. Still reading through your docs.
I'm also a little skeptical on the claim of it making things simpler. It kind of feels like it just moves the responsibility. Instead of developing infrastructure/backend and communication with it, you instead have to accomplish most of that on the frontend instead? Maybe it does simplify things in the end but my intuition is telling me that you'll end up with an equal amount of different types of complexity.
... You could also sell a desktop app instead of a SaaS app. And then the desktop app connects to linkedrecords server. This model a few advantages:
- You can do the purchasing in the app (.e.g traditional license keys)
- The user is not affected if your business closes. He still has the desktop app running locally and can use any linkedrecords server.
Here is a small piece of text regarding this I've pulled from my notes:
Both the Solid project and LR share a foundational vision: decoupling data storage from software vendors and enabling interoperability across applications. In both approaches, data is stored in a vendor-independent backend.
However, the two systems differ in their focus and technical priorities. Solid is primarily concerned with personal data sovereignty. It empowers individual users to host their own “data pods” and control access on a per-resource basis using access control lists. In contrast, the LR architecture is tailored to enterprise-level SaaS scenarios, where data collaboration across roles and teams is essential. It supports fine-grained, logic-based access control policies embedded directly in a triplestore backend, enabling rich authorization scenarios without requiring domain-specific backend logic.
Solid prioritizes decentralized identity and personal agency, aiming to let users choose where their data is hosted and who can access it—typically across diverse web applications. LR, on the other hand, assumes a centralized or semi-centralized backend under customer control (e.g., an organization’s IT department or a trusted third party), while still preserving vendor independence.
LR provides a flexible API that enables single-page applications (SPAs) to dynamically query all resources a user has access to, based on the authorization logic encoded in the triplestore. In contrast, the Solid project addresses this challenge through the use of typed indexes—explicit data records maintained by each application to list identifiers (URLs) of resources relevant to the user. While this mechanism enables some level of resource discovery, it introduces overhead: applications must create, update, and sync these index records manually. This approach becomes particularly cumbersome in multi-user scenarios where different users have access to different subsets of resources.
I'm thinking to open source it but I want to see some traction before doing that since I don't want to open source then someone else takes my code and I get nothing out of it.
Authorization is enforced based on CRUD rules that are defined on the control panel on each Model. For Create, Read, Update or Delete actions, the permission can be either "block" (don't allow anyone to perform this action), "restrict" (only allow if the user has a token which matches the resource) or "allow" (anyone can perform this action on the resource without authentication).
Permissions are enforced at the Collection and row/record level by default but can be overridden on a per-field basis so you could, for example, have a record which could be read by anyone but only the owner can edit a specific field. You could also make it so that a specific set of users is allowed to read a resource but only one of them (or perhaps a third one) is allowed to edit.
When the user authenticates themselves, they are issued a signed JWT token.
From the control panel, you just need to specify which property of the JWT to match against which field of the model; it can be the same for all CRUD actions or different for each one. The token contains an accountId property. You just need to select the corresponding field on the model and the backend middleware will match both values to decide whether or not the 'restrict' condition is met. If the accountId in the token does not match the one on a resource, then the user will be blocked. In 'restrict' mode, if fetching a list based on a filtered view, the user will be blocked if the list/page contains a resource which does not match their accountId from their JWT. The views can be parameterized with an accountId field from the client when applying an indexed filter so you can easily define views which meet the restrict criteria for any given user.
You don't really need to know any of this though because you can just ask your AI to define these rules for you and you can ask it to run tests as it can call all the CRUD actions with HTTP and you can make your AI agent impersonate any accountId you want by associating it with the API credential of your AI agent via the control panel.
You can also enforce group-based access control for handling large dynamic groups but the default attribute-based access control is quite versatile and you can optionally have multiple owners on a resource with comma-separated accountIds but you have to update the resources individually. It's good for simple sharing scenarios where one user wants to transfer ownership of a resource to another user. They could add a second owner and then the second owner could later remove the first owner to gain exclusive ownership.
This approach is also useful for simple private chat scenarios where two users are allowed to read a private message but only the sender is allowed to edit it. You can have different properties on the Model to enforce access for read vs update... For example a field readerAccountIds (Read) and senderAccountId (Update).
That said, the load test immediately stuck out to me as being too small scale. Triple stores can have performance issues, and the amount of operations in the load test isn't enough to exhaust a single node, let alone a multi-node setup. If you're looking to make a more convincing case I'd benchmark where one node falls over and get some sense of the ability to horizontally scale.
I also know that the bottleneck is the triblestore which is currently a simple postgresql table with three columns (to put it simply). Now the system has to check in with the triplestore for each operation to find out if the operation is authorized. I'm thinking that it might be possible to replace this kind of auth check with a Zanzibar based system.
https://en.wikipedia.org/wiki/Google_Zanzibar
So if I’m a user of an app built with your thing, how do I go about controlling where my data is stored? What’s the experience like for the end user to set this up and connect it to an app?
But even on the website I guess it could be explained a little bit better.
the first question is where is the "user". It could be the end user like you and me who want's to use some app (e.g. calorie tracker). Or it could be a company subscribing to a SaaS. In this case the user would not be the end user but the company.
The later is the more interesting use case in my opinion. Now the user/company can subscribe to a linkedrecord based SaaS and let it point to a linkedrecord backend this company trusts. the company itself does not need to operate neither the SaaS app (which is a simple SPA) nor the backend.
One interesting open question now is: It is easy to say how the backend provider would bill the company for its services. It is harder for the app provider (the SPA) to bill their services?
The copy is still pretty focused on the Developer experience building something that uses your thing. But I can't imagine anybody choosing to use this for a product until they know for sure that the end-user experience is painless and frictionless.
I'm actually in the market for something like this. I'm building a game that could benefit from letting people store their savegames in the cloud, but I don't see any particular reason for it to be _my_ cloud. I'd rather not store user/pass information or data at my end, and I'm sure players aren't interested in making an account on my site just to play the game.
If there was something like this that was sufficiently frictionless (on the order of magnitude of going through a "Log in with Google" flow) to set up, I'd be keen to give it a shot. But if there was anything user facing that felt "Open Source", that would kill the idea dead.
Do you have an example of a user setup flow?
You can go to https://monsterwriter.com/ and see the system in action. When you click on login you will be redirected to a login provider, which in case of MonsterWriter is auth0. But it could also be an open source (e.g. KeyCloak) or any other commercial OIDC provider. Then it is up to the OIDC provider to display the "login with Google"
The hello world example on the website provides a dummy OIDC provider, If you try out the hello world example I guess this is the best place to really get an idea: https://linkedrecords.com/getting-started/
Reading the Getting Started code, it only shows me configuring storage as a developer. Nothing about users doing any sort of bring-your-own storage, let alone firing one up from scratch with a friendly workflow.
What am I missing?
The initial idea for linkedrecords was: I never want to write backend code and I want to build real time collaboration app. The realization that this way the user can choose its own backend came later. The idea never made it into MonsterWriter. But it would be very simple to add.
So the current implementation of MonsterWriter just hard codes the linkedrecords backend instead of prompting the user to pick one.
Why not use that space to say something that your thing actually does? It’d save everyone a lot of confusion.
https://github.com/matthewscholefield/blobse
Which powers a few small apps like https://matthewscholefield.github.io/votosphere/
Have you considered adding an llms.txt for linkedrecords? I'd love to be able to just tell my agent to build something and point it at your llms.txt and have it just build it out on its own reliably without having to clone the repo, go through the docs, etc.
It was a public API without authentication. Everybody could upload a blob and received an access and encryption key which the client can use to access this particular object. The the client could also trigger a job using the data and producting an outcome. The outcome could then be downloaded and decrypted by the client with the keys.
While linkedrecords is the BaaS part of serverless DJAPI was the FaaS part of it. I've used DJAPI to upload LaTeX files and create a PDF out of it. The actual plan is to merge those projects at some point.
If your entire product is turned into a frontend app, and all of the infrastructure is stored on the users backend, doesn't this effectively mean they can just use your service for free?
And if you try and gate it in the frontend, obviously that can just be stripped out with an LLM in 3 seconds.
Am I missing something?
Also curious about how payments would work in a system like this.
> One interesting open question now is: It is easy to say how the backend provider would bill the company for its services. It is harder for the app provider (the SPA) to bill their services.
Maybe it is not as big of a problem as pirating the app would be against the companies SLA and serious businesses who pay the most money would just not do it.
But yes, it is a open point.
I'm curious about the encryption side as well. Still reading through your docs.
I'm also a little skeptical on the claim of it making things simpler. It kind of feels like it just moves the responsibility. Instead of developing infrastructure/backend and communication with it, you instead have to accomplish most of that on the frontend instead? Maybe it does simplify things in the end but my intuition is telling me that you'll end up with an equal amount of different types of complexity.