-
@ Counter Narrative
2023-08-08 18:06:14
I have an idea I am currently putting together a javascript library and implementation for. This is a quick and dirty blog post to note where my head is at with it.
The main idea is using Nostr as a transport layer for accessing micro services in a censorship resistant way.
I will just use this blog post of a quick introduction on what I am thinking and I will link to more as development continues.
## The idea
The idea is for the client side to access a nostr service very similar to how websites and other clients use XMLHttpRequest() to make API calls to services. The difference here being that rather than relaying on HTTP for the request, the requests and responses would be sent through relays.
The above just shows a quick example of the standard http call to a service.
**This allows the following:**
* Services that do not directly rely on a hosts DNS
* Services that do not expose the service IP address
* Redundancy across multiple relays
* Censorship resistant applications (I will not use the term dapp) that have a service backend
The above shows how a client can interact with a service using nostr as the transport layer.
## How it will work (TL;DR)
In simple terms a service will have a naddress (naddr1) that will carry its public key and core relays it will be listening on. A client will make a request using a generated nostr keypair referencing the service's pubkey in a tag and some call data. The service will read and validate this request and respond by referencing the client's event ID it used to make the call.
There will also be the ability for the service to push data to relays that can be read by clients without a call request being made (i.e. block height changes).
## Why?
There are already many ways to push and pull data whether using nostr relays natively, inefficient block chain smart contracts, tor, or standard http. This may find a few use cases that can compliment existing methods.
In many ways this acts like many of the bots created on nostr that take input and responds with some output. This standardizes the uses a bit more.
**A few use cases:**
* Server side code that can be used on something like ipfs (instead of using expensive inefficient smart contract block chains)
* Services resistant to DNS and IP points of failure (i.e. targeted shutdown of services on the name server level. It has happened!)
* Pulling in outside data that a client does not have ability or access to generate
I will have a working prototype of this in the next few weeks that I will host on a github.