This page permanently redirects to gemini://sunshinegardens.org/~xjix/wiki/no-forge/.

no-forge

=> https://merveilles.town/@xj9/105147527221380842

a git forge-that-is-not-a-forge for inferno. i would like to be able to develop inferno from within inferno without calling out to os, i would also like to be rid of the whole git-forge thing. since i'll be on the topic for a while, i might as well think about what can be done to break away from the centralized git forge model. see, you can't just have a git repo. developing a project is more that source code hosting. you need somewhere to track issues, some way to share documentation, somewhere to discuss the project, a tool for managing builds and possibly deployment, and so on.

fossil addresses some of the issues by merging the entire stack of needs into a single system. however, it comes with some problems of its own. keeping discussion within the source repo also means that you have to clone the full mailing list onto your machine when you clone the repo. operating a fossil server is kind of confusing and you don't really get a fully decentralized system in the end because authz isn't tied to keys, but to passwords which are maintained within a particular instance of a repo (with some ability to group repos).

radicle has some good insights into what a future gossip-based distributed forge might look like. no-forge is an attempt to reach a similar goal and build some bridges into secure scuttlebutt in the process.

=> fossil scm

interfaces

inferno is a graphical envrionment, that means we can have nice interfaces! there is still a cli, which takes some ideas from git9 which rethinks the cli interface of git to make it nicer to work with.

=> git9

protocols

muxrpc

i would like to simplify some things here. radicle says they are an ssb-like protocol, so what if we get two birds stoned at once and adopt some ssb things? muxrpc, in particular, would provide a nice starting point for using secret-handshake for doing ocap stuff. luckily, muxrpc isn't where ssb gets tied to node.js so it should be possible to use as a general-purpose transport.

as far as compatibility with git-ssb, i would probably do a read-only bridge so git-ssb repos can be copied into no-forge with validation. going the other direction and creating ssb.js feeds isn't something i'm interested in, but i would accept patches.

=> muxrpc

git-helper

further study of how radicle uses git transport for gossip is needed.

git remote-no  []
git clone no://~xj9/tomo

=> Helper programs to interact with remote repositories

rlog

=> radicle-link | rlog | git-ssb

bugs

tomo/inferno is already using git-bug to track issues, so we may as well adopt the format.

=> git-bug

remaining issues

• [ ] what about project discussion? is email really king?
• [ ] you can't expect people to do builds over muxrpc
• [ ] probably other things