You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Sorry if an issue is a bad place to ask a question like this.
I'm just starting to look into Khatru in doing some research into building a novel relay setup I have in mind. I'm hoping to validate (or invalidate) if Khatru would be a good fit for the following design - or if Khatru (or nostr!) is the wrong approach for this.
I'd like to be able to synchronize a set of relays such that a single one is actively used by a given client, but the set of relays together attempts to keep synchronized and redundant. Not unlike https://syncthing.net/.
Example use case:
I have a relay on a remote VPS (remote relay) and a relay on an "edge device" - let's say the latter is a laptop (local relay)
At the moment, my device may be online or offline, but either way it for some reason is out of connection with the remote relay. I use my client as usual on the edge device while it is out of connection with the remote - posting notes, etc. When the remote is discoverable again, the new state from the local is synced to the remote and both relays again have identical state.
Now I'm on a public machine and I authenticate to my remote relay in some client. I use nostr as usual, posting to the remote relay. As this occurs, the remote and the local relay (wherever it may be, if it's online) continue syncing such that when I am back at my device, my experience of using the local relay is identical to what I experienced on the public machine connected to the remote.
Maybe it's the case that you're connected to both at the same time... Either both relays receive identical events and they are responsible for de-duping in their synchronization, or your client is smart enough to use the "best relay out of the synced set" or something.
But now I'm getting ahead of myself.
Does this sound like it's worth persuing in Khatru on Nostr, or are there latent issues with either that make this a poor fit?
Thanks!
The text was updated successfully, but these errors were encountered:
Khatru implements it on the server side, and go-nostr implements it on the client side, so you should easily be able to make a relay that talks to another relay to start a syncing session and vice-versa (although there seems to be some bugs left still).
Sorry if an issue is a bad place to ask a question like this.
I'm just starting to look into Khatru in doing some research into building a novel relay setup I have in mind. I'm hoping to validate (or invalidate) if Khatru would be a good fit for the following design - or if Khatru (or nostr!) is the wrong approach for this.
I'd like to be able to synchronize a set of relays such that a single one is actively used by a given client, but the set of relays together attempts to keep synchronized and redundant. Not unlike https://syncthing.net/.
Example use case:
remote relay
) and a relay on an "edge device" - let's say the latter is a laptop (local relay
)remote relay
. I use my client as usual on the edge device while it is out of connection with the remote - posting notes, etc. When the remote is discoverable again, the new state from the local is synced to the remote and both relays again have identical state.local relay
(wherever it may be, if it's online) continue syncing such that when I am back at my device, my experience of using thelocal relay
is identical to what I experienced on the public machine connected to theremote
.Maybe it's the case that you're connected to both at the same time... Either both relays receive identical events and they are responsible for de-duping in their synchronization, or your client is smart enough to use the "best relay out of the synced set" or something.
But now I'm getting ahead of myself.
Does this sound like it's worth persuing in Khatru on Nostr, or are there latent issues with either that make this a poor fit?
Thanks!
The text was updated successfully, but these errors were encountered: