Avatar
pedja
dd9b989dfe5e0840a92538f3e9f84f674e5f17ab05932efbacb4d8e6c905f302
software developer, linux, nostr, freedom-tech, AGI

there was a bot few months ago with similar behaviour. Dan something

really good news

nostr:npub1qfv2tudq6uawsutmzal5x8me5y26692xxfvf587wg79tl6l9q4msp5uyv9 is it better now?

nostr:npub1k6tqlj78cpznd0yc74wy3k0elmj4nql87a3uzfz98tmj3tuzxywsf0dhk6 ?

nostr:npub1qfv2tudq6uawsutmzal5x8me5y26692xxfvf587wg79tl6l9q4msp5uyv9 what kind of change are we talking about?

i'm sorry for late reply. i was going through body detoxification.

only primal clients should use wss://cache2.primal.net/v1 for number of reasons. your local cache instance is available at ws://127.0.0.1:8801 (this is default address on which server is listening which can be changed). if you want to expose the cache instance to public you should use nginx or some other webserver which can do reverse proxy and provides TLS for security.

congratulations! clients of primal cache instance are using websocket connections to send API request messages and get back API response messages. available API requests are defined in file called app.jl but i would suggest, beside looking at that code, you take a look at live communication between primal webapp (at primal.net) and primal server. in your web browser you should be able to open devtools/network tab, and select websocket connection to wss://cache2.primal.net/v1and look at the messages that are being sent and received. there you will be able to see common structure of each API request/response that the webapp is using which is almost everything currently available from our cache instance. webapp usually is the first to use new features and then i tell the same suggestion to our mobile app developers when i want to explain new API requests. ofc sometimes i have to additionally clarify some aspects of new API requests since nobody knows all the details which are sometimes important to mention. that's it. and feel free to ask again.