Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

GitHub as app storage, cont'd

オープン
#214 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
25/100
issue の種類
機能追加
明瞭さ
説明が足りない
活発さ
停滞
技術スタック
git, github, node.js

調査の方向性

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
PR マージ指標
30日以内にマージされた PR はありません

コントリビューションガイド

このリポジトリのコントリビューションガイドは索引されていません

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

scripting/Scripting-News のほかの issue

scripting/Scripting-News の issue をすべて見る

似ている issue

Backend & API Design の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。