GitHub as app storage, cont'd

Open
#214 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Stale
Tech stack
git, github, node.js

Research direction

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.

Written by the indexing model from the issue text.

Description

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.

Dominant language
HTML
Stars
134
Forks
10
PR merge metrics
No merged PRs in 30d

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from scripting/Scripting-News

All issues in scripting/Scripting-News

Similar issues

More Backend & API Design issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.