I don't know, it feels so cumbersome, you have to publish an event, signed by your key, then wait for the response? And then that stuff gets saved forever, and all you wanted was to make a search?
Discussion
The state is constantly changing, to publish events NIP-66 style would be burdensome in its own way. When I considered publishing events for a similar purpose, I backtracked and landed at a DVM as well.
What is a DVM anyway?
The request response stuff makes it be seen as something it isn't, or shouldn't be. There are at least two different use cases for DVMs, one is good, the other isn't, and they're mixed together in a cursed mix. The good one doesn't need the request-response interface, the other does.
Exactly! nostr:npub1fjqqy4a93z5zsjwsfxqhc2764kvykfdyttvldkkkdera8dr78vhsmmleku s custom HTTP seems quite a bit more elegant
i haven't got an elegant solution for generating JWT expiring tokens tho
that's in Go only at this point, someone who knows how to generate JWT tokens and custom events, this is the flow:
- create new JWT ES256 key pair
- generate kind 13004 event designating the public key of the JWT key pair (this delegates that key to auth for you
- generate a JWT token, optionally with an expiration time (it's a standard JWT claims list and all that)
- send filter or event with Bearer
you don't need to do the JWT flow if the relay is set to be public-readable, so for fetching events it's very straightforward, the auth is just for writing in that situation, or for fetching privileged events like DMs
You had me until "JWT".
Yes, I think the same, dvms are somehow wasteful if we understand the responses as a non valuable data, I mean there are going to be responses that worth to keep and others than no, depending on the job. But I agree, I would add ephemeral events to the spec, which are good for the use case. Also I'll be pruning my relay of dvm responses