Basically my vibe code experiment of the week.
Mine has this concept:
- If we come across it we cache it.
- To our peers we forward the query the user did so we get their data, along with a list of who we already queried so they don't all spam the same relay. Anything that comes back we cache.
- If its sent to us we forward it if we dont already have it.
- If we come across a new relay we save it. If we come across a relay often we prioritize it to automatically stay in touch with relays people actually use.
- We announce ourselves over the network so others can find us. (This bit I still need to refine, its probably good enough that only the public nodes do this). These events are tempoary events relays dont have to keep long, and frequently overwritten with an updated copy. Now other nodes find us.
- We centralize by promoting peers we like to ultrapeer if we need more of those. Those facilitate things like holepunching and fetch more events than leaf nodes. (Gnutella style).
So far todays test runs went very well once I found why it was bombarding relays with requests (the ai added some stuff I didn't ask for that amplified queries, and it lacked good ajti looping I now added). How well it works in practise when theres a lot of them has to be seen though. But its designed to be extremely resillient to where the network just heals itself and where all these nodes are aggregator relays.
:H::e::n::k::y:!!
npub160…x889v
2026-10-07 00:58:37 UTC
in reply to nevent1q…ddl0
Author Public Key
npub1600yr4qg5vcfp7svf6ysj0008tn7aphnu0gjs6lw5hjn74n0laasjx889vSeen on
wss://relay.mostr.pubPublished at
2026-10-07 00:58:37 UTCEvent JSON
{
"id": "67bd5f855dad7392f2116d7523d3495a10f53e68ccd857032adb69b45e3cff1a",
"pubkey": "d3de41d408a33090fa0c4e89093def3ae7ee86f3e3d1286beea5e53f566fff7b",
"created_at": 1791334717,
"kind": 1,
"tags": [
[
"alt",
"A short note: Basically my vibe code experiment of the week.\nMin..."
],
[
"e",
"428ff7ebceb39da593a6f91b4fc25c99a9ed143679d086214d54fcb4c49c4267",
"wss://relay.ditto.pub/",
"root",
"32e1827635450ebb3c5a7d12c1f8e7b2b514439ac10a67eef3d9fd9c5c68e245"
],
[
"p",
"32e1827635450ebb3c5a7d12c1f8e7b2b514439ac10a67eef3d9fd9c5c68e245",
"ws://relay.jb55.com/"
],
[
"client",
"Amethyst"
]
],
"content": "Basically my vibe code experiment of the week.\nMine has this concept:\n- If we come across it we cache it.\n- To our peers we forward the query the user did so we get their data, along with a list of who we already queried so they don't all spam the same relay. Anything that comes back we cache.\n- If its sent to us we forward it if we dont already have it. \n- If we come across a new relay we save it. If we come across a relay often we prioritize it to automatically stay in touch with relays people actually use.\n- We announce ourselves over the network so others can find us. (This bit I still need to refine, its probably good enough that only the public nodes do this). These events are tempoary events relays dont have to keep long, and frequently overwritten with an updated copy. Now other nodes find us.\n- We centralize by promoting peers we like to ultrapeer if we need more of those. Those facilitate things like holepunching and fetch more events than leaf nodes. (Gnutella style).\n\nSo far todays test runs went very well once I found why it was bombarding relays with requests (the ai added some stuff I didn't ask for that amplified queries, and it lacked good ajti looping I now added). How well it works in practise when theres a lot of them has to be seen though. But its designed to be extremely resillient to where the network just heals itself and where all these nodes are aggregator relays.",
"sig": "bf2f479a02fa8b4e74bcd98c09dc1584d287ee69f155a5516d24749ac56e05addf0a3e2efdc511c5557191aeff2e5d2868bc3cac8b485e16560aff6bfe91f7b0"
}