我想拥有我的应用程序使用的数据库

我拼凑这篇帖子是为了从我的脑海中想出一个主意。我不认为我有关系，也没有必要的资金来推动这个想法在世界上的广泛采用，但我认为，如果让更有能力的人来指导，它会带来一些相当酷的东西。所以就是这样了。

我几乎无法控制应用程序为我存储的数据。我说的是应用程序明确宣传自己需要的数据：比如我在健身应用中记录的锻炼数据，或者我放在待办事项应用中的待办事项，或者我在Twitter上发布的推文。

我可以访问这些数据的唯一方式是通过存储这些数据的特定应用程序，而且我只能做产品设计师事先想好要包括的事情。一般来说，我不能对我的数据做任何应用程序不明确允许的事情，应用程序通常也不会明确允许太多。

为什么应用程序不能提供更多功能呢？因为每个功能都需要开发人员来实现，而开发人员的时间又有限又昂贵。如果只是我(或一些少数人)想要的话，实现一些我想要的随机可视化是不划算的。

我希望能够随心所欲地查询我的数据，并且希望跨应用程序关联数据。例如，我希望能够回答我的锻炼和饮食习惯(在各自的应用程序中记录)如何影响我的睡眠(在第三个单独的应用程序中跟踪)？今天我无法定量回答这个问题，即使我有关于所有这些事情的详细数据，因为这些数据将在不同的应用程序之间分配，这些应用程序之间不会相互交谈。

我不仅希望能够在不同的应用程序之间关联数据，我还希望其他一些应用程序能帮我做到这一点。为什么我不能让图表网站访问我的健身数据、饮食数据和睡眠数据？因为保存这些数据的应用程序不会公开API。他们没有时间和金钱花在这上面。换句话说，我希望能够注册应用程序，将我已经使用的应用程序的功能合并并扩展到比现在更大的程度。

导出是应用程序开发人员必须花费时间的一项功能，而大多数人都没有做到这一点。

但让我们假设世界上每一款应用程序都有导出功能。然后我就可以下载我所有的数据了，但是它们可能都是不同格式的。做任何有成效的事情都需要一些数据争论。如果我想要所有数据的最新更新，我必须再次导出所有数据，并再次为数据争论不休。

如果我要与其他应用共享导出的数据，该怎么办？我想我必须将其导出，然后上传到第三方应用程序，但这一步并不一定要存在。同样，如果我想让第三方拥有最新的数据，我需要定期导出和上传。

比数据导出好一个档次的是合适的API。API非常棒。它们允许以编程方式访问应用程序的数据，这听起来正是我想要的，对吗？嗯，大部分时间，是的，但不是全部。

在大多数情况下，API只是访问应用程序内部数据的一层：这一层需要花费时间和金钱来构建，并且不会比直接访问数据增加价值。正因为如此，API并不能满足我想要的一切。此外，API还有我之前提到的问题，那就是应用程序开发人员是你能做什么的把关人：如果我想分析我所有锻炼的持续时间，但API没有返回那部分数据，那么我就会解决问题。

蒂姆·伯纳斯·李(Tim Berners Lee)坚定不移地试图解决我试图描述的问题，其方式与我即将提出的非常相似。Solid为用户数据提供了一个归宿，也充当了一种身份验证方法。固态Pod可以由不同的提供商托管，也可以由自己托管。

Solid的不足之处在于它缺乏实用主义。它的技术与开发人员已经知道的太不一样了，因此在获得开发人员采用方面会有问题，这是获得其他任何人支持的先决条件。开发人员甚至需要先熟悉关联数据词汇表，然后才能创建应用程序，这意味着99%的利润驱动型应用程序都不能采用Solid，这一事实意味着，Solid成本太高，无法应用于99%的利润驱动型应用程序。既然您已经知道如何使用Postgres，为什么还要学习存储数据的新方法呢？

因此，虽然我与Solid项目的目标和意图保持一致，但我个人认为，我们需要一个对所有没有时间学习全新技术的开发人员和公司都有效的解决方案。

https://beepb00p.xyz的作者详细讨论了我正在描述的问题，甚至制作了一个有趣的工具来帮助解决这个问题。该工具使应用程序数据的编程变得容易得多，我认为这是朝着正确方向迈出的非常务实的一步，但它仍然依赖于API的存在和应用程序的导出功能(据我所知)。

我认为乌尔比特也试图解决这个问题，但我对这个项目不太熟悉。不过，据我所知，他们似乎想要重新发明他们在解决问题时遇到的每一个轮子。换句话说，如果Solid看起来不够务实，那么Urbit似乎甚至不想务实。

这并不是一个新问题，所以可能有更多的项目试图以某种我不知道的方式来解决这个问题。

我们如何才能使应用程序之间的数据所有权和共享成为默认设置？以一种易于开发人员采用和用户理解的方式？

我认为描述这个想法的最好方式是通过几个用户场景。还有很多细节需要解决，但希望这能传达出事情的本质。

我将引用我将呼叫MyData；的服务。您可以将其视为组合身份验证提供程序和数据库提供程序。通过数据库提供程序，我的意思是它将封装许多流行的数据库技术中的任何一种。它可以提供Postgres、MySQL、Mongo、Cassandra等。其他应用程序将在这些数据库中存储用户数据。

虽然我会将MyData称为一项服务，但实际上这项服务的提供商可能很多。

我还想说出我虚构的用户的名字，所以我避开了化名，选择了第一个出现的名字。

罗纳德点击按钮，从他们的MyData账户中看到一个OAuth屏幕。请求的权限将包括以下内容：

现在，Ronald有了一个由MyData托管的新Postgres数据库，他可以完全访问该数据库。Ronald可以针对它编写SQL查询，或者导出它，或者授权其他应用程序访问它。第二个场景描述了这一点。

罗纳德点击按钮，从他们的MyData账户中看到一个OAuth屏幕。请求的权限将包括以下内容：

MyData提供了带有postgres用户和url的SweetFitnessGraphing，以便它可以读取CoolFitnessTracking数据。

在上述场景中，MyData封装了Ronald的所有数据库并授权访问它们。这有效地消除了对API的需要，因为用户和应用程序将可以直接访问其他应用程序数据库。这样做的结果是数据库模式是"；API"；。这确实将责任推给了应用程序开发人员，以确保他们与代码访问的其他应用程序的架构保持一致。

现在，对每个用户使用不同的数据库连接绝对不是一个微不足道的建议。不仅如此，需要存储用户不应该访问的数据的应用程序也需要一个集中的数据库来存储这些数据。我仍然认为这比像Solid这样的东西更务实，因为它只是一个软件工程问题，使用的是众所周知的技术，而不是学习、缺乏社区和年轻的技术问题。

不幸的是，这不是一个纯粹的技术问题，所以我们需要考虑的不仅仅是技术本身。以下是一些需要考虑的事情：

Solid做这件事是完全正确的。mydata需要实施一项标准，并且有竞争对手也实施该标准。否则，如果只有一个提供商，我们就会将所有数据的权力整合到一个实体中。

这也将给用户提供选择，并防止它变成另一个有围墙的花园。实现这一点的最好方法是使应用程序与MyData交互的协议成为一个开放标准。然后创建一个易于运行的开源参考实现。

这很简单。要将数据库生态系统引导为API，我们需要一个让人们创建帐户并开始使用该技术的理由。这需要通过提供只能通过这个系统提供的价值来实现，这就是为什么它不能只是一个杀手级的应用，而是一个杀手级的应用组合。应用程序的杀手级组合将通过MyData标准进行互操作，并以传统软件架构难以匹敌的方式共同提供价值。

我不知道这里最好的路是什么。以下是关于资金流的几个选择：

在互联网上，我们不指望用户为许多服务(直接)付费，这既令人惊叹又令人瞠目结舌。在围绕MyData&34；设计货币化方案时，我们需要牢记这一点。我们生活在一个资本主义世界，因此这些数据库的主机提供商(MyDatas)需要以某种方式赚钱。

但是如果我们不能向用户收费，我们该向谁收费呢？连接到MyData服务的应用程序必须支付基于使用量的费用，这取决于它们从该服务读取/写入的数据量。我们都习惯了AWS和其他云服务的这种定价模式。

也许MyData提供商可以直接向用户收取一小笔费用，然后通过向应用程序收取较低的费用而逍遥法外。然后，应用程序可以将节省的费用传递给用户。如果用户通过MyData使用大量付费服务，这甚至可能会让他们变得更便宜。

在这种情况下，用户将向MyData支付基于使用情况的订阅费，对于他们连接的每个应用程序，该费用都会增加。然后，mydata会将部分资金转发给用户连接的每个应用程序。

例如，MyData的基本费率可能是每月5美元。然后，注册CoolFitnessTracking将把MyData的费用提高到每月10美元，但其中约5美元将流向CoolFitnessTracking。

需要激励应用程序使用MyData，而不仅仅是保持一个集中化的数据库。换句话说，对于营利性公司来说，采用这项技术需要在财务上有意义。

我们也许可以安排它，让MyData提供商负责大多数安全和GDPR类型合规性，这是小应用程序可能会喜欢的。

更广泛地说，如果我们能够达到围绕共享数据库构建的应用生态系统的临界质量，那么应用之间的互操作性的好处将有望显现。例如，如果其他人能够构建为CoolFitnessTracking服务添加功能的应用程序，这将使CoolFitnessTracking对客户更有价值。我们可以将其作为应用程序的自动插件/附加生态系统进行营销-不需要额外的工作。

这个话题最近似乎很流行。这篇帖子是我试图提出一种方法来解决这个问题，而不是发明任何太激进的新东西。然而，这一领域最大的问题似乎是推动业务采用，而不是发明技术解决方案。