We need a federation of forges

[dead]

[dead]

[dead]

I'm sorry but I will never use this. I don't want a federated protocol and I absolutely do not want "social". The Git protocol is enough to distribute my source code to any Git server, so that part is complete. What I need, in addition and separate from Git, is a standard API schema for all the other SDLC bits: CI/CD, PRs, Issues, Packages, Containers, Branch Protection, etc. The API should not be a specific transport implementation, like HTTP, or AT. It should merely describe the schema, and then you implement that schema on anything else.

"createIssue(title=string, body=string, labels=[string])" would be the same in Git's source code as it would be on a REST API server. The point of this is to standardize the software development lifecycle everyone uses around Git. That way you can do all the work we all need, with any VCS, without tight coupling. That's been the missing piece that nobody has made yet.

Want just the CI/CD component? Use that part of the schema. Want just the Issues? Use that part of the schema. Now you can write any tool you want, and just implement the features you want, and say "this follows the SDLC v1 CICD standard", or "the follows the SDLC v1 Issues standard". Much simpler to add extensions or support different use cases, without implementing everything you don't need. Yet everything's compatible.

We need that implementation-agnostic standard, so we can make transport-agnostic protocols, so different providers, clients, and servers can all talk to each other, without a hundred different bespoke "things". Rather than write your plugin-downloading app only against GitHub or against Federated-Whatever, you write it to use "httpSLDCs://some-server/v1". Don't want to use https? Use "grpcSDLC://some-server/v1", or "atSLDC://some-server/v1". You layer the application-specific protocol on top of the transport protocol, and express that in a URL. That's how we did 'federation' in the 80's/90's/2000's.

(also: did nobody come up with a better name? Tangled? Knot? you want your solution to be a tangled knot?!)

Why not Just™ store all PR/Issues content as markdown on a separate branch along side the code itself? Why do we need a new protocol?

I'm hesitant to build anything load-bearing on AT Protocol given its PQ exposure: https://words.filippo.io/crqc-timeline/

It took me a minute to figure out what this was even talking about.

Tangles is, apparently, a gitlab-type project where PRs and bug reports and stuff are available on something called "at protocol" which is the bluesky social network "federated protocol".

at protocol competes with ActivityPub, which is mastadon

--

so you could, in theory, have a little federation of gitlabs peer-to-peering with each other, which is desirable for some reason.