sounds exactly like what it should be
also, yes, remember what i said about having a single relay that forwards queries? well, the solution to that would be a relay that interfaces with a local relay to become its proxy, and the auth requests are processed by the local relay but the primary remote merely forwards auth messages to and fro to enable auth and then it does the bandwidth heavy stuff on the cheap VPS connection, caches all query results as well as forwarding the responses back.
the key thing is it requires the relays to expose a specialised type of socket connection that functions as a proxy for some traffic but not for other kinds of traffic, and acts as a filter and cache to act as an intermediary without requiring you to trust the deployment upstream, and as well, in the bundle you get a local cache that works offline, potentially can also cache outbound publishing of events and dispatch them when it comes online again (and ofc handling the auth via your local signer between the client and the local relay)
i'm just talking about solving for the bandwidth optimization, the rest is already easily done by writing teh client the right way
mleku
npub1fj…mleku
2025-05-31 11:14:56
in reply to nevent1q…gwz2
Author Public Key
npub1fjqqy4a93z5zsjwsfxqhc2764kvykfdyttvldkkkdera8dr78vhsmmlekuPublished at
2025-05-31 11:14:56Event JSON
{
"id": "bf9ea5e30cd3b03044c8ab33412345e4fd2a2d9eb6961f2cdc0260495865ed0d",
"pubkey": "4c800257a588a82849d049817c2bdaad984b25a45ad9f6dad66e47d3b47e3b2f",
"created_at": 1748690096,
"kind": 1,
"tags": [
[
"e",
"afdaf251a095914d0f9d4ea7cd604092421e6a7569467e8a388bc54eb5c6928a",
"nostr-idb://cache-relay",
"root",
"fd208ee8c8f283780a9552896e4823cc9dc6bfd442063889577106940fd927c1"
],
[
"e",
"ed138062d444ac1067f6cddf5a817604d0406b2d0569c5cd8e588139987e4074",
"wss://theforest.nostr1.com/",
"reply",
"fd208ee8c8f283780a9552896e4823cc9dc6bfd442063889577106940fd927c1"
],
[
"p",
"dd664d5e4016433a8cd69f005ae1480804351789b59de5af06276de65633d319"
],
[
"p",
"70122128273bdc07af9be7725fa5c4bc0fc146866bec38d44360dc4bc6cc18b9"
],
[
"p",
"fd208ee8c8f283780a9552896e4823cc9dc6bfd442063889577106940fd927c1"
]
],
"content": "sounds exactly like what it should be\n\nalso, yes, remember what i said about having a single relay that forwards queries? well, the solution to that would be a relay that interfaces with a local relay to become its proxy, and the auth requests are processed by the local relay but the primary remote merely forwards auth messages to and fro to enable auth and then it does the bandwidth heavy stuff on the cheap VPS connection, caches all query results as well as forwarding the responses back.\n\nthe key thing is it requires the relays to expose a specialised type of socket connection that functions as a proxy for some traffic but not for other kinds of traffic, and acts as a filter and cache to act as an intermediary without requiring you to trust the deployment upstream, and as well, in the bundle you get a local cache that works offline, potentially can also cache outbound publishing of events and dispatch them when it comes online again (and ofc handling the auth via your local signer between the client and the local relay)\n\ni'm just talking about solving for the bandwidth optimization, the rest is already easily done by writing teh client the right way",
"sig": "da0283127f06335441c56a87e47f36d9544b2e66e9782c42c6da9c057091a8528757b96ebaa96f7b4a67907409137ac01965c902b1c436ad9012a6f54af2d31d"
}