MCP is just a JSON-RPC API with natural-language docs.
Maybe all the hype around it will make developers realize that RPC is better than REST.
Discussion
Why is RPC better than rest? Just curious.
He's overreliant on streaming.
subscriptions, really, and he mashed them together with queries in a way that makes managing network resources difficult to do when writing a relay, put it this way, you can't really run even the most well written relay in under about 600mb, that's a lot more than a blockchain client, for example, with transactions coming in all over the place
How low can you go with the Realy API?
i haven't got a client to test it with so idk, i'd assume it would be more like 200-300
Hmmm. Thar sounds pretty good. We'll see #thoon.
Should maybe be part of an overall low-bandwidth mode, or something. Stop auto-downloading media and pull events over HTTP.
just separating subscriptions and queries alone makes a huge difference because you don't need to keep a socket data structure and thread live all the time, you just spin one up each time there is request
the majority of nostr queries are not subscriptions but the client has to explicitly close them all the time
At least in one case where I've made a client server app, it was easier for me to open a websocket and use the webserver as a place to run functions and return ok/err. I found it much easier to work with than requests to endpoints.
I rolled my own message format, but JSON-RPC would have done well too.
because its just function calls. REST is some crazy shit
Far fewer lines of code.
I don't know it's a fair comparison. REST technically is a high level standard but rarely do corporate APIs follow it correctly. Some endpoints return binary, some json, some xml (even though rest requires json) Some endpoints return usable error objects, some don't, some return standard http error codes. It relies more on the HTTP protocol layer for "signalling" compared.
RPC is, well it's a procedure call, but remotely. It's meant to be more agnostic of the layers below it, and imo gives more freedom at the function level with a very strict message structures. I find RPC to be more pluggable and friendly for large systems with many functions. Everything is a POST method, so it safely assumes data can travel both ways.
It can (and is usually) stateless over HTTP, and should be IMO.
Both have their place, for simple services I think REST is simple and assuming they follow the rules should be find for rapid development. For more long term machine-machine interaction RPC offers so much more flexibility. It means the developer is futzing less with HTTP and more on talking to a remote function (procedure)
My favorite example of RPC options are. Lets say you have a modular service, all servers can be slightly different because they can have different plugins running. Well the client only needs to know how to talk to a single HTTP endpoint forever, with a standard format. It only has to make a single GET to the server to know what features/functions are supported by the server. With REST you'd just have to assume the service is there and make an HTTP request and let the server return a 404 at runtime.
I think it might be fair to say RPC is (or at least was) far more widely used. Windows RPC for almost everything, for internal and networked services, RPC is even part of most kernels (or was when the books I read were written.
People don't even know what REST is. They just use GET and POST as RPC access controls and smear error handling across both layers
XD
REST is more advanced than RPC and more compliant with the principle in computer science of avoiding the necessity of codecs to view the transit of information
you have headers (request and response), parameters, paths, body (request and response) and cookies, with RPC you only have request and response
you didn't even use a normal RPC layout for NIP-01, with ambiguous method names in the messages, as well, that makes it more complex to write codecs for it
and subscriptions can be done on HTTP since about 2016, called Server Sent Events SSE
i learned all of that stuff in the last few months because i'm doing this for my paid gig, and it's extremely standardised such that there is no such thing as a HTTP framework on any programming language that doesn't support everything already out of the box
meanwhile, here with nostr we have number codes, ambiguous message formats, absurdly complex filter tag parameters (for most languages you have to do omitempty with all all letters of the alphabet in both cases, which you put an unnecessary # prefix on when there is no other single letter fields in the object), and the lifecycle of connections is very complicated and wastes huge amounts of code and network resources to keep alive, when you could have done that with SSE
i would just add that blu esky is even worse, it uses CBOR binary for its API, and their data structures are absurdly expansive, at least nostr events are simple
It has multiple transports built into the protocol tho. So maybe the Nostr-over-HTTP fools were right all along.
OK, let's do that, but only after Nostr-over-STDIO and Nostr-over-UnixSockets are well-established.
REST, we require state but can't maintain it.
The hype really makes me question the judgment of devs.