[socketcluster]

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.

[WolfOliver]

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

[socketcluster]

It supports attribute-based access control (similar to RLS but more granular) and also Group-based access control for more advanced situations.

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