Forgejo / Gitea share support

I’ve been using a local forgejo repo for a wiki type of thing and wanted to be able to write content in silverbullet, so I copied @zef 's Github share library and got it working with Forgejo (and probably also Gitea but I don’t have one to test) to install with the library manager.

New library is at silverbullet-libraries/Forgejo.md at master · justyns/silverbullet-libraries · GitHub and available in my library repository.

It allows you to read/write to git repos stored on forgejo / gitea servers, and has a few extra features:

  • fetches list of directories from the repo and puts t hem in the picker to choose from
  • adds a forgejo.shareTo lua helper that lets you more quickly share a note to a specific repo
  • saves recent list of repos shared to
2 Likes

This is great. And exactly what I was planning to do, as I’m getting a bit worried about how long GitHub will remain the best place for open source: Post by Zef Hemel, @[email protected]

Maybe I can integrate at the minimum parts into the Std library?

Glad to see you were already planning on it! I could probably rant about github, but I think my worries would probably be similar :smiley:

I do think github will be around for a while just due to the size of community it offers. Forgejo with ActivityPub support will hopefully help when that becomes a thing.

Maybe I can integrate at the minimum parts into the Std library?

You’re more than welcome to. A few things I left out for now:

  • no http/https uri detection. With github, you can look for github.com. With forgejo, I’m not sure if there’s an easy way to detect if a hostname is a forgejo server without maintaining a manual list.
  • forgejo doesn’t have an equivalent of gists
  • no support for releases like ghr:, maybe fjr:?
  • the shareTo helper is forgejo specific, but I’d like to support any share providers

The model I’d like to move to is to rely less on URI prefixes (like gh: and forgejo:) and more on URLs. I think this is nicer, and also opens up the ability to e.g. replace internal wiki-links with proper external URLs when sharing content that has links to other shared content. One page may be on a github gist, another in a mastodon post, yet another a Codeberg repo file. If all of them set a linkable share.uri we can ad-hoc replace those during share. Which I think would be great!

The obvious problem is that many (especially self hosted) solutions have indeed the problem you describe: you cannot really tell from the URL what you’re dealing with, is it a Forgejo instance, a mastodon instance, gotosocial instance, Ghost blog? I don’t really have an ultimate solution for this, but what I’m thinking about now, is to simply let share providers configure URL patterns. Implicitly you already do this in yours, if you configure a token for forgejo.example.com you can assume that http://forgejo.example.com/* URIs are forgejo instances. I think we can do the same for Ghost, Mastodon accounts etc.

Thoughts?

That model would be pretty great. I like using SB to write stuff in first, so ultimately having bi-directional (eventually) syncing with a bunch of different services would be super useful imo.

The problem with url patterns is mostly for read-only usecases. With Forgejo, you can pretty much guarantee we’ll have a list of hosts that you push to because we need to save a token for each host. But if you want to install a library or something from someone’s self-hosted forgejo, you probably don’t have (or want) a token for their domain.

Same for fediverse instances, if you do any writing, you’ll have to provide a url + auth of some sort.

Thinking about it though, it’s probably not that big of an issue. Each share provider could register a list of url patterns or respond to an event, and then if none of them match - just prompt the user with a list of share providers to pick from.

1 Like