support Nostr

[snarfed]

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

• Test deletes
• Nostr: add more default relay(s) #2208
• when we send to a relay, we're not populating Object.copies?! looks like a race condition between the different send tasks?
• @-mentions, https://nips.nostr.com/27
  • not doing NIP-27 right when sending to Nostr, eg at://did:plc:3ljmtyyjqcjee2kpewgsifvb/app.bsky.feed.post/3m5msld36cs2q
• alsoKnownAs should use npub, not hex id. https://web.plc.directory/did/did:plc:apr5mpjlx7z3mag5mcpe3nge , https://browser.pub/https://nostr.brid.gy/ap/test@snarfed.org
• follows, both directions
  • Bluesky
  • AP
• handle conversion can have collisions, eg a.b@c.d vs a@b.c.d #1994
  • use User.handle_as_domain?
  • https://fed.brid.gy/docs#concrete+examples
• images/video, need at least one more element in the imeta tag. m (type), dim, size, etc. https://nips.nostr.com/92 , https://nips.nostr.com/94
• searching by AP id in Mastodon doesn't work, eg https://nostr.brid.gy/ap/nostr:86062523fd96df9a06132675a446455448517e840a624798030eb70a25e1bd26, https://nostr.brid.gy/ap/test@snarfed.org
• Nostr: stop overriding users' profile Object ids to be their pubkey #2209
• Nostr: try harder to find users' relays (kind 10002 event) in Nostr.fetch #2211
• Internal blocking, eg for web <=> Nostr #2210
• profile updates
• fix NIP-05 handles. (eg Bluesky's is curently _@[handle])
• Nostr posts, replies, reposts get duplicated, I think because we generate a fresh event, with new created_at, for each relay we send to?
• when we validate a NIP-05 validation, remove that NIP-05 from any other Nostr users who have it
• fix uri_to_id with TLV bech32, eg nevent1qqs80uhl8s0ps9pm9ctxgvqzcf57dyzgly7fhfjphh5ah9fnuze7z6spqqq36amnwvaz7tmwdaehgu3wvf5hgcm0d9hx2u3wwdhkx6tpdshsz8nhwden5te0dehhxarj94c82c3wwajkcmr0wfjx2u3wdejhgtczyp7uculf7v34dkjxp2cp48d4f37g5zp0kp7mftpdgj7pqcyw7pwtuqcyqqqqqqg77rwwc should be 77f2ff3c1e18143b2e16643002c269e69048f93c9ba641bde9db9533e0b3e16a

---

• Implement Protocol
• Serve NIP-05 discovery /.well-known/nostr.json path. Translate eg @user@instance to user.instance@ap.brid.gy
• authenticated relay connections (blocked on NIP-42: which key should clients sign AUTH challenges with? nostr-protocol/nips#1949)
• handle
• Relay selection
• NIP-65 per-user relay list
• Verify signatures
• NOSTR: NIP-24: extra profile fields #1954
  • [ ] r tags for web URLs? https://nips.nostr.com/24#tags
• NIP-48 proxy tags
• require NIP-05 in status
• NIP-72 imeta tags
  • images
  • video
  • audio
• delete. note that granary's Nostr.delete seemingly takes hex ids right now
• hub
  • subscribe to posts from followings
  • subscribe to notifications
  • subscribe to Nostr users' relays
  • when a new user is on a relay we're already subscribed to, re-subscribe with their pubkey
• Implement Schnorr signatures
• Spam/abuse hardening #1941
• [ ] NIP-73 external ids with i tags
• Encrypt private keys in datastore #794
• What's the current state of scaling query filters? Ie requesting lots of user's events. Overlaps with but not exactly the same as lists/sets?
  • https://nips.nostr.com/51 ?
  • Follow lists don't scale nostr-protocol/nips#1179
  • NIP-61 - Event Sets nostr-protocol/nips#784
  • https://github.com/arthurfranca/nips/blob/bunch-of-events/61.md ? Not sure if this directly applies
  • https://nips.nostr.com/21 , Kind 3, follow lists
• when receiving a profile for a Nostr user, do reload_profile() with it
• add SUPPORTED_KINDS, use in nostr_hub?
• narrow Nostr native users query to just posts, profile, relays, ...?
• query with since, store per relay
• don't reconnect to relays if pubkeys haven't changed
• standardize event ids on nevent bech32 prefix...or hex ids? without nostr: prefix? hrm
• clamp created_at to now (?) (eg nos.lol doesn't allow it to be too old, eg 2022)

If we do opt out:

• Nostr: add followees to npubs that we filter for in the hub #2213

For launch:

• add nostr to AUTO_REPOST_ACCOUNTS
• add web back to DEFAULT_ENABLED_PROTOCOLS? maybe?
• make nostr bot user in AP, Bluesky
• propagate existing bot users into Nostr
  • serve NIP-05 for them
• add to nodeinfo

Extra:

• Nostr: include native (source) id in NIP-39 tags in profile objects #1950
• Use nostr_hub for writes as well as reads? #1953
• Nostr: custom NIP-05 domain handles (ie set_username) #2212
• [ ] NIP-11 relay info
• handle conversion can have collisions, eg a.b@c.d vs a@b.c.d #1994

[snarfed]

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.

[danielcharrua]

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.

[snarfed]

Thank you!

[snarfed]

ActivityPub <=> Nostr bridge! https://soapbox.pub/blog/mostr-fediverse-nostr-bridge/

[sven-hash]

Is there something to test already ?

[snarfed]

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

[sven-hash]

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

[snarfed]

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

[snarfed]

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:

• drastically 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. Negentropy synching? How widespread is it?

[snarfed]

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.