i may be misunderstanding this - the jargon in that post is non-intuitive to me - forge-fed can be discussed/presented much more plainly
it is definitely concerned with more than only the VCS, and is definitely not specific to git; but it is limited to “forges”, whatever a forge is
the goals forge-fed could be summed as “everything that someone could do by clicking a mouse on a forge website, should be possible without a web browser” - ie: all forge operations should be possible using only a ‘curl’ client - once you have that layer of simplicity in place, everything is possible, including cross-forge interoperability and whole project migration - that simplicity is complicated only by cross-server authentication - the only fundamental constraint, is which set of operations are common across forges (which requests are the target forge willing to fulfill) - the logistics of it could be summed as “translating forge-fed requests into CRUD operations on the remote forge database” - any concerns which do not fit that generalizatoin, do not need to be supported
the concerns for “business domains” and “lifecycles” only complicates people’s thinking - maybe this is more about expanding the scope of the project, to accommodate things that forges do not already do? - at least for the initial ‘core’ protocol, it is sufficient to let the forges decide which features to support - forge-fed could accommodate whatever forges permit their users to do with a mouse, or via an API - everything that forges do is represented canonically in their databases; and i dont see any reason for forge-fed to accommodate anything that forges generally do not do
however, there could always be increasing (but backward-compatible) compatibility versions defined over time, extensions, or whatever is necessary for special use-cases as they arise, beyond the core functionality which is common across forges - if any of those special extensions need to be relatively complex, of course new projects could form around them, dedicated to that domain
i think it is most critical to keep the ‘core’ protocol as limited and generic as possible, and suggest to implementers that any unrecognized messages should be ignored, in order to avoid proliferation of incompatible protocols, while allowing for arbitrary extensions transparently
am i missing something? - why cant we think of it so simply?