WolfOliver

unfortunately the pdf itself has some typesetting issues. Whats about all those overflowing boxes and the small black boxes all over the document?

The feature does exists it is just noch used in MonsterWriter which is one application

looking at https://www.inrupt.com/customer-stories

They are enterprise customers but I see a lot of use cases where the end user is private person. From what I understand the recurring pattern is: A private person stores data and then specifies who can access this data. Mostly the amount of data records per person is quite small, so the discovery of the records is not that sophisticated.

I think where linkedrecords might be better suited are groupware apps like notion, google docs, airtable, github, where a group of people collaborate on the same large body of data records.

But I might not have understand SOLID 100% ...

maybe "animations" would be a better term

it took me a while to understand what is ment with "Motion"

That is interesting. Can you point me to some information on how the authorization works? From a user/developer perspective?

yes, good point.

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.

You don't miss anything.

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.

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

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.

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.

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/

It's true, I'm planning a serious of youtube videos showing how to code different apps with it.

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/

There is not encryption for data at rest. It might be something I look into.

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.

But yes, it is a open point.

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.

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?

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.

https://en.wikipedia.org/wiki/Google_Zanzibar

Thank you for the feedback.

It is a personal project and a byproduct of a SaaS I'm running.

This is a quite different approach so its best to keep an open mind when reading it. A little more hands on introduction can be found in the getting started guide: https://linkedrecords.com/getting-started/

Would you be less sceptical if the tutorial would use a publicly hosted instance?

You a free to inspect the yaml file which will be passed into the docker compose.

Also it is not as dramatic as it looks like as docker compose will just start containers. All the potentially malicious code will be run in containers.

for me, using go is the fancy stack

20$ vs 300$ does not really matter if you have multiple 10K MRR.

That is a valid point. This is exactly when you should use a mock.

Does this make sense? Anybody can confirm this?

Check out MonsterWriter if you are concerned about the recent acquisition of this.

It also offers LaTeX workspaces

see video: https://www.youtube.com/watch?v=feWZByHoViw

exactly, react could not deal with mutable object so they decided to make immutability seem to be something that if you did not use before you did not understood programming.