NIP-05 verification for replayed events

[psic4t]

To mitigate some spam I enabled NIP-05 authentication on my relay. This does not seem currently supported in rsslay, as I got errors now:

2023/05/31 12:31:04 [WARN] Replayed 10 events to wss://nostr.data.haus with failed status summary -1

Which user is used to replay events to relays? Can I configure that?

[piraces]

Hi there @mdebus , we do have a mechanism to authenticate with relays used to replay events (with their corresponding NIP-05 verification). Nevertheless, I think it may be failing by now and I didn't notice it earlier sorry 😢 (used open relays mainly to test).

I will triage this issue with a relay with authentication and try to fix it. I will let you know when done... This will take priority 👍

[psic4t]

Hi @piraces !

Thanks for your answer! It would be great if NIP-05 verification would be independent from NIP-42 authentication, as my relay should stay open (but still require NIP-05).

[piraces]

Hi @mdebus I have been investigating this issue and I think it is working well but probably failing due to duplicated events. Could you please set the LOG_LEVEL to INFO in order to see specific errors of each "replay".

I have been testing with your relay and I do not see any problem...

[psic4t]

I turned NIP-05 verification off for the time being.

I now turned it on again. If you check now, you'll see the following error:

rsslay          | 2023/06/03 17:21:48 [INFO] Failed to replay event to wss://nostr.data.haus with error: msg: blocked: NIP-05 verification needed to publish events
rsslay          | 2023/06/03 17:21:48 [INFO] Failed to replay event to wss://nostr.data.haus with error: msg: blocked: NIP-05 verification needed to publish events
rsslay          | 2023/06/03 17:21:48 [WARN] Replayed 2 events to wss://nostr.data.haus with failed status summary -1

[piraces]

Ok... I see, will continue with this

[piraces]

Hello @mdebus, I have been testing with this... it results very complicated (maybe impossible) to replay to relays with this setting enabled, since the relay stores the verification status in a table and waits for a process to verify them.

What I'm trying to do now its to emit a metadata event with the NIP-05 verification before every replayed event, nevertheless it will not work until the relay checks the NIP-05, so this first event will fail. Nevertheless, it will success when this verification process has finished.

Version v0.5.2 is going out now with these change... could you try this version and try to enable this setting for a while with your relay and see if there are some verification process ongoing in the user_verification table related with rsslay?

Thanks in advance for your collaboration.

[psic4t]

Hi @piraces!

I re-enabled NIP-05 authentication on nostr-rs-relay and updated rsslay to 0.5.2. Same error as before (blocked: NIP-05 verification needed to publish events).

I checked the database of nostr-rs-relay for rsslay but can't find anything:

sqlite> select * from user_verification where name like "%psic4t%";
12|4246741|psic4t@data.haus|1686073868|1684326184|0
sqlite> select * from user_verification where name like "%rsslay%";
sqlite>

Do I need to set a specific option in rsslay to activate auth?

[piraces]

Hi @mdebus , it will be only necessary to enable ENABLE_AUTO_NIP05_REGISTRATION and set MAIN_DOMAIN_NAME...
If you are with this config set, and no yet any user_verification entry, I will have to investigate further...

[psic4t]

Both were set. Unfortunately no entry in user_verification table.

I now turned off auth to make replaying work again.

[piraces]

Let's continue working with it then...

[psic4t]

Replaying seems not to work at all at the moment. Here's the log:

2023/06/13 12:47:59 [DEBUG] ping to relay failed, reconnecting to wss://nostr.data.haus because of error: use of closed network connection
2023/06/13 12:47:59 [INFO] Failed to replay event to wss://nostr.data.haus with error: failed to flush writer: use of closed network connection

Same for other relays.

EDIT: Just checked, it works with 0.5.1 but not with 0.5.2

[piraces]

Thanks for that info... will review it 👍

[piraces]

Hi @mdebus , I have just released v0.5.3 with some library upgrades and fixes...
I have been investigating too long for now.
I'm considering now NOT to enable replaying to relays.
This "replay" behaviour was in times that rsslay could not handle all incoming traffic, but nowadays I think it makes no sense to duplicate all the information. I think we should deprecate this behaviour.

If someone wants to read feeds from rsslay should connect to this relay, there is no standard for syncing between relays and may generate unexpected and unneeded trafic to other relays.

Please let me know what you think about this 🤔

[psic4t]

Hi @piraces !

As I never got rsslay running reliably (Amethyst shows no posts at all, Snort only sometimes), I decided to code a new RSS/Atom gateway from scratch.

I just finished the first public version of Atomstr today. It's no relay but posts all feed entries to one or more configured relays.

Project page: https://sr.ht/~psic4t/atomstr
My demo instance: https://atomstr.data.haus

It's a bit rough on the edges but it runs reliably for some days now.

Check it out If you want - maybe we can work together on the new codebase?

Greets, psic4t

[piraces]

Hi @psic4t !

Glad to hear that! It's always awesome to see people building things 😄
I find your project very interesting, I started rsslay from the perspective of being a relay (from the fiatjaf initial PoC). Nevertheless, posting feed entries to another relay makes a lot of sense, since you are also storing old feed entries in some cases. I will check it out!

I'm going to put this as an alternative in this repo README.md

Closing this issue then for now... Good work!