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?

▲

jasonkester 3 hours ago | parent | next [-]

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. I'm building a game that could benefit from letting people store their savegames in the cloud, but I don't see any particular reason for it to be _my_ cloud. I'd rather not store user/pass information or data at my end, and I'm sure players aren't interested in making an account on my site just to play the game.

If there was something like this that was sufficiently frictionless (on the order of magnitude of going through a "Log in with Google" flow) to set up, I'd be keen to give it a shot. But if there was anything user facing that felt "Open Source", that would kill the idea dead.

Do you have an example of a user setup flow?

▲

WolfOliver 3 hours ago | parent [-]

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/

▲

jasonkester 2 hours ago | parent [-]

I tried your monsterwriter site (nice looking app, by the way), and logged in with google. I don't see any option to "control where my data is stored". As far as I can tell as an end user, I've just created an account on your site.

Reading the Getting Started code, it only shows me configuring storage as a developer. Nothing about users doing any sort of bring-your-own storage, let alone firing one up from scratch with a friendly workflow.

What am I missing?

	▲	WolfOliver an hour ago \| parent [-]
		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.

▲

WolfOliver 3 hours ago | parent | prev [-]

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.