fiatjaf
commented
3 hours 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.
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.