it can be improved a lot by not downloading a bunch of events in the first place.
By using DVMs this burden can be moved to service providers, which benefit from better infra and economies of scale.
An example is using Vertex vs downloading 1000 kind:3s to compute WoT things.
smarter relays are the key
idk why they made up this DVM thing, it's just a fucking relay
can i get more free money from odell if i say I'm a DVM developer?
It is a relay, yes, however the output is a new event kind which depends on the inputs of the request.
Yes, the same can technically be achieved by abusing a REQ filter, buuut it's different enough from the normal use that I am okay in using a new thing.
Why would it be "abusing" the REQ?
What's the difference in terms of conditions that you can put on the request?
Both can have a price.
Both can ID the requester.
nip-01 protocol is a mess that literally mashes 3 query APIs into one, incoherently
fetch events by id
search events by filter
search events by content keyword search
it's three API methods that are not clearly separated and this confusion is very obvious at least between the "ids" field and the rest except the "search" field
can we combine SEARCH and FILTER together? maybe yes, but that's a separate logic, and it is actually doable with a small enough result set out of the filter before you do a full text contains search
the nip-01 protocol was not designed as a proper API, and we aren't going to progress this protocol's capabilities without adopting age old "API" semantics
Hehe, I think nostr:npub1wf4pufsucer5va8g9p0rj5dnhvfeh6d8w0g6eayaep5dhps6rsgs43dgh9 and nostr:npub176p7sup477k5738qhxx0hk2n0cty2k5je5uvalzvkvwmw4tltmeqw7vgup would agree on that last point, yes.
> nip-01 protocol is a mess that literally mashes 3 query APIs into one, incoherently
fetch events by id
search events by filter
search events by content keyword search
Yes, If I were to re-make nip-01, I would use these 3 APIs + a general request/response API (DVM like).
However, as much as I don't like messy things, I don't think this is a big deal.
yeah, you only say that because you don't care as much as i do about auth and the private/paid relay use case, which i see as the main avenue of funding for development
We tried and discovered that DVMs do have a place
You could do REQs with AUTH otherwise
also, can you tell me why everything needs a websocket upgrade?
I've been insisting with plain HTTP endpoints for a while but nostr CEO told me that won't happen. Would add too much complexity
yeah, it is a temporary phase, that's how this works, after that the websockes for everyone phase is finally fading and only retards still use it two years later
Websockets are important for feeds
no, they are only important for subscriptions, everything else is in the past and in the event store
IMO this is the number one reason why clients blow up relays sockets management systems - and with Go that means coroutines as well, that manage the pings - because client devs are web devs and are not familiar with this retardation called "websockets that flip from response to subscription when they receive an EOSE" and i doubt that is very scalable either
i'm sure other languages may be slightly more efficient at managing thousands of open sockets that are basically idle but it's not gonna be that big a difference, since the coroutine is 2kb and the socket has minimum 4kb buffer allocated, and that's just the read buffer, not counting all the state
it's just wrong to do request/response with sockets, not only is it extra initial overhead and a round trip, it's also those threads, and the ping pong waste, and the biggest waste is giving sockets to web devs who barely understand http requests
What the funk is a DVM?
