Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- Please explain in simple words what it is and does. Is user data stored unencrypted on your servers?
- The readme in the GitHub repo contains a link to the website which I hope does a better job in explaining this: https://linkedrecords.com/by WolfOliver
- I think it would help demo an app or two that use this BaaS. Even better, if all those apps use/display the same data in different ways.by gurjeet
- It's true, I'm planning a serious of youtube videos showing how to code different apps with it.by WolfOliver
- 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.
by nullbio - 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.
by WolfOliver - 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:
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.
by _matthew_ - 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.
by WolfOliver - 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?
by jasonkester - 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?
by WolfOliver - 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.
- That is interesting. Can you point me to some information on how the authorization works? From a user/developer perspective?by WolfOliver
- 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.
by danpalmer - 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.
by WolfOliver - 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.by Avery29
- yes, good point.by WolfOliver
- 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/protocolby thraxil
- 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.
by WolfOliver