Nothing revolutionary. Since I’m fetching users, notes etc via relay internally (just like every nostr app does), I was thinking, why not expose these as GET endpoints.
I.e.:
/user/npub….. get JSON of user.
Will any one use it? I don’t know. I’m just exposing them as Apis, since I need them anyway.
why are you doing it that way instead of just writing a nostr client?
this is a bad anti-pattern
I wrote a library to make interacting with relays very easy, maybe have a look?
Of cause I’m using NDK. Maybe no one except me will be using it. Maybe someone doing simple Excel spreadsheet wanna pull users can use it.
Certainly it will be much easier (lesser work) not packaging it and exposing it. Just a little community service.
But why do you need it? Why aren’t you fetching data from the relays directly instead of introducing a different api?
I’m fetching it from the relays directly. Just that instead of putting the fetching within the client, I’m putting these fetches as GET endpoints and use them for the client.
Currently it isn’t this way, it’s like what you mentioned, “using relays directly from the client”.
Refracting the code to use GET endpoints, will allow client to use react queries, and fetch data as and when needed with parameters.
What your concern about?
Centralization.
Lack of user control.
You should make it clear to your users they are not using a nostr client then 😉
Those codes will be open source. People can see what each endpoints is doing, that is, simply just get information and pass along. Don’t think it’s centralised just because they are calling a http request. I see this as a community service actually, as reworking the codes and packaging them nicely is not as straightforward as just directly using NDK and nostr tools for my own usage.
