Martti Malmi

@npub1qg8…24kw @npub1exc…n72a @npub1xts…kk5s @npub12rv…85vg @npub1qny…95gx @npub1c87…8avm @npub1l2v…ajft @npub18am…p424 @npub10vl…sp42 @npub1cj8…rz4u @npub1lr2…dl6a @npub16vr…p2va @npub1szp…h3td @npub1cn4…3vle @npub1sg6…f63m @npub1cjw…j2rh @npub1a2c…w83a @npub1e0z…0txy @npub1wg4…6a4f @npub1sn0…jdv9 @npub1dg6…sguz

2024-11-18 07:33:04 GMT

Always wanted to visit Finland, the land of 5 million people and 3 million saunas? Now’s the perfect chance.
BTC HEL, the largest Bitcoin conference in the Nordics, will take place in Helsinki for the first time on August 15–16, 2025.
Join us in orange-pilling Finland before the anti-crypto narrative has a chance to catch on, like it has in other Nordic countries.
We have a positive and true story to tell: Bitcoin can make even renewables more profitable and balance the power grid. In the North we can use up all the excess heat. All the while, sound money fixes short-sighted fiat culture.
Please DM @npub1w2e…pmgp or email [email protected] if you’re interested in speaking! Flights and hotel are covered for speakers.
Tag the people you’d like to see there!
Sign up for the mailing list to know when the ticket sales begin: https://btchel.com
https://image.nostr.build/fd016e6c41a5010cdeeae1eeee5066a35d38db7b240ba04c946a9d5520df8bba.jpg
https://image.nostr.build/1192f7cc27b490ede3286160769996f12d1dd8687830a461cf9eea01f52a7dd4.jpg

2024-10-28 11:49:56 GMT

- reply

Toxicity 🔥
https://video.nostr.build/1d605c049c58762159fe48e99b96d75fc67ea4cf11c6128067d37c6db763592c.mp4

2024-10-23 10:33:58 GMT

- reply

Also I think I want to do a LMDB version of this: https://github.com/mmalmi/nostr-social-graph/blob/master/src/SocialGraph.ts
Can be used as a strfry web of trust filtering plugin.

2024-10-19 08:55:46 GMT

- reply

And one-click zap with other wallets too

2024-10-19 08:55:25 GMT

- reply

Yes, being able to one-click-zap using the Cashu wallet would make it a lot better. I just probably don't have the time to do it anytime soon 😬

2024-10-19 08:34:54 GMT

New Iris version source code is here. Now you can fix your favourite annoying bugs: https://github.com/irislib/iris-client

2024-10-14 08:25:21 GMT

- reply

#nevent1q…kt8k

2024-10-14 08:00:01 GMT

- reply

We should have had @npub1l2v…ajft on stage to boost our energy 😄

2024-10-14 07:53:57 GMT

- reply

Yeah, we are often our own worst critics when others don't care so much. It's healthy to learn from mistakes, but also to get over them. I've had difficulty with the latter and found that talking about things helps in the process, even if it can be uncomfortable.

2024-10-14 07:42:44 GMT

- reply

I mentioned it later on the panel: building applications that move money and taking a cut of them, even if it's a voluntary donation that's enabled by default.

2024-10-14 07:39:04 GMT

Fug... now that I'm home, I woke up last night to reflect on past cringes. On the main stage panel in Amsterdam I forgot what I was about to say (how to make money with Nostr) after already starting my answer and ended with "and umm yeah [awkward silence]". Should have re-asked the question.
I'm quite sensitive to cringe, but fortunately those moments have been mostly off stage since Slush 2014 which was pretty bad (or maybe I just haven't noticed). I'm not the best speaker, but I'll try 😄 Come see me in Lugano next week!

2024-10-13 19:50:57 GMT

- reply

So it would actually be a general notification service, not just web push

2024-10-13 19:46:05 GMT

- reply

For those who don't do push notifications, it could send email, sms or fax

2024-10-13 19:21:23 GMT

Random dev thoughts: Would it be a good idea to do an open source web push notification server for Nostr?
It could have fine-grained options for what notifications you want, from whom and how often.
It could be used automatically in the background by a client, or through its own web UI. Clicking the notifications would redirect you to the client of your choice.
It would be a lot like a relay in that it needs to match incoming events to a potentially large amount of subscriptions. Subscriptions would be persisted in a database and maybe managed over a REST API.
In addition to the stuff typically sent over Nostr, you need to send the subscription object and other things like notification frequency, maximum social graph distance or score, minimum zap amount to notify etc.
It would connect to other relays and maybe also have a websocket endpoint for receiving events over Nostr protocol.
Extending strfry into this direction crossed my mind, but maybe something like Django (or whatever web framework you're familiar with) would be better, as we need to persist the subscriptions.

2024-10-12 07:39:50 GMT

- reply

If you want to use multiple Nostr clients for the same double ratchet or MLS chats, they can technically be different members of a group. MLS would handle that better especially as groups get larger and numerous.

2024-10-12 07:24:39 GMT

- reply

It's a step in the right direction, but it still reveals the recipient and doesn't do key rotation, so all your message history and future messages are revealed if your main Nostr key is ever compromised. It's a tradeoff between security and availability. I'd personally choose Signal-style key rotation.

2024-10-12 07:19:01 GMT

- reply

True, I forgot to mention that with double ratchet or MLS we can solve the metadata privacy on Nostr. Working on double ratchet, already deployed on Iris: https://github.com/mmalmi/nostr-double-ratchet

2024-10-12 07:17:12 GMT

- reply

Absolutely, I should have mentioned that with double ratchet and MLS we can solve the metadata issue on Nostr. Working on double ratchet, already have single ratchet on Iris. https://github.com/mmalmi/nostr-double-ratchet

2024-10-11 16:46:43 GMT

- reply

You can use disappearing messages if you're worried about device access. Disappearing messages require ratcheting, otherwise the message history will be found on relays and decryptable. Ratcheting protects your past and future messages even if your main key is stolen by a compromised client or one-time device access.
On Signal, maybe someone who borrows your phone could link another device without you noticing? Idk. But double ratchet still protects from all the other scenarios.

2024-10-11 16:09:48 GMT

- reply

What would this attack look like in practice, against Signal for example?

2024-10-11 08:10:54 GMT

- reply

No, we use temporary keys that are rotated and only live on device. Main key is only used for authentication on the first key exchange.

2024-10-11 03:50:11 GMT

- reply

Temporary npubs are quite similar to message queues. Maybe you could also send a "delete" event to relays after receiving a message.

2024-10-11 03:37:48 GMT

- reply

We can use temporary npubs that are not linked to long-term identities and rotate them all the time. Iris.to messages already do that. The code is here: https://github.com/mmalmi/nostr-double-ratchet

2024-10-11 03:25:39 GMT

- reply

That's easy to do on Nostr with secure messaging protocols like double ratchet and probably MLS. Just add "create anonymous chat" in the UI.
It's just that relays can probably figure out who you are if you also make other Nostr requests. Maybe need a different client and relays if you want to avoid that.

2024-10-11 03:18:20 GMT

Secure DMs and groups might be how Nostr wins. Like Signal, but better: no phone number or centralized service provider needed. Actually there are no publicly visible user IDs involved, so in that regard it's similar to simplex.chat.
Unlike public messaging, DMs do not depend on the network effect. Great for onboarding people and keeping them returning with push notifications. They get a bitcoin wallet, zaps and all the other Nostr greatness on the side.
Many people don't want to let go of their existing follower base on X, but "Nostr DMs only" is easier to do. I could imagine that becoming a thing in the Bitcoin scene at first.

2024-10-10 12:09:05 GMT

- reply

Can MLS be done using only nostr-tools primitives like DH and hkdf?

2024-10-10 11:59:12 GMT

- reply

I’ll definitely look into MLS

2024-10-10 11:58:11 GMT

- reply

I’m very uncomfortable using DMs that don’t have forward secrecy. That builds up a growing trove of private message history that will all be revealed if your key is ever compromised, increasing the potential harm with every message.

2024-10-10 10:14:07 GMT

- reply

This is right next to the conference venue, which is a beautiful old brick building

2024-10-10 10:12:29 GMT

Got a bit awestruck again by the combination of natural beauty and a city built for humans by all the generations before us. We need a renaissance of beautifully built environments.
https://video.nostr.build/c83e3e13ed65932f234e1107e305724d1309ca15bc20087135bdbee1ffdae5de.mp4

2024-10-09 15:54:11 GMT

- reply

Double ratchet is simple to implement and works well for 1-on-1 chats. MLS is better for groups. In case the MLS is also good for 1-on-1, happy to change.

2024-10-09 15:41:34 GMT

I'm at Bitcoin Amsterdam, but spent half the day finishing some Signal-style double ratchet messaging.
Deployed an experimental version on https://iris.to. You can create chat invite links and give them to friends via QR or other messaging. The UI is still lacking and glitchy, but just had to demo at the conference.
The chats cannot be publicly linked to either participant, and even if your main Nostr key is revealed, the content and existence of past messages stays hidden.
https://image.nostr.build/b4533acd973793f7114fd5c272ccd5b5045ea0bd127c214e8314fc4c8282a354.png
https://image.nostr.build/ded8c0437548cb1359d34b43b966b64f798cd2f98ae5f859771f47cc551cd5bd.png
https://image.nostr.build/4458f2de8f4d424aff137d2d7ed283dd27501e1abc0a43234405008614a5cb70.png
Also published npm package nostr-double-ratchet 0.0.1: https://www.npmjs.com/package/nostr-double-ratchet
It's not actually double ratchet yet, but the single ratchet already achieves forward and backward secrecy.
The second ratchet would help secure the latest consecutive messages by same author, in case a message key for the most recent of their messages is compromised. That makes disappearing messages or manually deleted messages more secure. I guess we'll have to do it so we can say "Signal-level security".
This is obviously not tested or audited yet, but probably it's not worse than normal Nostr DMs 😅
You can take a look at the source code, but I'll write a better technical description later. It's using existing Nostr cryptography + some key derivation stuff. Chat invites use gift wrap -like arrangement addressed to the inviter's temporary session key. https://github.com/mmalmi/nostr-double-ratchet

2024-10-07 19:26:32 GMT

How to do millisecond timestamps on Nostr? 🐒 In chats it's not unusual to send multiple messages during the same second, not to mention other stuff like games.

2024-10-07 05:06:51 GMT

- reply

Seems there's no whitespace before the url, so other clients interpret the leading part as part of the url.
Maybe Iris shouldn't highlight urls that don't have leading whitespace or linebreak, so users notice in the editor that something's wrong. (I actually used to have that check in my regex, but that broke other things in the library I used.)

2024-10-06 18:58:21 GMT

- reply

Gzip can however compress the text content of notes whether binary or json

2024-10-06 18:54:59 GMT

- reply

Event IDs, pubkeys and sigs are such high entropy data that gzip probably won't compress them much. Also binary formats are faster to decode than json (+ gzip).

2024-10-06 18:49:54 GMT

- reply

I believe we'll always have JSON for simplicity and backward compatibility. Simplicity is indeed important, it's why Nostr attracted developers. I don't think opt-in binary format supported by some clients and relays can break that. We already have many nips not supported by everyone.

2024-10-05 19:18:25 GMT

- reply

Fields like event id, sig, pubkey, p & e tags would be 50% smaller in binary vs utf-8 hex. Follow lists are currently quite large and their size would be basically cut in half.
But if we implemented NIP-114, we could save even 90% or more in bandwidth and some processing as well, depending on how many relays you connect to. Hoping to find some time for it again. https://github.com/nostr-protocol/nips/pull/1027

2024-10-04 07:06:20 GMT

- reply

You have a point. The user's own avatar is one of the first images shown on the page, in a certain size, so you could even guess the Nostr user.
Without the proxy, requests are sent to multiple servers, making it more difficult to associate everything the user does.
On the other hand, those other image hosts might include those that are built expressly for logging and tracking users. Popular service like nostr.build or imgur.com can do that kind of analysis anyway.
Using a proxy, you can at least choose which host(s) you trust. Ultimately, the choice of proxy should be configurable, just like relays. Image loading without proxy is privacy-wise somewhat equivalent to outbox model (or nip05) where you connect to random addresses that see your requests.
Relays also know a lot about what you're looking at, and you might even reveal your identity by authenticating. The only way I see around this is onion routing where Nostr requests would be relayed on behalf of others, so there's plausible deniability.
Associating network address to a geolocation is a feature of the internet protocol. Tor and VPNs (where you also need to trust a 3rd party) seem to be the only solutions to that.
When it comes to image proxying, file size is one very pragmatic consideration. Without a minimizing proxy, avatars can be 100 times larger. Maybe multi-resolution image formats are the best solution to that.

2024-10-03 13:49:38 GMT

- reply

They pretty much even copied the iris logo I had pre-nostr https://image.nostr.build/8d4bf8052c62821e9b0f42f142880040fae4ee659742efd662ca18980b4acdad.png

2024-10-03 10:48:13 GMT

- reply

Fixed these two

2024-10-03 09:33:51 GMT

- reply

Unfortunately, yes. The wallet is hosted on the same domain (iris.to), but it's a separate application running in an iframe. I haven't integrated it on the actual Iris side yet.

2024-10-02 07:47:16 GMT

@npub1h0u…rwx8 do you have a spec for the double ratchet protocol you're building?

2024-10-02 04:59:18 GMT

- reply

testing cmd+enter

2024-10-02 04:58:15 GMT

- reply

#nevent1q…kema

2024-10-02 04:57:19 GMT

Fixed it for you
https://image.nostr.build/17202defe2d4295a3fd83b7bb4bbc3b982a724e14f940d35e05c8174e1c9ec33.png
Upload is fast, but nostr.build takes some time to check the image and return the url
https://image.nostr.build/1cc298a7cce6d0519962f410fc1be085d1c9e3d24a743009e920865c1edbd82f.png
#nevent1q…6wzz

2024-09-30 18:59:49 GMT

- reply

Zap.army

2024-09-30 17:50:05 GMT

- reply

They're separate codebases again. Iris uses NDK and Snort uses the Snort system (also available as a library).

2024-09-30 16:48:03 GMT

- reply

There's no download indicator but it should be downloading https://files.iris.to/large_social_graph.json. You can also try downloading from that link and feeding to "load from file".

2024-09-30 16:41:44 GMT

- reply

It’s so large that it crashes the mobile browser though 🤷‍♂️

2024-09-30 16:31:55 GMT

Added to https://iris.to and https://graph.iris.to the option to download a large pre-crawled social graph with 161K users and 5.25M follow relationships.
https://image.nostr.build/c937f408d0543e06c86ae4df700d3ead8e61122c53fe7d1c54e3bb7382c487a4.png

2024-09-28 13:45:40 GMT

- reply

Forward secrecy means that compromise of a long-term key doesn't reveal past messages. Signal does provide that. It's a different category of attack if someone gets access to your device and sees your chat history, or tricks you to link an untrusted device.
Export is possible in any client, at the very least with screenshots or by writing the message history on a piece of paper, but that's not related to forward secrecy. Disappearing messages is the solution when you don't want your message history potentially seen by anyone later.
You can use a VPN to hide your geolocation from Signal (which you should do on Nostr as well if you need privacy), but it's true that they can connect your messages to your phone number, see when and probably with whom you're chatting. Not surprised if intelligence agencies are mining that data.
With Nostr we're at least over the phone number part, there's no single service that sees all traffic and there are different ways to fix the metadata issue — and do forward & backward secrecy when desired.

2024-09-28 09:16:19 GMT

- reply

Signal doesn't have forward secrecy if you can save a backup of your chat? I don't think that's the definition.

2024-09-28 09:14:24 GMT

- reply

How would you derive the address? Something like event.pubkey = publicKey(KDF(messageKey))? I imagine "mailbox address" would need to be the signer's public key so others can't spam the mailbox.

2024-09-28 09:09:13 GMT

- reply

There's nothing preventing users from moving to another DM client. You can always go back to the old client or export or copy paste message histories if you need them.
It's not comparable to Twitter or Facebook, because you own your identity key and can always change the client or relays.
There's always a tradeoff between availability and security of messages, and maybe there are different use cases for both kinds of messaging. On Nostr, we are free to choose.

2024-09-28 08:38:40 GMT

- reply

Actually even without device linking, I'd rather use forward-secret messages even if they're out of sync with some other client.

2024-09-28 08:37:22 GMT

- reply

They can only see message history as far as the linked device allows and can't see future messages if the device unlinks. I don't know the exact details how Signal does this, but I don't think its forward and backward secrecy is broken because of the feature.

2024-09-28 08:27:28 GMT

- reply

Maybe we can have something like Signal for connecting sessions on different devices / clients so they see the same messages.

2024-09-28 08:15:46 GMT

- reply

I guess cryptographic forward & backward secrecy would be the most important addition, along with hiding the recipient metadata. I see Jeff started double ratchet at https://github.com/nostr-protocol/nips/pull/1206 and moved on to MLS. I'll take a look.

2024-09-28 06:59:05 GMT

- reply

Deriving a single-use public key for signing each Nostr event would have the advantage of messages not being linked to any other message or user, though.

2024-09-28 06:56:42 GMT

- reply

Am I right that nip-17 reveals the message recipient public key?

2024-09-28 06:56:12 GMT

- reply

What attack does the symmetric ratchet protect from? If your device is compromised, your message history will be revealed anyway.
Maybe it would help in the case when you locally delete earlier messages in a chain ("disappearing messages" or otherwise) but they're still on relays.
Maybe I answered my own question, but is there something else besides this?
Why not more difficult? Implementing DH + symmetric ratchet is more complexity than just DH.

2024-09-28 05:56:17 GMT

Halp me understand double ratchet. What's the advantage over just periodically generating new keys and doing DH between them? Would be fairly simple to do on Nostr. Even if your main private key was stolen, your message history would be safe.
In addition to DH keys, double ratchet also has individual "message keys" and "sending/receiving chain keys". In what real-life scenario would they be compromised without also compromising all past messages on device?
https://signal.org/docs/specifications/doubleratchet/
https://image.nostr.build/c66a4b601a146bbd7bdb93122fa7b1d778355f75801deaa1298be7a09444f465.png

2024-09-28 03:33:32 GMT

- reply

Social graph is not just the people you follow (1st degree), but also people they follow (2nd degree) and so on.
Currently Iris loads up to 2nd degree by default. There's also a tool for crawling up to 3rd degree, but it consumes a lot of bandwidth and cpu. 2nd degree was 20K users and 3rd degree 160K users in my graph, so there's plenty of diverse voices.
Optionally we could show posts from unknown users who have a nip05 (e.g. [email protected]) from a bot-resistant provider. In a permissionless system like Nostr, we will always need to limit write access somehow or it will be filled with spam.
https://image.nostr.build/1407ad9d130088eceff4a8f1d73dc4f546237b47db170c8f48313d38839695eb.png

2024-09-27 13:35:24 GMT

Added a tool for crawling the follow lists of your friends-of-friends. My graph of 160K users and 5M follow relationships is 36 MB on disk.
https://image.nostr.build/1407ad9d130088eceff4a8f1d73dc4f546237b47db170c8f48313d38839695eb.png

2024-09-27 09:28:15 GMT

- reply

I made the borders rgba(255,255,255,0.2) in Iris theme

2024-09-27 08:27:10 GMT

- reply

It sets npub.cash address only when you create a new user on Iris. Maybe it could suggest npub.cash address for existing users who don't have a LN address yet.

2024-09-27 07:49:24 GMT

Rolled out new https://iris.to version:
* Zero-configuration zaps for new users: comes with a [npub]@npub.cash lightning address and an integrated Cashu wallet (cashu.me)
* ReplyGuy-free experience: automatically hides content by users not in your social graph
* "Unseen" feed. Click "home" or switch tabs to refresh.
* "Adventure" feed. Shows content from everyone in your social graph.
* Social graph based fast user search
* Better scroll position retention on back navigation
"Add to home screen" for better mobile use experience & push notifications.
This new version is based on NDK. I think it's a good idea for web devs to work together on shared core libraries.
Not perfect, but I'll keep working on it! If you preferred the previous Iris version, you should use https://snort.social which is basically it.
https://image.nostr.build/2f997643856deed77cbb27eb68549fe5def27b3464f1d88d716c80badac0d354.png

2024-09-27 07:46:43 GMT

- reply

Apparently cashu.me is not nip-60 yet — is there some other wallet I should use on iris.to instead?
Is nip-60 on public relays a privacy tradeoff? I imagine it reveals when there's been activity in your wallet.

2024-09-27 06:41:16 GMT

- reply

Sorry that Iris doesn't have translations yet! Snort.social is basically the old version of Iris if you prefer it.

2024-09-26 07:58:14 GMT

- reply

Gift wraps don't hide recipient metadata, and you can guess who are talking to each other by timestamp correlation 👀
Creating a new shared keypair for each secret chat doesn't have this problem, but it can be tricky to keep track of all the keypairs between sessions.

2024-09-26 07:50:03 GMT

- reply

On the relay side, maybe allow nip-42 authenticated users to push gift wraps (where event.pubkey is not the authenticated user).
On the client side you need to process all incoming gift wraps and only check WoT after unwrapping. That adds some spam processing overhead unless you only connect to WoT relays.

2024-09-26 07:39:47 GMT

- reply

How do you make gift wraps work with WoT?

2024-09-25 16:38:59 GMT

If your client doesn't support WoT yet, at least you can use WoT relays.
#nevent1q…clk8

2024-09-25 16:18:30 GMT

- reply

Social graph filtering works great and doesn't require domain names or other trusted parties, but nip05 (maybe limited to trusted providers) can be one way to complement it for newbies who are not yet in the graph.

2024-09-25 09:30:26 GMT

- reply

Yes; he's not only a translator, swordsman and academic, but also an artist!

2024-09-24 04:31:14 GMT

- reply

I was thinking about bitcoin mining style PoW which some have suggested, but actually I'm concerned it might hinder normal users more than spammers. There was a PoW-based anonymous reddit once, but it was filled with spam. https://github.com/notabugio/notabug

2024-09-24 02:04:54 GMT

- reply

Have you configured CORS headers? It's necessary to allow requests that originate from other domains like iris.to or snort.social.

2024-09-23 17:52:29 GMT

- reply

Basically a domain-name based Nostr username, get one for free at https://iris.to/free-nostr-address

2024-09-23 17:46:25 GMT

- reply

It's best if they can be introduced by someone, or get noticed by zapping.
Secondarily, messages from users who have a nip05 from a bot-resistant provider like iris.to, or provided a sufficient proof-of-work, could be scored higher, at least within the "messages from unknown users" pool.

2024-09-23 17:00:00 GMT

I had such a cool translator @npub16ww…5cht at #nostrasia2024!
https://image.nostr.build/11922ffeb7d0ed6a0384c51f6b63889c191e115a3dd7433947bfda5a73401423.jpg

2024-09-23 15:43:51 GMT

- reply

Yes. It actually limits to 5th degree so basically everyone who's somehow connected. It only initially downloads up to 2nd degree follows though, and then further when you visit their profiles. I could make these parameters configurable.

2024-09-23 15:39:08 GMT

- reply

It only shows content from authors who are in your social network. Nostr-social-graph library https://github.com/mmalmi/nostr-social-graph

2024-09-23 15:35:53 GMT

try https://beta.iris.to for a replyguy-free experience

2024-09-22 10:46:12 GMT

- reply

Approved

2024-09-22 03:14:44 GMT

https://image.nostr.build/66fc8265b4f9e0d9c89a10e0471d4c30f2be04febcd8dac4cd4377a62bf814ee.jpg #BitcoinTokyo2024

2024-09-21 02:46:12 GMT

- reply

Test

2024-09-18 14:14:24 GMT

- reply

It's just embedded as a /cashu subdirectory & iframe in the user interface. I'd like to make it more seamlessly integrated, so you could quick zap, show the balance and automatically redeem incoming zaps from npub.cash without the wallet page being open.

2024-09-18 14:04:36 GMT

Should I use nuts.cash @npub1wun…qhq8 instead of cashu.me as the integrated wallet in beta.iris.to?

2024-09-18 13:33:39 GMT

- reply

Just made it fetch missing follow lists from your follows when you change current user

2024-09-18 13:16:23 GMT

- reply

for clarity 🐒
purple: you and your follows
orange: followed by at least 10 users you follow
gray: followed by at least 1 user you follow

2024-09-18 13:14:49 GMT

- reply

Yes. Purple for yourself and followed users. Orange for users that are followed by users who are followed by at least 10 users you follow, and gray for at least 1.

2024-09-18 12:54:32 GMT

https://image.nostr.build/5b27a090cdf43f8268fdaf5b3ab0ae832e14acd3e490035610a6c8ee1ccae24e.png
https://image.nostr.build/12d0aeaa4c9a8c406b3588ee7aa82960afbd18950bd7789583cd9a795038555b.png
Published npm package nostr-social-graph and its demo on https://search.iris.to
It builds a social graph from Nostr follow events. You can query followed users, followers and follow distances. You can change the graph root user, efficiently calculating new follow distances.
It maps public keys to integers as internal representation, consuming less memory and storage when serialized. My graph of 23 000 users and 120 000 follow relationships is 2.2 MB on disk.
The package also includes pre-crawled datasets of follows and profiles that you can optionally use. They're used on https://beta.iris.to and https://search.iris.to for hydrating the search index and profile cache.
https://beta.iris.to uses the social graph for filtering of replies and notification, so you don't need to see that reply guy again (unless he's followed by people you follow — need to add "muted by followed users" support).
https://www.npmjs.com/package/nostr-social-graph
https://github.com/mmalmi/nostr-social-graph

2024-09-16 08:32:57 GMT

- reply

Yes 👍

2024-09-16 05:36:31 GMT

As clients implement WoT filtering based on follow lists, the meaning of "follow" might become more like "endorsement", whether we like it or not. Your followers might complain / unfollow if your follows bring unwanted content to their feed. Other lists would be used when you just want to follow without endorsing.

2024-09-16 02:27:12 GMT

おはようございます ☕️ Woke up at 5 am Helsinki time to adjust to Tokyo time.

2024-09-15 14:56:17 GMT

- reply

I'm hosting it myself, so it can access the nsec stored on the same domain and works without configuration. Enabled npub.cash and Coinbase exchange rate by default.