bridgy-fed
bridgy-fed copied to clipboard
snarfed
support Nostr
Simple, key-centric, UX is still rough, community is heavily Bitcoin/crypto people right now, but could be promising.
https://github.com/nostr-protocol/nostr
- [ ] Implement
Protocol - [ ] Serve NIP-05 discovery
/.well-known/nostr.jsonpath. Translate@user@instanceto[email protected] - [ ] Poll for new posts from followings
- [ ] Poll for new notifications
- [ ] Implement Schnorr signatures
- [ ] ...?
Data points to help determine priority:
- https://nostr.io/#profile-chart says there are 365k users (profiles) right now
- https://stats.nostr.band/ says there are 1.13M users (profiles) right now, 13k "high" (ie non-zero) quality WAUs
365k vs 1.13M is a big spread, not sure why that is.
I think they differ because of when they started collecting stats, maybe also the relays they are using. Here are two more:
- https://primal.net/explore
- https://nashboard.space
Talking to a nostr friend @gzuuus, he told me that https://stats.nostr.band/ is the most reliable source.
ActivityPub <=> Nostr bridge! https://soapbox.pub/blog/mostr-fediverse-nostr-bridge/
Thanks @snarfed for the quick answer, good to know that PRs are welcome ! Will check on it with other Nostr people
I reread https://github.com/nostr-protocol and https://github.com/nostr-protocol/nips/blob/master/01.md and have a few questions about the protocol:
- Apart from events you've sent, it sounds like all of your account/user data, notably your private key and your follows (?), are kept locally on the client. Key rotation sounds unsolved, ok, fine - https://github.com/nostr-protocol/nostr/issues/45 - ~but how about your follows? If you use multiple devices, do you have to manually follow/unfollow on all devices to keep them in sync? If you use a single device, and you lose it, is your following list gone? Is there some NIP for this?~ Aha looks like this is NIP-02.
- Where's the guidance on whether/how long a relay should store a given event? Eg the contacts kind for NIP-02? Haven't found anything on that in NIP-01.
- Should Bridgy Fed be a relay? Or should it act more like a client proxy, and use other relays? Not sure yet.
Here are the relevant NIPS I've found so far:
- User profiles: NIP-39
- User's relays: NIP-65
- Likes/reactions: NIP-25
- User mentions: NIP-27
- Replies: NIP-10, notably the Marked "e" tags method, which has parent, root, and references (eg quotes), along with "p" tags for those events' authors and other related users.
- Notifications: also NIP-10, by users querying for themselves in "p" tags?
- Reposts: NIP-18
- Hashtags: NIP-12
- Articles: NIP-23
- Count queries, for eg followers, likes, etc: NIP-45
cc @manton
To relay, or not to relay? Reasons:
Relay:
- need to be a WebSocket server but not client, which may be harder on GAE
- necessary for discovery? ie for a Nostr user discovering another user, both of whom are new to Bridgy Fed, if we're not a relay, there's no way for BF to discover this and propagate events into the remote relay on demand. This might be the deciding factor.
Not relay:
- probably less work, don't have to implement relay protocol, just be a client
Same either way:
- need to connect to an arbitrary number of external relays either way? to collect Nostr users' posts? Or would we say they have to add us as a relay destination for their posts to federate them?
- How does relay-to-relay traffic work anyway? Nothing about it in NIP-01. Does it happen? Or would BF be unusual in doing it?
Interestingly Nostr user growth and posts seem to be way down over the last month or so. Either that or maybe some big relay change happened and stats.nostr.band missed it. But it's "the most reliable source" ^ so 🤷
...ah, ok, the earlier high new user growth was evidently accounts with no profile or other info, so they likely weren't human, so the drop in posts may have just been a big wave of spam ending.
Still, active "trusted" users is slowly dropping too.
List of relays: https://nostr.info/relays/
I'm currently testing with https://relayable.org/
Curious what relays you settle on. I'm currently using nos.lol, relay.snort.social, relay.damus.io, and relay.nostrgraph.net because they seemed popular and didn't sound terrible. But I'd like to put some more thought into this. There's a performance trade-off to supporting "all" the relays.
Definitely. Right now I'm just learning, but I suspect Bridgy Fed will actually need to be a relay itself: https://github.com/snarfed/bridgy-fed/issues/446#issuecomment-1563618821 . Not sure yet though, and obviously it's pretty different from micro.blog.
I like the idea of Bridgy being a relay itself, although I'm not sure that's required. If I do more with Nostr, I will probably have a relay too. Mostly because it feels like the right thing to do to fully participate in the Nostr ecosystem, more than a technical requirement. (But I might be missing something!)
I recently finished enough Nostr data conversion and relay protocol support to launch it in granary:
- https://granary.io/?site=nostr#logins
- https://granary.io/?input=html&output=nostr#logins
Current obstacle: from NIP-01:
Each user has a keypair. Signatures, public key, and encodings are done according to the Schnorr signatures standard for the curve secp256k1.
I'm having trouble finding a production-appropriate Python implementation of BIP340 Schnorr signatures.
- pycryptodome feature request
- pyca/cryptography feature request (closed pending OpenSSL support)
- OpenSSL feature request
- BIP340 includes a reference Python implementation, but it's unpackaged and unmaintained
- BitPolito/schnorr-sig is "for educational purposes only"
- btclib looks mature but says it's "not intended for production environments"
- FROST-BIP340 is an early implementation of a new, BIP340-compatible multi-sig schema
- long discussion on StackExchange
Production-ready candidates:
- rustyrussell/secp256k1-py, FFI bindings around bitcoin-core/secp256k1
- Moustikitos/fast-curve, native lib, seems largely unused
- karask/python-bitcoin-utils, just copied the reference implementation with minor modifications
- kauriid/schnorrpy, bindings for the Rust schnorrkel lib, looks unmaintained, unclear if it does full BIP340
secp256k1-py looks like the winner.
I should do a survey of relay info metadata, specifically the limitation field, for a handful of the bigger relays. nostr.law (?), nostr.mom, relayable.org, etc. I'm curious what their limits on the various filter fields are, esp if I need to subscribe for all Bridgy Fed users on a given relay.
Active user counts are still low, but trending up again. Last 6 mos:
https://stats.nostr.band/#daily_active_users
https://stats.nostr.band/#weekly_active_users