Giters

snarfed / bridgy-fed

🌉 A bridge between decentralized social network protocols

Home Page:https://fed.brid.gy/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

support Nostr

snarfed opened this issue · comments

commented

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.json path. Translate @user@instance to user.instance@ap.brid.gy
  • Poll for new posts from followings
  • Poll for new notifications
  • Implement Schnorr signatures
  • ...?
commented

Data points to help determine priority:

365k vs 1.13M is a big spread, not sure why that is.

commented

I think they differ because of when they started collecting stats, maybe also the relays they are using. Here are two more:

Talking to a nostr friend @gzuuus, he told me that https://stats.nostr.band/ is the most reliable source.

commented

Thank you!

commented

Is there something to test already ?

commented

@sven-hash not here yet, no, but PRs are welcome!

commented

Thanks @snarfed for the quick answer, good to know that PRs are welcome !
Will check on it with other Nostr people

commented

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
  • 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

commented

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?
commented

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 🤷

image

image

...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.

image

commented

List of relays: https://nostr.info/relays/

I'm currently testing with https://relayable.org/

commented

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.

commented

Definitely. Right now I'm just learning, but I suspect Bridgy Fed will actually need to be a relay itself: #446 (comment) . Not sure yet though, and obviously it's pretty different from micro.blog.

commented

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!)

commented

I recently finished enough Nostr data conversion and relay protocol support to launch it in granary:

commented

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.

commented

Production-ready candidates:

secp256k1-py looks like the winner.

commented

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.

commented

Started a todo list in the description

commented

Active user counts are still low, but trending up again. Last 6 mos:

https://stats.nostr.band/#daily_active_users
image

https://stats.nostr.band/#weekly_active_users
image