24hr report... 848,011 events.

Believe it or not, the hardest part of this in-app browser was matching the theme choice of the app.

Don't look now, but it looks like I can edit Amethyst's website from within Amethyst with Shakespeare, through Tor, of course.

I’m making the internal browser the default 4th button on Amethyst by default. Which Nostr web clients or nSites should be pre-listed on the blank screen for new users to explore the ecosystem beyond Amethyst with a single click? 👇

GN

There is a proposal by @hodlbod to simplify NIP-17 in exchange for less metadata privacy and safety for all users. These are real gains by have real tradeoffs, so we need your help. Today, NIP-17 is so private that the spec does not allow clients to download only a specific chat room. If you are talking to me in a DM, your client is downloading all the other chats you received just to discard most of it to display our chat. Because of that privacy by design feature, relays also cannot filter messages: there is no way for them to only accept your friend's DMs because they don't know. They cannot know. There is no way for relays to filter spam. In NIP-17, that's the work of the receiving client. The relay is absolutely powerless on purpose. The new proposal creates a public code for each 2 people messaging each other so clients can filter events by that code, simplifying and saving bandwidth. The issue is that this code is also visible to all other users and relays, who can now track a chatroom you participate on. Today, they already know one side of the conversation — your pubkey is visible. They know you are receiving. With this change, they can also cluster all messages from the same unknown sender into a single timeline, without decrypting anything. This means that they can also filter spam, but also means they can censor you by blocking messages from given senders they do not like. So, less privacy and less censorship resistance in exchange for easier time for devs + less bandwidth used + gains in spam control. On top of that, the new code works in such a way that the sender can now delete their messages to you and recreate them in the past or future. In the original NIP-17, once the sender sends you a message, the message is yours. They cannot delete it anymore. If your friend's key leaks in NIP-17, the attacker cannot change the history of DMs. But with this new change, they can. They can delete and rewrite the past. So, less historical safety in exchange for easier time for devs + less bandwidth used + spam control by relays. What do you think about this trade-off? Acceptable? not acceptable? Was I clear? It's hard to simplify these things... But we try:

GitHub

Update nip 17 to indicate that wraps should be signed with the conversation key by staab · Pull Request #2396 · nostr-protocol/nips

For discussion. This trades off some metadata hiding (watchers can now identify a single conversation over time) for spam prevention and the abilit...

@Final any chance you know the people at Acrescent to give us an account to ship Amethyst on? They don't seem to be accepting new dev accounts, probably due to the amount of trash out there, but maybe you can put a good word for us? :)

This GitHub keeps getting better! @jack would be proud. View quoted note →

Amethyst now fully supports Onion-Location headers! Websites, relays, and Blossom server operators: if you include your .onion address in your reply headers as Onion-Location, we’ll connect directly to the onion service instead of using a Tor network exit node. Better privacy, less friction.

GitHub

Add Onion-Location support for transparent Tor routing by vitorpamplona · Pull Request #3368 · vitorpamplona/amethyst

Summary Adds transparent Tor routing support by implementing the Onion-Location HTTP header (RFC 7686 / NIP-11). When a server advertises its .onio...

If I can get this Amy-LM to write napplets and nsites and then publish, this is going to be awesome. BTW, now you can use LLMs inside the Views it creates as well. You can ask it to load a bunch of events of any kind you want and then send it to the LLM to summarize or search for things you want.

Amy

Amy — a Nostr client that builds itself

No app to install, no server. Ask the built-in LLM for a feed, a profile card, or a publish box and it renders a live view instantly — routed ove...

If you are using NutZaps on Amethyst, the cashu option in zaps will only show if the receiver has selected mints to receive and if you and the receiver share a Mint. Otherwise, things just go through lightning, which defeats the purpose of using Cashu in the first place. So the best setup is to use cashu when you can (super private), then lightning zaps if that is not available.

lol, my claude just launched 80 agents... I guess this is it... no more AI for the week.

Feedback? View quoted note →

Which Nostr Signer has the best/more intuitive permission management UI?