Thread

🛡️
So I was listening to @Gigi and @hzrd149 talk about replicating content across relays this morning, and so I wrote replicatr:
GitHub
GitHub - coracle-social/replicatr: A daemon that monitors nostr relay selections and replicates user events based on the outbox model
A daemon that monitors nostr relay selections and replicates user events based on the outbox model - coracle-social/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 (22)

🛡️
↩ replying to Vitor Pamplona
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 was thinking how we could add nostr into rclone
GitHub
GitHub - rclone/rclone: "rsync for cloud storage" - Google Drive, S3, Dropbox, Backblaze B2, One Drive, Swift, Hubic, Wasabi, Google Cloud Storage, Azure Blob, Azure Files, Yandex Files
"rsync for cloud storage" - Google Drive, S3, Dropbox, Backblaze B2, One Drive, Swift, Hubic, Wasabi, Google Cloud Storage, Azure Blob, Azure Files...
 I use this tool quite a lot on different machines
🛡️
↩ replying to Sebastix
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 !