Use case or problem
Requiring Obsidian plugins which desire to be on the official plugin list and downloadable directly through Obsidian to use GitHub for hosting introduces some issues including:
- Questions of ethics when it comes to GitHub’s use of code which is not released under a permissive license being used in copilot unattributed.
- The fact that GitHub outages are remarkably common for such a popular and critical tool. During such an outage, no plugins can be downloaded.
- Plugin developers are at the whim of GitHub’s pricing model and privacy policy (something many of us who use Obsidian because of its “you own your data” model object to).
Proposed solution
It would be nice to have flexibility about the way plugins are hosted including using other Git providers such as GitLab, Gitea, Azure Repos, etc. Here are links to some of the relevant APIs:
While integrating with each service individually would probably result in the most well performing solution, I realize that integrating with each of these services would require a non-trivial amount of work. One possible easier solution would be to less closely tie plugin releases to GitHub’s feature of “releases”, and rather tie it to the tags themselves, requiring the main.js and related files to be committed to the repo itself. With such a solution, a plugin repository could be identified by a clone URL for the sake of the community plugins list, and this would allow any method of hosting a git repository to be supported with less special casing in the code.
Alternatively, this could also be handled by allowing plugin developers to specify the specific URL where their plugin’s release can be fetched from, possibly even from within the manifest.json file. i.e. manifest.json file would have fields for where the main.js and styles.css files can be downloaded from, while the community plugins list would specify where the manifest.json file can be found.