5 ms·

Sounds like the description of Radicle. :-) https://radicle.dev/guides/protocol#collaborative-objects https://radicle.dev/guides/protocol#collaborative-objects

0xbadcafebee 2mo ago
That's not really what I'm looking for. Radicle is trying to define specific functionality the system supports: a single protocol which combines multiple separate use cases into one standard. What I want is a system that doesn't define functionality. I want something protocol-less. The larger system design prescribes only loose i/o channels between components, so (for example) you know you can interrogate something Git-ish. But what language or protocol they speak, what functionality they contain, isn't prescribed by the design. This allows them to have any functionality. You might think I want something like microservices. But microservice interfaces are too prescriptive and not interoperable with other services. Everyone writes their own custom incompatible API for the same basic functionality. What's needed is something so simple, so loose, that people naturally copy the first one they see for their own implementation. Example: Pull Requests. They're basically just a git diff, that can be approved, blocked, rejected, and comments are attached to them. You could implement that a hundred different ways. But what's the simplest possible thing? It already exists: patches in e-mail. You e-mail a diff to a mailing list, people reply (comment) on pieces of the diff, and eventually somebody commits and merges some form of the diff and pushes it to their repo. You didn't really need a DAG, or objects, or CRDTs, or protocols. You already had everything you needed. So how to implement this, in a system with no protocols? Just feed e-mails into an app; the app reads the e-mails, it accesses a clone of a Git repo for operations, it sends e-mails out, and displays comments etc in a web interface of the diff. Next example: Issues. This one is pretty simple: use any ticketing system you want, the rest of the system has no idea. Reference an issue's URL in a comment or commit message with either the bare url, or markdown ([issue #123](uri://somehost/issuetracker/view?i=123)). Use OIDC to allow logins, or read-only for anonymous. Want to "copy" data from one system or component to another? Each system can do this differently, but if you make it simple enough, they'll all do the same thing. Simplest solution? For each service's HTTP endpoint (I'm just assuming they would all use HTTP to communicate, but don't have to), prefix the endpoint with "/zipmime", and the result is a ZIP file of MIME files (so "uri://somehost/issuetracker/view?i=123" becomes "uri://somehost/zipmime/issuetracker/view?i=123"). Now you can export any data from any service in a standard way that supports any kind and amount of content (because it's URI-based and HTTP-based, the service doesn't even have to support this natively! you can implement a reverse proxy and microservice to bolt the functionality on later). At no point in any of these designs are they dependent on other designs. They just "do what they do", and other designs naturally coalesce around simple standard methods.
- Nemo_bis 1mo ago
  That sounds like you do want a protocol. You have listed several requirements of one such protocol: 1) Patches at git-email would make them; 2) Issues in markdown format; 3) Authentication with OIDC; and others depending how strictly you meant some of your other preferences.

0xbadcafebee 2mo ago

That's not really what I'm looking for. Radicle is trying to define specific functionality the system supports: a single protocol which combines multiple separate use cases into one standard. What I want is a system that doesn't define functionality. I want something protocol-less. The larger system design prescribes only loose i/o channels between components, so (for example) you know you can interrogate something Git-ish. But what language or protocol they speak, what functionality they contain, isn't prescribed by the design. This allows them to have any functionality. You might think I want something like microservices. But microservice interfaces are too prescriptive and not interoperable with other services. Everyone writes their own custom incompatible API for the same basic functionality. What's needed is something so simple, so loose, that people naturally copy the first one they see for their own implementation. Example: Pull Requests. They're basically just a git diff, that can be approved, blocked, rejected, and comments are attached to them. You could implement that a hundred different ways. But what's the simplest possible thing? It already exists: patches in e-mail. You e-mail a diff to a mailing list, people reply (comment) on pieces of the diff, and eventually somebody commits and merges some form of the diff and pushes it to their repo. You didn't really need a DAG, or objects, or CRDTs, or protocols. You already had everything you needed. So how to implement this, in a system with no protocols? Just feed e-mails into an app; the app reads the e-mails, it accesses a clone of a Git repo for operations, it sends e-mails out, and displays comments etc in a web interface of the diff. Next example: Issues. This one is pretty simple: use any ticketing system you want, the rest of the system has no idea. Reference an issue's URL in a comment or commit message with either the bare url, or markdown ([issue #123](uri://somehost/issuetracker/view?i=123)). Use OIDC to allow logins, or read-only for anonymous. Want to "copy" data from one system or component to another? Each system can do this differently, but if you make it simple enough, they'll all do the same thing. Simplest solution? For each service's HTTP endpoint (I'm just assuming they would all use HTTP to communicate, but don't have to), prefix the endpoint with "/zipmime", and the result is a ZIP file of MIME files (so "uri://somehost/issuetracker/view?i=123" becomes "uri://somehost/zipmime/issuetracker/view?i=123"). Now you can export any data from any service in a standard way that supports any kind and amount of content (because it's URI-based and HTTP-based, the service doesn't even have to support this natively! you can implement a reverse proxy and microservice to bolt the functionality on later). At no point in any of these designs are they dependent on other designs. They just "do what they do", and other designs naturally coalesce around simple standard methods.

Nemo_bis 1mo ago
That sounds like you do want a protocol. You have listed several requirements of one such protocol: 1) Patches at git-email would make them; 2) Issues in markdown format; 3) Authentication with OIDC; and others depending how strictly you meant some of your other preferences.