Open rikmeijer opened 3 weeks ago
fiatjaf
commented
3 weeks ago This has been suggested many times in the past. It's not a good idea. WebSockets are fine. They can be used statelessly too in one-off requests if you need that. It is not a good idea to have two ways of doing the same thing.
rikmeijer
commented
3 weeks ago I must have overlooked these proposals, my apologies then. However the intent for this is not so much an alternative to relays, I agree that having two similar ways is not a good idea. The idea is to connect clients who can not run websockets permanently (shared hosting for example). Not altering the protocol. It is just a small addition to relays, but opens the nostr network for shared webhosting sites, which run a lot of websites.
According to you websockets can be run stateless, which I concur. My guess was that spinning up a websocket for each request gave too much overhead/delay. Seeing no proposals on this I wanted to open that discussion first.
melvincarvalho
commented
3 weeks ago +1000 it's the ONLY way to scale nostr which is struggling quite badly right now with scale
Typically in a REST API you would have /v1/ type things as the exact details can evolve and/or be refined
rikmeijer
commented
3 weeks ago I can not say for sure if nostr is struggling with scaling, no data for that, however I believe that opening up to other networks (shared webhostings, IRC etc) can help onboarding more use cases and ultimately growing the network effect
melvincarvalho
commented
3 weeks ago They can be used statelessly too in one-off requests if you need that
While WebSockets can technically support stateless, one-off requests, they are fundamentally constrained by multiple round trips, which can severely impact performance. Additionally, WebSockets require a connection-oriented web server, presenting significant scaling challenges that make it difficult to support large-scale deployments. In contrast, the technique outlined in the original post has demonstrated the ability to handle billions of users efficiently and cost-effectively, with decades of proven data supporting its scalability and reliability
Title: REST2NOSTR Proxy for Shared Hosting Environments
Authors: rik@nostriphant.dev
Status: Draft
Created: 27 oct 2024
Abstract: This proposal introduces a REST-based proxy for Nostr relay interactions, intended for environments where WebSocket support is limited, such as shared hosting platforms. The REST2NOSTR Proxy enables clients to communicate with Nostr relays via simple HTTP REST endpoints, offering a more accessible method of connectivity while preserving the functionality of Nostr's protocol.
Motivation
Shared hosting environments often lack the necessary infrastructure for persistent WebSocket connections, which are essential for traditional Nostr relay communication. Challenges in such environments include:
Limited Running Processes: Shared hosting may restrict long-lived processes or may not allow dedicated processes for WebSocket communication.
Connection Overheads: Each interaction with WebSocket-based Nostr relays may require reconnection, leading to inefficiency and added overhead.
Intermittent Connectivity: Users on shared hosting are often unable to sustain persistent connections, limiting the effectiveness of real-time interactions.
By introducing a REST2NOSTR Proxy, we provide an alternative that allows shared hosting clients to interact with Nostr relays using HTTP REST requests. This bypasses the limitations of WebSocket requirements and allows for more flexible and compatible deployments in constrained environments.
Detailed Specification
The proposed REST API endpoints would cover the fundamental actions in Nostr:
POST /event
Description: Allows clients to send a Nostr event to the relay.
Request Body: JSON object containing the Nostr event.
Response: JSON acknowledgment of the event's acceptance or error.
GET /req/
Description: Retrieves a list of events from the relay, filtered by specified parameters.
Parameters: Optional query parameters for filtering (e.g., event kinds, author, tags).
Response: JSON array of matched events.
POST /req/
PUT /req/
Description: Allows clients to establish a subscription for specific event types.
Request Body: JSON object specifying the subscription filters.
Response: JSON acknowledgment of the subscription setup.
DELETE /req/
Description: Allows clients to unsubscribe from specific subscriptions.
Request Body: JSON object specifying the subscription ID to cancel.
Response: JSON acknowledgment of successful unsubscription.
The REST2NOSTR Proxy would act as an intermediary between the client and Nostr WebSocket-based relays:
Client Request Handling: REST-based HTTP requests are received by the proxy, processed, and then converted to the appropriate WebSocket interactions with the Nostr relay.
Relay Communication: The proxy maintains the WebSocket connection with the Nostr relay on behalf of the client, thereby managing persistent connections.
Response Management: Events from the relay are converted into JSON and sent back to the client via HTTP response, allowing for periodic polling if real-time connectivity is limited.
Polling Overheads: In the absence of WebSockets, clients may need to periodically poll the /events endpoint to retrieve real-time updates, potentially introducing latency.
Connection Management: The proxy must handle multiple clients while maintaining efficiency, requiring mechanisms to limit resource consumption and maintain service quality.
Security Considerations: Authentication and rate-limiting must be implemented to prevent abuse of the REST endpoints.
Use Cases
Shared Hosting Applications Applications hosted on shared environments can use the REST2NOSTR Proxy to interact with Nostr relays without the need for WebSocket support.
Lightweight Clients Devices with limited connectivity can benefit from simplified, stateless HTTP interactions, reducing overhead.
Future Work
This NIP opens the door for additional extensions, such as:
Enhanced Event Filtering: Providing more granular filtering options for REST-based event retrieval.
Subscription Improvements: Options for long-polling or server-sent events (SSE) as a potential alternative to WebSockets for real-time updates.
Conclusion
This proposal suggests a REST-based proxy as an efficient alternative to WebSocket connections in constrained hosting environments. By introducing the REST2NOSTR Proxy, we provide developers with an option to maintain Nostr compatibility and functionality on platforms where WebSocket support is impractical. This enables broader adoption and flexibility within the Nostr ecosystem.