Gregory's Server
Rubber duck:
We're doing a weird trick with Nostr+HTTP in Ditto, which follows these steps:
1. Client hits the API, eg POST /api/v1/statuses
2. Ditto sends a WebSocket message to the client, asking it to sign the Nostr event.
3. The client signs the Nostr event, using NIP-07, a stored key, or whatever other method it wants to use, then sends it back over the WebSocket.
4. All this time, the HTTP request from step 1 still hasn't received a response. But now that the backend (Ditto) is finished, it delivers the response.
Here is the problem: sometimes that takes more than 60 seconds. It's no issue for Deno, which is very efficient at dealing with idle HTTP connections, but most webservers such as Nginx and anything on top, will cut the request off at 60 seconds.
60 seconds is a reasonable amount of time to wait for a user to sign an event. But now I'm introducing proof-of-work requirements, some of which are designed to not finish in less than 60 seconds on purpose.
So now I need to rethink this. I originally chose this design because Mastodon clients already rely on the HTTP response to show toasts such as "Post successfully submitted! [View]" and "Internal Server Error". By keeping the connection open, we can submit the correct response code when it's ready, avoiding a broken UX.
So the question is how to extend the duration of the request. Or how to prepare the information needed before making the request.
I know this sounds insane, but it will be so worth it.
We're doing a weird trick with Nostr+HTTP in Ditto, which follows these steps:
1. Client hits the API, eg POST /api/v1/statuses
2. Ditto sends a WebSocket message to the client, asking it to sign the Nostr event.
3. The client signs the Nostr event, using NIP-07, a stored key, or whatever other method it wants to use, then sends it back over the WebSocket.
4. All this time, the HTTP request from step 1 still hasn't received a response. But now that the backend (Ditto) is finished, it delivers the response.
Here is the problem: sometimes that takes more than 60 seconds. It's no issue for Deno, which is very efficient at dealing with idle HTTP connections, but most webservers such as Nginx and anything on top, will cut the request off at 60 seconds.
60 seconds is a reasonable amount of time to wait for a user to sign an event. But now I'm introducing proof-of-work requirements, some of which are designed to not finish in less than 60 seconds on purpose.
So now I need to rethink this. I originally chose this design because Mastodon clients already rely on the HTTP response to show toasts such as "Post successfully submitted! [View]" and "Internal Server Error". By keeping the connection open, we can submit the correct response code when it's ready, avoiding a broken UX.
So the question is how to extend the duration of the request. Or how to prepare the information needed before making the request.
I know this sounds insane, but it will be so worth it.
Meanwhile, we can add a new approach for signing events to Soapbox, using WebSocket instead of HTTP.
Therefore the default setup with Soapbox will work out of the box, but admins can work around support for native Mastodon clients.
Still.. it's a lot of work and I don't know exactly what it looks like yet.
Meanwhile, we can add a new approach for signing events to Soapbox, using WebSocket instead of HTTP.