Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

GitHub as app storage, cont'd

未关闭
  • 哪里不对？
#214 1 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
25/100
Issue 类型
功能
描述清晰度
需要澄清
活跃度
停滞
技术栈
git, github, node.js
领域
api, backend, backend-api-design

调研方向

Start with the linked post and the GitHub API behavior described in the issue, then review the referenced Isomorphic-Git project. The issue names no repository files or tests; done would require a documented, validated direction for using GitHub as shared app storage, including the reported propagation concerns.

由索引模型根据 Issue 内容生成。

描述

A place to continue work on using GitHub as a storage system for a community of apps, as described in this post.

Yesterday I wrote two bits about using GitHub as a storage system for a community of apps.

That matches the as-yet unachieved ideal of using the web as an operating system, that for me goes back to 1994. It's the potential I saw when I first understood how HTTP works. Now in 2021, the one thing the web OS doesn't have is reliable storage for users that multiple apps can access to edit and render on the user's behalf. The same way you might have a text file on your desktop, that you write in a word processor (of your choosing, this is important) and send it over email, put it in a tweet, or a Facebook post, or print it. Or any of a million other uses. The key thing is the text file is yours. Not just for Mac or Windows, for everyone, anywhere. It's the wedge we need to be able to build a new world that's been technically possible for a couple of decades now. :-)

It's important that we're using GIT which is an open and often-cloned data structure. You could move your data to another GIT provider if GitHub proved too expensive, or their service was failing, or really any reason at all.

Dropbox was getting close to this idea, but they pulled back. That's why I did "Fargo", which used Dropbox for storage. But no other app could access Fargo's outline files. They couldn't even access public files, that's the feature they withdrew. They had reasons to change course, not faulting the company.

LogSeq

The main reason I picked up using GitHub as storage, again (I had experimented in 2017 with a GitHub-backed text editor) is that another app developer, "LogSeq" is going down this path: using GitHub as a place for users to store their data. Even better LogSeq is an outliner! And even better, they're supporting "OPML". So now it gets interesting. I can imagine a user opening an outline in "Drummer" because it has a feature they need, and then opening the same file in "LogSeq" because it has features that Drummer doesn't. This is the nirvana we've been waiting so long for. And we're close to having it.

GitHub is tempting, but there appear to be problems when accessed through their API, as I am doing. For example, if I saved a file to a user's repo, it might take 20 minutes before the changed version showed up to other apps. There must be a cache somewhere in there. I don't have a clear statement of how GitHub works here, maybe it's out there, but I wanted to do a reality check.

LogSeq says they use a Node package called Isomorphic-Git. It has been reliable. But there are other problems.

主要语言
HTML
星标
134
派生
10
30 天内没有已合并 PR

环境准备

这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

scripting/Scripting-News 的其他 Issue

查看 scripting/Scripting-News 的全部 Issue

相似的 Issue

更多 Backend & API Design Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。