yeah, that's really sticky
programmers tend to be fairly opinionated about languages
some must have objects, and some don't want them
some must have functional, and others don't want them
some want composition, some want inheritance
but the protocol is not a language and only has a syntax in as far as the API is defined
you can define the API in a protocol like for example protobuf or jsonrpc2 but nostr unfortunately uses a custom API as well, with two main types and a bunch of context relative messages that tend to indicate the state of a subscription
relay testing is relatively straightforward because there is only one interface, the websockets
client testing is different, it has to provide a standard form for each kind of request that it handles, in the wire format, allowing the simulation of human inputs parsed by the client code... probably best done as part of the client-side of the library implementation... in fact it's got me thinking, maybe i should be clearly separating these two parts in my work, currently just been focused on the implementation of data encodings, that should not be in the same package as client or relay code, both should be separated
i'm gonna start thinking about this a lot, at least, preparing myself to be able to work with such a system, maybe at some point actually implement the test harness and define the language agnostic (CLI) interface
it's not possible to eliminate human language from the spec without picking a computer language and that is just not a viable approach, as outlined above
but converging on a single test implementation gives you the freedom to implement with other languages so long as everyone agrees on API encoding, while keeping the "spec" in one codebase
there is probably a reasonable way to create a side-by-side generator so you can compare different implementations to each other, it's just a small extension to the test rig's structure, allow more than one and test the outputs for differences and flag them in the logs
mleku / mleku™️
npub1fj…mleku
2024-07-21 13:12:47
in reply to nevent1q…g5p0
Author Public Key
npub1fjqqy4a93z5zsjwsfxqhc2764kvykfdyttvldkkkdera8dr78vhsmmlekuPublished at
2024-07-21 13:12:47Event JSON
{
"id": "4411b178b0595980127a6a32b30e559edc9b5df212e0a33d867226c9b8e207b7",
"pubkey": "4c800257a588a82849d049817c2bdaad984b25a45ad9f6dad66e47d3b47e3b2f",
"created_at": 1721560367,
"kind": 1,
"tags": [
[
"e",
"45aa2c732ffe83f8e5fa2b2a7966bbda42683db178189cdb1cfa6068b8bfb517",
"",
"root"
],
[
"e",
"94b362c472da94a9243c99d397be0eb2047f4bd2fded3dbdee5c3b1dcf80c69d",
"",
"reply"
],
[
"p",
"dd664d5e4016433a8cd69f005ae1480804351789b59de5af06276de65633d319",
"",
"mention"
]
],
"content": "yeah, that's really sticky\n\nprogrammers tend to be fairly opinionated about languages\n\nsome must have objects, and some don't want them\n\nsome must have functional, and others don't want them\n\nsome want composition, some want inheritance\n\nbut the protocol is not a language and only has a syntax in as far as the API is defined\n\nyou can define the API in a protocol like for example protobuf or jsonrpc2 but nostr unfortunately uses a custom API as well, with two main types and a bunch of context relative messages that tend to indicate the state of a subscription\n\nrelay testing is relatively straightforward because there is only one interface, the websockets\n\nclient testing is different, it has to provide a standard form for each kind of request that it handles, in the wire format, allowing the simulation of human inputs parsed by the client code... probably best done as part of the client-side of the library implementation... in fact it's got me thinking, maybe i should be clearly separating these two parts in my work, currently just been focused on the implementation of data encodings, that should not be in the same package as client or relay code, both should be separated\n\ni'm gonna start thinking about this a lot, at least, preparing myself to be able to work with such a system, maybe at some point actually implement the test harness and define the language agnostic (CLI) interface\n\nit's not possible to eliminate human language from the spec without picking a computer language and that is just not a viable approach, as outlined above\n\nbut converging on a single test implementation gives you the freedom to implement with other languages so long as everyone agrees on API encoding, while keeping the \"spec\" in one codebase\n\nthere is probably a reasonable way to create a side-by-side generator so you can compare different implementations to each other, it's just a small extension to the test rig's structure, allow more than one and test the outputs for differences and flag them in the logs",
"sig": "7b5387eb3c3efbe847bee209b2119fc77d514ad47161129769e4b752386b423a28130956136c9b2542acfe964dcbe9dbf60988d50d6580a56c970bbe9e90d880"
}