Extensions, plugins, extra functionality

[otherlayer]

Hi,

@scsibug is currently working on gRPC 'bypass', handling of events depending on many factors (IP, request, content data).
I decided to comment here as there are born very nice features:
#64
#71

IMHO gRPC will be the best place where they can be implemented as a (micro)service, extensions/plugins.
This have many advantages:

• clean and robust relay core implementation
• nostr-rs-relay focus on protocol NIPs
• writing gRPC extensions/plugins in your own language/framework, which will encourage others not familiar with Rust and boost relay functionality
• relay administrators can decide which extensions they want/need and independently add them from many different contributors
• with a clean gRPC protocol/interface one day maybe it can become a NIP (event delegation, external processing)

We all want: spam filtering, pay-to-relay, relay bots, connections with external systems and many other things, in the long run it's not possible to implement all features everybody want in the core relay, will make maintaining harder or almost impossible.

With KISS we just got gRPC event with request data passed by, simple quick relay startup and config, the rest is per extension/plugin/(micro)service.

[otherlayer]

This is what I quickly came up to. There could be extension that internally works with plugin system etc as well.

All gRPC commands (proto files) would be best to be in specified nostr-rs-relay protocol, even in separate repo so whatever language/framework you use you just clone it and build your types.

I don't do UMLs so forgive me, it was just spontaneous diagram.

[otherlayer]

I guess default 'policy' for RequestEvent would be to pass. Every extension can decide to block it or decide where RequestEvent outflow client (there will be two, one to relay, one to next extension, except last one) should pass event, down the chain of extensions or directly to relay, probably not to both. RequestEvent can be even changed/mangled and passed (bot catching message to administrator account and responding with message to user, probably in this case I would say it blocks msg and sends new).

[otherlayer]

Further, extension can conform to some protocol (must have RequestEvent gRPC client/server, work with relay gRPC). This makes it kind of plugin system container which can be implemented in Python, Rust, C#, TypeScript and internally work on plugins similar to how extensions work with each other. Relay administrator can pick eg. 3 Python plugins in Python written extension and connect to Rust extension that will work with 4 Rust written plugins. Something like that.

[scsibug]

This has the advantage of not blocking the writing thread, and even letting events get temporarily held or quarantined for further review; but the downside of just being more complex.

We could always build this in later or optionally, by sending events to the outflow, and then putting the back on the event writer channel once they are sent to inflow; so this could be a separate option for externalized event handling for more complex workflows.

I say we stick with the simple option for now. Is this something you are willing/able to build, or just a suggestion for me to implement? If it was done as an isolated chunk that intercepted and reconstituted the event stream in one place, i'd be willing to merge I think.

[otherlayer]

Will try to hook it, need some time to look into code.