I've been hacking on my own task manager on-and-off for years (https://the.do.zone). It has no database; the primary store is the browser, and you can optionally sync to local file system (if using chrome), dropbox, or google drive (less optimal for my needs, because their js oauth implementation is very conservative about token length.) It has some crude but functional diff resolution, so that you can sync across multiple machines. Browsers _could_ provide better tooling to make this kind of app architecture more convenient to write; and theoretically you could imagine cloud providers providing some kind of standard for datastores. But there's no market for it; non techies really don't care about the location of their data to any great extent.
Authorize, don't authenticate
11–20 of 49 posts
Re: Authorize, don't authenticate
#12Got 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…
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.
Re: Authorize, don't authenticate
#13Got 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…
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…
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.
Re: Authorize, don't authenticate
#14I've been hacking on my own task manager on-and-off for years ( https://the.do.zone ). It has no database; the primary store is the browser, and you can optionally sync to local file system (if using chrome), dropbox, or google drive (less optimal for my needs, because their js oauth implementation is very conservative about token length.) It has some crude but functional diff resolution, so that you can sync across…
They do care, but not at the right point in the sales cycle. They care about the eventual bait and switch. They care about how in the face of that pack of lies they can't even recover their own data in any capacity whatsoever. They just don't recognize ahead of time that data location is a critical ingredient in preventing recurring pains they definitely know and understand.
Re: Authorize, don't authenticate
#15> It’s your data! You shouldn’t have to prove to anyone else that you have the right to access it.
How does the service know who you are? That's the point of authentication. Once that question is settled, the service can decide what you are authorized to do. You need both.
Re: Authorize, don't authenticate
#16If people manage their own data, that essentially means each person has their own database. And a database has to be connected to an application. Whenever the database schema changes, the application's CRUD operations have to be updated as well.
In the end, it seems likely that everyone will develop and maintain their own web application, and if others need access to their data, they'll expose it through APIs.
Re: Authorize, don't authenticate
#17I feel like this blends two discrete things
1. Can I have access to my data (the side effects of my interaction with an application) in a portable way?
2. Can I stop or prevent others (like the application author) from having access to my data?
I wonder which -- if users had to choose -- they care more about? I think for most uses its #1 unless its very personal data, in which its #2. I love the idea as presented in this article but I'm not so sure how practical it is. I don't know how much overlap there is between "author has to run application a central server" (can't just be a local app) and "author must not retain data".
Seems like a really awkward space to inhabit.
Re: Authorize, don't authenticate
#18Got 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…
(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!
Re: Authorize, don't authenticate
#19I feel like this blends two discrete things 1. Can I have access to my data (the side effects of my interaction with an application) in a portable way? 2. Can I stop or prevent others (like the application author) from having access to my data? I wonder which -- if users had to choose -- they care more about? I think for most uses its #1 unless its very personal data, in which its #2. I love the idea as presented in…
(Author here)
Hello there! I agree users may want one or both of these features in their interaction with an application, and that their preferences likely vary depending on the type of data we're considering. The way I'm reading what you're saying, there's some sort of tension or tradeoff between the two features that I don't fully understand. Can you help me understand it a bit better? Thank you!
Re: Authorize, don't authenticate
#20We are back to File->Open I guess. We could use native applications instead of web apps while we're at it. Sadly this approach does not work for a lot of (web) apps.
Author here!
The solution I'm proposing does not assume the data is local to the user's machine. In the video attached to the blog post, a web application is authorized to access a database hosted by a different service/domain. While the blog post covers collaboration/social data as current limitations, I'm curious what other classes of web apps you think don't work with the proposed approach?