I know there haven’t been very many good places to host git repositories for game projects, in part due to the large sizes of games. I know some of us run our own git servers to get around the size limitations normally present on other managed hosting services.
I’m curious if people would be interested in utilizing a gitplace at git.tsuki.space that would be made available to t/suki users, with the running of the server supported by donations or dedicated assistance from the community. I could manage the server, on which I would probably run Forgejo with the LFS data sent to a Backblaze for low-cost storage[1], unless someone else better suggestions.
An initial data cap (perhaps 10 GB?) would still be implemented to prevent abuse, though I will probably adopt the same policy as Codeberg as far as this is concerned. In fast, I’m more or less interested in running a gitplace instance just like Codeberg does except for indie and hobbyist game projects instead of for FOSS.
Backblaze is the same place data is stored for t/suki, though for the gitplace I would use a different bucket. ↩︎
I like the idea, and although I’ll most likely keep using my own Forgejo server for personal projects, a tsuki one might be a welcome thing to have, should we do some game jamming or community projects, for example.
I didn’t think of game jams or community projects!
I use github for, like, work stuff or stuff I think could be portfolio pieces, but I wouldn’t use it for a second for some of the game stuff I’m planning to do. Might use a tsuki gitplace for that! And, tbh, if it’d be ok I might put some of the work/portfolio stuff there too.
However, you can’t sign in or make an account right now. I would like it so that if you have an account here, you can log into the gitplace. But, it seems like Discourse itself cannot officially be used as an OpenID provider. So, it looks like I’ll have to look into using an authentication server like Keycloak or something like that first.
After several hours of reading confusing documentation, I’m saddened to report that there doesn’t appear to be a great way to make it possible to automatically provide access to the Forgejo instance if you have a Discourse account.
I’m not terribly familiar with all of this, but there appears to be three different approaches I could try. They all have serious drawbacks:
Use Discourse as an OpenID provider. My favorite choice. In this situation, you would only have one account, and that would be your Discourse account. t/suki is focused on the community aspect, and I feel comfortable betting that Discourse will be core service that is important to its operation. Forgejo would delegate user registration to Discourse.
Unfortunately, Discourse doesn’t support being an OpenID provider officially. However, there is a way to do this with an unofficial third-party server called distrust. On the bright side, Discourse staff said that such a feature would be a desirable addition to the official Discourse client and distrust appears to still be actively maintained. However, this thread is from 2021 and it appears that Discourse has not bothered adding support for becoming an OpenID provider and I am not aware of how trustworthy the developers of distrust are.
Offload identity management from Discourse to a different service. This choice is okay. In this situation, you would have one account managed by some other identity provider (like Keycloak). Forgejo and Discourse would delegate user registration to the identity provider. Imagine logging into Google, and having access to all of the various Google services like YouTube, Google Docs, and etc without having to log in every time you visit a new service that Google provides.
However, it appears that Discourse didn’t implement a standard protocol for this. Instead, they made their own custom protocol called DiscourseConnect. DiscourseConnect is not OAuth2. This means that even if I wanted to use something like Keycloak which supports many standard protocols for managing accounts, I would need to pull in some unofficial third-party code to support DiscourseConnect like keycloak-discourse. I would also need to run another server to provide the identity service and migrate user accounts from Discourse to the identity service.
Use another service just for authentication. This choice sucks. In this situation, you have three accounts. You have one at an identity service which is used to authenticate, but authenticating only grants you permission to create accounts on Forgejo and Discourse. Imagine using your Google account to log into some other website that isn’t run by Google.
The one benefit of this approach is that it would work out of the box as the software currently exists right now. However, as far as I can tell I would no longer be able to keep t/suki invite only, because that functionality is built into Discourse and not in something like Keycloak. Instead, I’d have to create every account manually in Keycloak or open registration to the public. I would also need to migrate user accounts from Discourse to Keycloak. I think any user could also, at any time, break the connection to the identity provider to turn their account on either service into a standalone one with a username and password. I’m not 100% sure about that though.
In my opinion, automatically granting access if you have an account at t/suki is vitally important, but I also don’t think any of these options are acceptable. Obviously, I think the first option is the best, but I do not relish the idea of running some code which is responsible for handling authentication that is made by unknown entities.
Any thoughts or suggestions on how to proceed would be appreciated. Maybe I misunderstood something in my research? I could, of course, manually grant user accounts on Forgejo. But, this would become more tedious to manage as the community grows and I don’t want to place a burden on community members to have to ask me to grant access.
Having taken a quick look at the distrust codebase it looks to actually be really rather small, so it might not be too bad to just audit all of that code and then integrate it as is without letting it auto-update or anything like that if possible. Though go does seem to have some kind of dependency system that pulls in other things via the mod file, auditing those may or may not be as easy.
Maybe we could set up a thing so that when a new account is created in Discourse (from an invite or otherwise), it automatically creates a corresponding user account in Forgejo, and then emails the user about it, with a temporary password?
I don’t know about the Discourse side of it (API? webhook? plugin?), but I know the Forgejo API side supports this: Forgejo API
That’s not a bad idea, but you’d end up with two accounts – both of which have their own credentials and could diverge in user account information. For example, you could update your email in one place, but not the other! That would be a bit difficult to sort through if I ever need to ban someone.
Had a conversation with @MyriadMinds on Discord that I want to document here.
He suggested that I could use Authentik as a identity provider, as it implements the most complete collection of protocols and services. Keycloak is a close second, but it’s exponentially more difficult to configure.
He also suggested setting up a reverse proxy for Forgejo even though I didn’t think it was necessary due to the fact that you cannot access anything other than the login page and that the only way to login was to do login to the t/suki Discourse instance (which itself has a reverse proxy set up). A few examples of abuse I had not considered include:
DDOS resiliency (early quitting on suspicious connections)
Alerts for odd behavior (like if someone with access starts auto-downloading all repositories on the instance)
Block connections that test random URLs looking for exploits and vulnerabilities
In the case of a hate raid, have a fast way to block IPs
I normally use linuxserver/docker-swag, but I asked if he had a recommendation of his own. Myriad approved of SWAG, but made a few additional suggestions:
I was reading the documentation for repository visibility in Forgejo and found out that there’s actually three different ways repositories can be visible:
If your profile’s visibility is set to “Limited”, all of your non-private repositories will only be visible to logged in users.
If your profile’s visibility is set to “Public”, all of your non-private repositories will be shown to everyone.
If you do not want anyone (apart from your fellow collaborators) to see your repositories, mark your repository as “Private”.
Right now the instance is private as a way to deal with AI scrapers, but I was hoping that I we could decide later about making the git instance visible to the public and change all public repositories at that time to limited. But, you can’t actually do that on a per-repository basis. So, I think it would be better if everyone treated the git hosting as if it were visible to the public. I’ve updated the official t/suki gitplace docs to reflect that.
t/suki uses forgejo right? I’m curious, once the federation support is finally implemented in forgejo, would t/suki be interested in federating with forges that other members of the community self-host?
Yes, that’s right! Federation support is something that I’m looking forward to with Forgejo, and I would be happy to look into it and experiment with it once it is available.
Use Discourse as an OpenID provider. My favorite choice. In this situation, you would only have one account, and that would be your Discourse account. t/suki is focused on the community aspect, and I feel comfortable betting that Discourse will be core service that is important to its operation. Forgejo would delegate user registration to Discourse.
Offload identity management from Discourse to a different service. This choice is okay. In this situation, you would have one account managed by some other identity provider (like 
Use another service just for authentication. This choice sucks. In this situation, you have three accounts. You have one at an identity service which is used to authenticate, but authenticating only grants you permission to create accounts on Forgejo and Discourse. Imagine using your Google account to log into some other website that isn’t run by Google.