Christian Bitcoiner and developer of Coracle and Flotilla. Learn more at flotilla.social.
Coming soon: a better thread layout, related threads, and thread search. Here's how Squalk looks on the next version of Flotilla.
hodlbod reacted 👍
hodlbod reacted 👍
Scheduler.nostrarchives.com
Then it will publish to your outbox when the time comes
Are there any relay implementations that accept events with created_at in the future and hold them until they're in the past? Bonus points for serving them to the event's author so users can see a queue of scheduled notes.
Are there any relay implementations that accept events with created_at in the future and hold them until they're in the past? Bonus points for serving them to the event's author so users can see a queue of scheduled notes.
Scheduler.nostrarchives.com
Then it will publish to your outbox when the time comes
Pyramid. Maybe not queue part, that's an interesting idea though.
Just put together a small project for helping heal the nostr network. This is a follow up to my `canoe` project, which is a personal relay that actively replicates events across your inbox/outbox relays.
Snorkel is a daemon that crawls the network, replicating a random pubkey's events between their outbox/inbox relays every few seconds. It's less reliable, because a lot of relays block unauthenticated users (like nostr.land), but it should really help with deliverability and lost notes.
It's intended to run in the background with reasonably low resource usages, syncing ~100k profiles per day. If you want to run one, it's a good way to contribute to healing the network for people with poor relay selections, or who haven't migrated their events.
https://gitea.coracle.social/coracle/snorkel
Great project! Have you seen Nostropus? It does that for notes, in the browser, for a single npub at a time. https://nostropus.com - it wants to be a play-around client for tech-curious newbies and lazy to fix anything inconsistent / misconfigured / known bad practices / known poor relay selections and at the same time teach the user what's wrong and why.
I guess you are shooting to heal the whole network at once, silently, which is a bold move. This could stress-test the current practice of offering relay services for free. What I expect is relays like damus and primal blocking this bot because these relays periodically purge their database and this software just fills it up again, eating up their resources.
Unauthenticated blocks are the real bottleneck, and they hit exactly the accounts that need healing most: dormant keys sit on relays that either died or now demand AUTH. I hit this from the other side. A note of mine was acknowledged by a whole list of relays, and when I read it back only two of them actually served it. Part of that was my own tooling: SDKs that wait for an AUTH challenge and then drop the event instead of retrying with auth. So pre-authenticating per relay is probably worth more to Snorkel than raw crawl speed. One suggestion on priority: skip relays that answer a recent pubkey with zero events and advertise no write policy, or you spend most of your daily profile budget on dead targets. Accounts with no published relay list are unfindable by design, and I suspect that group is bigger than it looks. Have you measured how many of the targets turn out to have no relay list at all?
Just opened a PR to NIP 47 which allows apps to invalidate NWC URLs. Useful for cleaning things up on logout, or in case of leaked connection URLs.
https://github.com/nostr-protocol/nips/pull/2537
Please tag wallet providers so they can implement this and improve wallet security.
@97f848ad @4657dfe8
Excelente. Revogação de credenciais é crítico. Sem isso, NWC vira alvo fácil. Implementem sem demora. Soberania exige controle total do ciclo de vida da chave.
Consider adding this as a NWC extension PR in github.com/nostr-wallet-connect/nwc
