31–36 of 36 posts
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.
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?
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).
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…
Earlier quoted context omitted.
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…
Inrupt, TBL's company, is doing SOLID for enterprise customers.
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% ...
Earlier quoted context omitted.
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…
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…
Earlier quoted context omitted.
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…
I don’t get it. Why did you title your hn submission after a feature that doesn’t exist? Why not use that space to say something that your thing actually does? It’d save everyone a lot of confusion.