I am totally trying to upload the mails that didn't make it to the list, to arweave. The code's not complete, but it's chugging away trying to figure it out.
I made git-remote-bsv some time ago. It uses bsvup. Bsvup is broken. The api server interface kept changing. I made a number of p2p backends for bsvup. Each one, _not quite complete_, _not quite stable_. Just something that _almost_ works but then you go crazy when you're about to fix the last bug. Anyway, git-remote-bsv has a semi-cool norm when it makes a shadow git repository and uses normal git remote syncing with it, then syncs the shadow files to the blockchain. This lets very little code be written, to make it work, since you just have to have a file uploader.
The nice thing about git-remote-bsv's norm of using a shadow repository, is that I worked out a bunch of funny glitches one could run into, and did things to address them. This would be easy for a normal coder, but things can change. For example, it's pretty confusing to me to sort out garbage collection and object packing. In git-remote-bsv, it automatically disables garbage collection on the shadow repository, retains identical pack files, and ensures new changes are consolidated into a single new packfile. This is all done with normal git shell commands.
Disabling garbage collection can really simplify the space of syncing an object store somewhere, when you're very confused. So, if making an adhoc git remote for arweave, it would be good to disable garbage collection in a shadow repository :) That can be hard for me to think of. Ideally, I'd review git-remote-bsv for other things, that are good to think of. A lot of people make git remotes using custom protocols. This is indeed snazzy, but it means that you need the custom git remote to access the repository. If you use a normal file tree, then other people can download the file tree using third party tools. If there's a web mirror, they can sink the repository with the plain old client using the dumb http protocol. I like that.
Additionally, if your funny tool breaks because I'm insane, if the repository is already in a normative format you don't need to figure out how to repair the tool to access it.
So, git-remote-bsv broke when bsvup broke, and it was pretty buggy anyway. I've basically changed from nodejs (which bsvup was using) to python. Python uses a cross-platform runtime bytecode format that is relatively well-defined, and inspectable at runtime, making it seem much easier to manage weird issues. In node, I kept running into exceptions that propagate poorly through mismatched arguments in a catch() blocks and be reported to the user as completely unrelated errors to their cause. I would have to patch node to fix that. It was pretty frustrating. But I understand the node is incredibly popular and is going to be made stable. I'm sure I can write contracts on solana in javascript, somehow. I also reinforced some python knowledge so I could out machine learning research. Turns out you need to be able do things that you struggle to do, to do that. Something I value more and struggle to do, is writing a blockchain git remote that stays useful.
Git Remote! woohoo. I might try to really simplify and comprehend the process before making a script to do it, I'm not sure.
Here's my git-remote-bsv mess: https://github.com/xloem/git-remote-bsv I'll try again to take notes on whatever I did.
1: if there was private key information, i configured separate push url and pull urls, only if they weren't already configured if (child_process.spawnSync('git', ['config', '--get', 'remote.' + remotename + '.pushurl']).stdout.length === 0) { child_process.spawnSync('git', ['remote', 'set-url', '--push', remotename, origurl]) child_process.spawnSync('git', ['remote', 'set-url', remotename, origurl.replace(privkey, addr)]) } 2. i defined two shadow folders: one for git to sync with, and another for the uploader to upload from const bsv_path = path.join(GIT_DIR, 'bsv', addr) const mirror_path = path.join(bsv_path, 'git.' + crypto.createHash('sha256').update(urlparts.join(path.sep)).digest('hex')) const mirror_path_new = path.join(bsv_path, 'git.new')
3. it only had to handle three commands in the line-based protocol. I've changed the function names from git-remote-bsv below, for clarity. The processes are meant to be run on the remote server, so it's backward. "capabilities\n" -> "connect\n\n" "connect git-upload-pack\n" -> remote_uploads_to_us() "connect git-receive-pack\n" -> remote_receives_from_us() "connect" expects a process to be launched on the remote, with stdin/stdout piped. 4. for both commands, first I synced the shadow dir called "mirror_dir" down from the remote. this ensured it was a canonical copy. I downloaded these files and dirs: /description /config /info /refs /HEAD /packed-refs I additionally downloaded /objects, but I made sure not to overwrite files that were newer locally, and if there were multiple copies on the chain, I made sure to always pick the oldest one, to retain integrity if a private key were compromised. In case the repository had not refs remotely, or wasn't present remotely, I then instantiated a refs folder: 140 fse.ensureDirSync(mirror_path + '/refs')
participants (1)
-
Undiscussed Horrific Abuse, One Victim of Many