Hello HN,

I would like to share with you linkedrecords.com - an open source backend as a service I'm working on since some time now. You can think of it as an firebase/convex alternative with an interesting twist.

In 2018 I needed to write large software requirements/architecture documents in Google Docs. While I was annoyed by the limitations of Google Docs back then (no captions on figures, no automatic heading numbering, slow when docs are bigger,...) I was still fascinated by the real time collaboration features of it. So I've started a quest to understand how it works and I begun to implement an alternative to Google Docs.

I was convinced that this kind of real time collaboration is the future so I've given it much thought how I could make this as generic as possible so I could use it in all future tools I would build.

In the same time I was playing around with firebase (surprisingly you can not build a google docs alternative with firebase that easy as their real time collaboration does not provide merging text but rather just JSON). And back then I was also convinced that backend as a service is the right way to go. I was thinking that one of the most important reason we were still writing custom backend code is because of authorization.

I also was faced with another problem when trying to make the backend as generic as possible: relations between entities are also domain specific. E.g. A Documents can have many comments.

Luckily I was intrigued by another concept back in 2018 it was called web 3.0. Back in 2018 this had nothing to do with crypto. It was used as a term to refer to the semantic web and the resource description framework as one of its standards. There are also some RDF implementations which I could have reused but they are all XML and mostly Java based. I needed something light. Instead of implementing my own RDF product I took the idea of the RDF triplestore and came up with my own interpretation of it.

Using concepts like: triplestores and schema-on-read, I came up with a system that does not has any business logic in its backend and while working on my Google Docs alternative I felt in love with it as I've discovered some properties I did not anticipated from the get go:

- Dealing with global state in react is very easy. It feels like you use an SQL client in your browser and all queries are reactive and always up to date. When writing a query you do not have to think about authorization it's all backed in. - Because the backend is 100% free of domain specific code you can point your single page app to any linkedrecords deployment. - You never have to write backend code - Its quite efficient when using AI agents

The best way to experience it, is to follow this little tutorial: https://linkedrecords.com/getting-started/

It takes a while to get a hang of it so you have to have an open mind.

I would love to read your feedback on this.

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.

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.

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.

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.

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?

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.

Please explain in simple words what it is and does. Is user data stored unencrypted on your servers?