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 @btchel or email hello@btchel.com 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.comhttps://image.nostr.build/fd016e6c41a5010cdeeae1eeee5066a35d38db7b240ba04c946a9d5520df8bba.jpghttps://image.nostr.build/1192f7cc27b490ede3286160769996f12d1dd8687830a461cf9eea01f52a7dd4.jpg
I wonder why they did not build on Nostr keys and events. Anyway, the pubkey-dns resolver is super cool! It should be complemented with a browser extension for looking up public keys in your social graph.
Daily dev thoughts: Nostr notification server should probably connect to relays and let them do what they do best: filter -> subscription matching. On the notification server you'd just match the subscription ID to notification endpoints. Resubscribe everything if the relay websocket reconnects.
If you're self-hosting and only have a small number of notification subscriptions (less than 20 or so), you can connect to public relays. If you're running a notification server for 1M users, you'll need your own private relay that has no subscription limit.
I'm thinking of pubkey -> [notification subscription JSON] database. Pubkey is client & session specific, not linked to a Nostr public identity.
What DB to use? I want it to be easy to self-host (docker at minimum) but also scaleable, so it can be the default notification server of a client. Efficient persistence is an obvious requirement. LMDB seems like a good option, but on the other hand MongoDB has lots of existing tools for administration, monitoring, indexing, JSON handling etc.
@jb55
Such an inspiring story!
nostr:nevent1qqst0fu00sezruj3c6xfqhcreegcmjdk75s8zyeh0y5xzsgutwpmx9spz9mhxue69uhkummnw3ezuamfdejj7q3qlelkh3hhxw9hdwlcpk6q9t0xt9f7yze0y0nxazvzqjmre3p98x3sc9d2c7
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.
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.
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!
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.
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.
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.
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
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.
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
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.
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
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.
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.
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.
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.
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.
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.pnghttps://image.nostr.build/ded8c0437548cb1359d34b43b966b64f798cd2f98ae5f859771f47cc551cd5bd.pnghttps://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
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.
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.)
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).
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.
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).
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.
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
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.
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.
Oddbean new post about login | logout
Notes by Martti Malmi | export