Nostr

just actually needs a little more parsing of the http request i think. probably i can just exclude based on parsing the actual URL in the request, which should be the origin, because i've set up the replicas to use back-channels instead of the DNS name because they will propagate across the wireguard mesh.

i should find that the http request source address contains the match with one of the configured replicas somehow.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 5mo ago

actually, just thinking about it, probably better if the events are pushed anyhows just in case the path from the relay that received the event to one of the other replicas is down, then it still will get there indirectly. fuck it, just gonna leave it. events aren't that big anyway, considering the relays are on fat 100mbit-1gbit lines, better to overshoot propagation than to undershoot. but i wish i could make it so it didn't immediately send it back to the sender lol, that's definitely a step that doesn't need to happen, i just can't see how to work that currently

i think part of the problem is that my test setup has one node on the wireguard mesh, and the other is localhost. i probably just need to deploy it with the test relay instead here on local as the replica to the one on the main, currently only one behind the dns name for realy.mleku.dev, and then they will see the actual mesh addresses. what's happening now is the localhost replica sees a localhost origin IP address so it doesn't know to skip it because it's not the same as the address on its sender list.

yeah, just gonna mull over it a bit more. maybe the solution is to add a header for this delivery. then it can check for that header and get the real expected origin address and correctly skip that. probably the easiest way. even, could, rather than use the IP, even could use the sender pubkey, the HTTP event endpoint gets that from the auth so then it can exclude it by the pubkey of the sender.

this may take me a while to think through, i've got the basic thing working now anyhow.

Reply to this note

Please Login to reply.

Discussion

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 5mo ago

i'm probably going to go with the special header tho. it needs to be non-spoofable. i think that's already covered because the auth events for replicas are from replicas, just that at the moment, there isn't a 1:1 relation between allowed pubkeys and their expected addresses. i think if i switch up the configuration scheme so it pairs pubkey and address together then split them into a collection of address, key that this will let me prevent sending back to the sender who triggered the replication.

so, a little more work yet before this is done. just to avoid that pointless send when the event is already saved to send it back to who it was sent by when it can be known that was a peer. other than that, say i have 3, then the receiver sends to two, and each of those will send to each other AND back to the receiver.

it just sorta seems like to be sure it gets complete propagation, there can't be any such checking, if the event is already stored in the relay then it can know by this fact that it doesn't need to relay it again. so, it's a complete graph replication, times two. which guarantees full propagation, it just ... i'm just not happy with this. seems like something that could be optimized

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 5mo ago

nah, the solution is i change the configuration so the pubkeys are paired with the URLs, write them so they are | because | is not a valid URL character so i know i can split it simply on that character and first segment is the key and second segment to the end is the URL.

then when the message is received, the data structure contains a pubkey|URL pair and it can just skip the URL that matches the auth pubkey

replication REQUIRES the use of auth to properly separate the internet from the mesh anyway. the authed pubkey of a replica cannot be spoofed, and is known in the list of replicas, so when broadcasting it, it just checks the pubkey of auth and then if that matches a given replica in teh list it just skips and only sends to the relays that didn't send it.

there will still be a redundant send from all the replicas aside from the receiver from the internet anyway. this just reduces the number of sends to one less

so if i have 3 replicas, they both get it successfully and then send it to each other and then the replication terminates because both either get it first from one or the reciver. they at least won't send it back to the replica that tehy received it from.

for guaranteeing full propagation this can't be avoided