Winter came back yesterday

We have new stuff. Not much tested yet, so feedback is welcome: 1) Iris Docs —

Iris Docs

Proof-of-concept collaborative text editor and simple canvas on Nostr. Recently also added a chat, so might rename to Iris Apps? 2) IrisDB —

GitHub

GitHub - irislib/treelike

Contribute to irislib/treelike development by creating an account on GitHub.

Extensively used by Iris Docs. Tree-like data structure on Nostr. Build wikis, marketplace apps, games and other decentralized applications where users can choose whose edits they want to see (e.g. followed users, extended social network or specific group). Enables science fiction stuff like deleting & unliking posts, or editing a user profile or list of users without risking overwriting the whole thing with an out-of-sync version. Use a filesystem-like interface to create all kinds of applications on Nostr without having to define obscure event kinds for each purpose. Has simple & powerful useLocalState and usePublicState hooks for React applications. 3) npm create iris@latest —

GitHub

GitHub - irislib/iris-docs

Contribute to irislib/iris-docs development by creating an account on GitHub.

A template that quickly gets you started with Nostr & IrisDB web application development. with dev tools and basic components like login, settings or avatar. Built on Iris Docs — remove the parts you don't need. Decentralize everything!

Bitcoin FilmFest - the heart of Bitcoin Cinema

European Halving Party 🟪🥳🟧 Celebrate Bitcoin in Warsaw

April 19-21 2024 in Warsaw, Bitcoin block #840,000 - see you at the biggest European celebrations of Bitcoin's superpowers

and https://www.halvingfestival.com/ are quite different, but both seem great in their own ways. Not an easy choice!

"Nostr Development Kit" reminds me of "Garden of Eden Creation Kit" from Fallout.

Experiencing slight Madeira FOMO. Didn't realize how many cool #nostr and #bitcoin people there are that I only met last year. Have fun, and see you in Prague & Riga!

Do you have experience quitting caffeine? How long did it take to get back to baseline? I've been without caffeine for 2 weeks. Mood and motivation are not back yet. Wanted to sleep better and have a regular heartbeat. Feeling more calm now, but I'm not sure if this is worth it 😄 I've developed a deep association between coffee and coding over the years.

Where can I find that Nostrasia Maguro song?

My email correspondence with Satoshi in 2009-2011:

Satoshi - Sirius emails 2009-2011

Local sqlite db by @Kieran is great. So much better than IndexedDB. Iris & Snort can now store a lot of data locally, sync only what they don't already have (negentropy & nip-114) and eventually do p2p over webrtc. Works offline. Iris now features a "for you" feed which uses the local database. It scores events by recentness, author favoriteness (top authors reacted by you) and amount of reactions from users who often react to the same notes as you. Recentness is randomly weighted to occasionally show older events as well. Recent notes from all followed users are also mixed in. Events are marked "seen" when they've been in the viewport for 1 second and not shown again in the "for you" feed. I've found it actually pleasant and interesting to use now. New feed every time. It's not extensively tested yet, and might not show great results before your local database is populated with notes and reactions. Also, it's unfortunate that sqlite wasm persistence (origin-private filesystem) requires some http headers that broke youtube and some other embeds.

When is strfry branch nextneg going to be merged to master? Snort / Iris negentropy by @Kieran is compatible with it, but not with the master branch version. Would be cool to be able to negentropy-sync with all strfry relays.

GitHub

GitHub - hoytech/strfry at nextneg

a nostr relay. Contribute to hoytech/strfry development by creating an account on GitHub.

Pull requested to strfry. Thoughts? --- NIP-114: ids_only filter When a subscription has a filter with ids_only: true, the relay responds with [HAVE, subId, eventID] messages. The client can then request the full event from only one relay instead of receiving it from all subscribed relays. If the event is already in a local database, the full event request can be skipped altogether. I have not implemented this for the stream command yet, but this could save a lot of bandwidth if you're connecting to many other relays and subscribing to everything. We might also want a GET message that is sent in response to HAVE messages to request the full event without creating a subscription.

GitHub

NIP-114: ids_only filter by mmalmi · Pull Request #99 · hoytech/strfry

When a subscription has a filter with ids_only: true, the relay responds with [HAVE, subId, eventID] messages. The client can then request the full...

Simple "for you" algorithm at https://beta.iris.to/ . It first checks who have reacted to the same posts as you, and then shows posts that those people have reacted to. It's building the feed using IndexedDB in a web worker. When you open the page, it loads some events from relays into IDB, but the more events you have there the better the results. It rebuilds the feed every minute, or you can hit refresh. I find the feed more interesting than plain timeline, but it should also include recent posts by users whose posts you react to, and some randoms. Ordering by score instead of time would be interesting to try. @npub1dcl4...x5ey was experimenting with logistic regression algorithms already last year. That might produce better results.

GitHub

light-nostr-client/src/lib/logistic_regression.ts at master · adamritter/light-nostr-client

Lightweight Nostr client using rbr.bio as contacts / metadata data source - adamritter/light-nostr-client

Some of you don't like algorithms, but don't worry; the CEO of Nostr has promised to not make them mandatory.

Added support for "not" filter to Iris. It adds filter { not: { ids: alreadyHave }} to all queries in order to avoid downloading events that you already have locally. It's only sent to relays that support nip 113 (which I haven't written yet).

GitHub

iris-snort/packages/system/src/query-manager.ts at d359f3123abb4a1ff08b41e70501a8c985df9775 · irislib/iris-snort

Contribute to irislib/iris-snort development by creating an account on GitHub.

Also implemented it in nostr-rs-relay, although haven't tested with a real database yet:

GitHub

nip-113: not filter support · mmalmi/nostr-rs-relay@55eb916

Mirror of https://sr.ht/~gheartsfield/nostr-rs-relay/ - nip-113: not filter support · mmalmi/nostr-rs-relay@55eb916

If you're connected to 10 relays and query them sequentially, adding alreadyHave to each request you might save up to 90% in bandwidth by not getting the same events 10 times. However, I started thinking if it would make more sense to just implement negentropy in the browser and nostr-rs-relay. It's more efficient sync, but more difficult to implement. I think { not: { ids: alreadyHave }} might be the main use case for the not filter. One consideration is that the "not" part might be so large that you need to discard it on the relay after eose. Any other use cases for not filter? Maybe excluding muted authors from a global query, but not sure if worth it.

What are your favorite steak knives?

If you don't have Nostr push notifications yet, you can get them from Iris and Snort web versions. You can subscribe to notifications by going to the Notifications page, or Settings / Notifications on Iris, where you can also check the subscription status. On iOS, you need to save Iris / Snort to the home screen in order to enable notifications. Notifications are currently sent from all mentions, replies, DMs and zaps.