[sandeepkd]

Got drawn to the topic, however usage of authentication and authorization seem like misnomer here, the core topic seems to be data ownership

The concept on a surface level to have ownership over the data makes a lot of sense and to a large part the support exists in a fragmented manner across the different providers/applications.

The concrete idea of user having a database and then authorizing that to the service is highly impractical. It might be applied for experimentation purposes in highly controlled environment but cant scale beyond that.

1. Databases require maintenance, backups, failover

2. Schema update are nightmares. No one is ever comfortable with it, specially the bigger you are.

3. Authorization seems to be following one to many pattern here, one database and multiple applications. Its a no go in case of update operations

[socketcluster]

Yes, it still does authentication. It's just about hosting the data, which might make sense for niche scenarios with well defined scope. Unfortunately, many data-driven systems need some kind of data sharing. Relying on data from multiple custodians is possible and could be cool but brittle if a single view is pulling data from many custodians. Also it would be impossible to run meaningful analytics on such scattered data... I guess that could be seen as a feature.

I think this may end up happening naturally over the next decade or so thanks to AI coding. People will just stick web components bound to different data sources on the same page without even realizing it. Data can be joined and chained together on the frontend. Some shared authentication standard like JWT with asymmetric key signatures could potentially facilitate that. Multiple data custodians could verify the same JWT using the user's public key... Account could be hosted on some blockchain so it's not centralized.

[sandeepkd]

It might be helpful here to categorize the data as sensitive, personal, financial, chat, public comments as such and then apply the probability model on a given category. I would probably call the AI coding as misnomer too, what you have is a higher level of auto complete functions and natural language processing.

Theoretically even I love the idea of independence, however practicality of such a thing has to be evaluated. From all the examples that exists as of today, a true and meaningful decentralization is not viable in the absence of a a trusted centralized component.

[marcua]

(Author here)

Thank you for pushing on this. Some clarifications that might help you see this as more practical than your initial impression: * I totally agree that databases require maintenance, HA, etc. My argument is not that someone running a database magically doesn't have to do these things, but rather that the person running the database doesn't have to be the person running the app. In the video attached to the blog post, you can see that separation in action: marcua.net hosts the Todos app, but thedata.zone hosts an ayb [1] database instance. As the owner of thedata.zone, it's my responsibility to configure the database for stuff like offsite snapshot-based backups (which I've done). * Schema migrations are an application-level concern, and are no more or less challenging in the model I'm proposing. As a convenience, in the ayb.js client I open sourced, I add some utilities for forward-only migrations to make it a little easier for application developers who build around ayb to have migrations fire at the right moment in their application's lifecycle. * Authorization is definitely not assumed to be one database to many apps. In the video, look for how the user already has a streaks.sqlite database (for storing streak data) and creates a new todos.sqlite database for storing their to-dos.

Thank you for engaging on this! I look forward to hearing your thoughts!

[1] https://github.com/marcua/ayb

[sandeepkd]

For the sake of discussion lets leave the business aspect. What you are offering is a service for managed database, similar to lot of cloud providers. What you have on the top of it is a OAuth2 process to obtain relevant credentials.

From practical standpoint you have to consider that the traditional use case for databases has been N:1 (n application instances, 1 DB) and you are inverting this.

There might be some unique B2C scenario where this makes business sense, however if you are providing database service then I cannot see how this would be any different.

On a side note, there are quite a number of B2B scenario where the client provides the DB for data residency requirements and the service providers uses that DB to manage the data on behalf of the client.

The price is also a big concern, a user scope database is going to be quite costly, as a provider you would end up sharing the infrastructure

Lastly I will repeat it again, schema migrations are as much as database level concern, and migrating N databases above a certain scale is not easy.

[zobzu]

yeah the article is dumb.