Testety McTesting test
🔔 This profile hasn't been claimed yet. If this is your Nostr profile, you can claim it.
Edit
Testety McTesting test
Looking great! Heads up: has kindly contributed WoT Refresh (already merged to master) and I'm working on Improved Backup, and finally Restore functionality (from Backup, not external relays) so we'll have some new environment variables and functionality in the next release.
Done already. I know you cultivate a small gold following list, plus I can always mute folks and assign an Ownertrust level of None to people I want to follow but do not trust to follow good connections. That is the beauty of it, at least for me it is working much better than Haven’s default algo. I mean, other than the fact that it makes Nostr very quiet :)
And it didn't... Well, now a tag mentioning it will, but the WoT correctly blocked this comment.
Not this kind of WoT lol. I’m not assigning scores to anybody other than “you can write to my personal relays or not”. Think GPG Ownertrust model. Your score is basically “you can write to my inbox relay, and I trust you to follow other pubkeys to write to my relays, as long as two other people that I also trust enough to write to my relay follow this same connection of yours Actually, now that you’ve reminded me, I need to change your trust level to FULL so that everyone you follow automatically gets write access to my inbox relay.
Ok, this one made it to wss://haven.accioly.social/inbox, now unfollowing and waiting for the WoT to refresh
Test WoT Refresh
Great stuff and glad to be of service Logen. The macOS UI / app / Distro is looking awesome. You may want to tag your releases with the #Haven hashtag
FYI: `nak bunker connect` is working well. I did a major refactor of the interactive fork so that it flows through the same path as incoming socket commands. Just one small gotcha: when adding multiple nostrconnect tokens to a single bunker session, the usual public relays (relay.nsec.app, relay.damus.io, nos.lol, etc.) quickly started to drop messages, rate limit, and so on. I do not know if `sys.Pool.subscribeMany` is already handling duplicate subscriptions and de-duplicating events on its own, but short-circuiting the extra subscriptions + sleep when delaying with duplicated relays made the problem go away on my end. If you want to bring the fix upstream, here it is: https://github.com/aaccioly-open-source/nak/blob/3ab1d9867f65fb258ecce34ff62f16c2acee137c/bunker.go#L395-L418 It should be compatible with a simple copy and paste upstream. If you decide to take the changes, there is no need to credit me in any way. PS: In theory this can hide a race condition when appending to `allRelays`, but I decided not to bother with it for now. If you run nak with `--race`, there are some other race conditions, same with khatru and Haven.
Will give it a try as well, thanks.
Always curious. Eventually consistent. Strongly opinionated, intermittently technically correct. Labels & self-deception: Computer geek, people builder, world citizen, homelab mad scientist, cat person. My personal relay: wss://haven.accioly.social PGP: 1BBD C23D 1853 255D 6415 D2EC 814E DF85 1AAB 370E