So I was listening to nostr:nprofile1qyt8wumn8ghj7etyv4hzumn0wd68ytnvv9hxgtcpz4mhxue69uhkummnw3ezummcw3ezuer9wchszxthwden5te0wpex2mtfw4kjuurjd9kkzmpwdejhgtcprpmhxue69uhhyetvv9ujuer9wfnkjemf9e3k7mf0qyd8wumn8ghj7ur4wfshv6tyvyhxummnw3ezumrpdejz7qpqdergggklka99wwrs92yz8wdjs952h2ux2ha2ed598ngwu9w7a6fsce9rzs and nostr:nprofile1qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qg3waehxw309ahx7um5wgh8w6twv5hszxnhwden5te0wpuhyctdd9jzuenfv96x5ctx9e3k7mf0qyghwumn8ghj7mn0wd68ytnvv9hxgtcqyqnxs90qeyssm73jf3kt5dtnk997ujw6ggy6j3t0jjzw2yrv6sy22vuwtly talk about replicating content across relays this morning, and so I wrote replicatr:

https://github.com/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).

Reply to this note

Please Login to reply.

Discussion

šŸ‘€

nostr:note1qsxw9hxrmyuuyny66fmz5w35pkzahaxmn72fuu4ymsp8mxrlx0es2ypeee

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.

Yes! It should just work (tm) and make it more likely for your events to be found by clients following the outbox model

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.

Amazing stuff

THanks

Interesting

Shouldn't it be the opposite. I find that indexer needs to pull for all other relays. There are new 10002 poping up everywhere but the index relays.

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.

This service replicates everything else

I was thinking how we could add nostr into rclone

https://github.com/rclone/rclone

I use this tool quite a lot on different machines

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 !

There is this: https://github.com/nostr-protocol/nips/blob/master/94.md which can be used to map hashes to names. rclone looks great, and nostr would be a natural fit.

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.

there is this function in https://nadar.sandwich.farm/ Relay Propagation Checker nostr:npub1uac67zc9er54ln0kl6e4qp2y6ta3enfcg7ywnayshvlw9r5w6ehsqq99rx šŸ˜€

this is the way. thank you for your awesome work.

šŸ‘€

Looks good. In which podcast were they taking about that?

I made a library for app state replication. Would like to combine this with cross-relay replicatr. What you think about negentropy?

https://gitlab.com/orangeman/replistate

Neat! I like negentropy, welshman/net has support for it, and is actually what powers replicatr

You can just make new stuff like this?

Only if you ask permission first

Great project!

I have a similar project, that does not DO sync, but it VISUALIZES the differences between relays. It's https://nostropus.com

It turns out that nostr.band is by far the best relay in keeping old notes...

You probably know this already, strfry supports one-way and two-way sync setup very easily. Use it to keep all nostr:nprofile1qqsdr0fnxvmn8hxyz8cwazfm8zu9yt7qmc38ll69nkvsgn8dnej4sxckxm0xe 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).

so you're saying you are now into blastr?

NO

the two last letters of your project beg to differ