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.
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?
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.
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.
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?
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.