So I was listening to @Gigi and @hzrd149 talk about replicating content across relays this morning, and so I wrote replicatr: Replicatr is a daemon which listens to one or more indexer relays for `kind 10002` events. When it detects a change in any user's relay selections, it uses negentropy to sync that user's notes to their new relays based on the outbox model. The neat thing is you don't have to run one. I deployed one this morning which points to indexer.coracle.social, so if your metadata gets published there (or to any of the relays that it mirrors), you're already covered (unless your new outbox relay rejects replicatr's publishes).

Replies (30)

I consider it a minor miracle that I'm even using NOSTR as my relatively very limited coding background is mostly irrelevant. With that in mind, I would not hesitate to call myself a NOSTR noob even though I've been here for a while, simply because I don't understand a lot of the super technical stuff. Frankly, I won't even use Github because I don't know how to navigate it. That said, is this relay thing you made going to make my life easier as a NOSTR noob in terms of relay management? Right now I kind of just hope it works and don't manage anything.
Thank you. NOSTR needs stuff like this. I would zap you but Iโ€™m having an electrical issue and my node is down and I am too much of a noob to work around it.
Well, that's sort of orthogonal to this problem, since the point of indexers is to have a copy of 10002s. But I agree that bootstrapping isn't really solved. Not all clients post relay selections to indexers, and even if they did indexers are sort of centralized right now. There should probably also be a service that scans the entire network and replicates relay selections to known indexers.
I also think about it. The probleme is Blossom servers do not store file path nor file name but only hash. So we need somewhere a db that store the path to hash matchs. I see 2 solutions: Solution 1 is to create a centralized middle server that expose a S3 api to the end user (rclone will talk to this server) and this server will process the user request using nostr and blossom. Solution 2 is to create a dedicated rclone remote for nostr + a new NIP to match the file path with the file hash. I prefer the solution 2 but it's more complex to achieve. I will be happy to work on that project, I want it too !
Great project! I have a similar project, that does not DO sync, but it VISUALIZES the differences between relays. It's It turns out that nostr.band is by far the best relay in keeping old notes...
Yes, it's the more suitable NIP for this purpose but it do not explicitly explain how to add the path + filename. I was thinking about adding a "path" tag to make it clear where the file is in the tree. Do you have an idea for the path ? Because we need the path somewhere.
I don't think it would be bad to just add a `path` tag to that event, but I'm not really sure how people are currently using it, or how bad not having a path would be.
You probably know this already, strfry supports one-way and two-way sync setup very easily. Use it to keep all @Nostria discovery (indexing) relays in sync, and I sync with your index relay, purple pages and a couple of popular regular relays with one-way sync.
Yep, I use it to sync my indexer with a few others. Outbox model is somewhat more complex though, replicatr is intended to help fix missing note parents and stuff like that (although I can't help wondering if it's a band-aid solution).
โ†‘