Meanwhile, I’ve been working on something like a nest myself, because I wanted a source browser for historical state, more in the style of gitea, with a single ssh user, and I did not want to burden you with my slop.
I’m now hitting an issue with pushing pijul over ssh myself. The client pushes in data all at once, a lot faster than my server can apply, and then for some reason, sshd sometimes drops the buffer to the server. Pushing pijul over http works fine, because it naturally applies one change at a time, but I don’t see a way to pace the client over ssh. With fast connections and pijul already being at slightly over 13MB worth of changes, that problem is only going to get worse.
I guess, I’ll try to make push over ssh fail partially, so that it can be resumed with less changes, but that’s not a very elegant situation.
This may be totally unrelated to the issue with the nest, but I just wanted to point out, that pushing pijul over ssh is also fundamentally challenging, as far as I can tell.
I had similar issues. I cloned the repository of GarettWithOneR and wanted to push it to a remote repository under my namespace to make a “fork” of the whole repository and apply some changes from a discussion. However, after creating the remote repo in the UI of the nest, I already failed to upload any changes:
$ pijul identity prove nest.pijul.org
Linking identity `lale` with lale@nest.pijul.org
$ pijul push lale@nest.pijul.org:lale/pijul-vscode
● Initialize Repository
Wrong signatureError: Remote exited with status 1
As far as I can see it this is due to GarettWithOneR using an old version of pijul with unsigned changes. If this hypothesis is true, would it be worth opening a separate discussion on how to handle this without just ignoring the authorship of the first commits?