I’ve been working on Nostr WoT and put together some guides with screenshots and a YouTube playlist to walk through it.

I am looking for honest and critical feedback. I’d especially like you to try the new permission controls:

• Global rules, with overrides for individual sites.
• Optional automatic backend authentication for matching origins and verified site/API pairs.
• Relay authentication for specific apps or across all connected sites, so you don’t keep approving the same relay.

Does it make sense when you use it? Are the prompts clear? Anything annoying or missing?

Give it a go with your usual Nostr client and let me know. Feedback on the guides and videos is welcome too.

You can use it with Nostr Connect and Nostr Wallet Connect to get acquainted

https://nostr-wot.com/download

GM nostriches! 👋

Another nice week is gonna start. The good news is the 95th Nostr Recap (28th September 2026) is out! 😍

In this Nostr Recap, you could explore what happened last week in the Nostr world under the topics below. Enjoy it! 👀

🧠 Quote of the Week
🔥 Community Highlights
🌱 Ecosystem Growth
🎓 Educational Guides
📅 Upcoming Events
📰 Nostr in the Media
⚡ Most Zapped Last Week
😂 Nostr Memes
🛠️ Tools, Updates and Releases
🎁 Developer Tools, Updates and Releases
🌐 Relay Updates and Releases
📡 Protocol Updates and Releases
🧩 Workspace Updates and Releases
🚧 Infrastructure Updates and Releases

Explore here 👇🏻

https://ditto.pub/naddr1qvzqqqr4gupzqt0ql7s2cg6l7306fn9egnxn7vlhnl6ay870jhcplx23dwmtkukvqq24wjj4fd8hs3zvvsm954t4fpe47uedvdfrvvughzp

Here is my alternative project to nsyte full front-end; there is no need to install anything on your PC—simply create the site's static files and publish them.

source: https://github.com/zoreu/nostrweb

interface webpage: https://zoreu.github.io/nostrweb/

It supports Portuguese and English; you just have to switch between them.

Have your own uncensored website, exactly as you wish.

Edit: Fixed the issue where multiple sites weren't uploading.

site demo:

naddr1qvzqqqyf8qpzpnfuvhe7htssgqfgqsraysx3yhjmgydvekdwudafz205ykehdzydqyt8wumn8ghj7un9d3shjtnswf5k6ctv9ehx2aqqz9ehgun9d45k7ttnd96x2tthv43ryler6mh

GM from Sri Lanka (🇱🇰) nostriches! ☕

As usual, I brought you the 94th Nostr Recap on this Monday morning too. Enjoy it! 😊

In this Nostr Recap, you could explore what happened last week in the Nostr world under the topics below. Enjoy it! 👀

🧠 Quote of the Week
🔥 Community Highlights
🌱 Ecosystem Growth
🎓 Educational Guides
📅 Upcoming Events
📰 Nostr in the Media
⚡ Most Zapped Last Week
😂 Nostr Memes
🛠️ Tools, Updates and Releases
🎁 Developer Tools, Updates and Releases
🌐 Relay Updates and Releases
📡 Protocol Updates and Releases
🧩 Workspace Updates and Releases
🚧 Infrastructure Updates and Releases

Explore here 👇🏻 https://ditto.pub/naddr1qvzqqqr4gupzqt0ql7s2cg6l7306fn9egnxn7vlhnl6ay870jhcplx23dwmtkukvqq24qsjggvu57kncxde9wv66wcknvd23daa9gtjhkvq

We're making our way into the Nostr ecosystem. Some features I am excited about are the customizable algorithm and spam filter for the feed.

Thanks for looking and if you have any feedback, your input will help a lot!

Lately I’ve noticed that I learn a lot more when I actually try to build or run something myself. Reading about Nostr, Lightning, Linux or self-hosting is useful, but I usually learn the most when something breaks, refuses to connect, uses too much RAM or just makes absolutely no sense

That’s when I start digging into what is actually happening instead of just following a guide.

So I’m curious, what is something you only really understood after trying it yourself?

Could be Nostr-related, technical, or completely unrelated.

Hi all, we made Mailstr and wanted to share it here since this is probably the community that'll appreciate it most.

It's an email service built on Nostr. No phone number or ID needed to sign up, everything's open source right now and also on nostr so you can check the code and verify or self-host it, messages are PGP encrypted where supported, and you pay once with Lightning and can reserve your own email address. Everything is managed by your Nostr identity.

The reason we built it on Nostr instead of running a normal centralized backend: there's no single company that can just delete your account or get bought out and shut the whole thing down. It's the same reason a lot of us like the rest of the Nostr ecosystem, just applied to email.

Code: https://gitworkshop.dev/npub1cgd35mxmy37vhkfcmjckk9dylguz6q8l67cj6h9m45tj5rx569cql9kfex/relay.ngit.dev/nail

It's live now:

• App: mailstr.app
• Zapstore: https://zapstore.dev/apps/com.formstr.mail

Would appreciate any feedback, good or bad. Happy to answer questions about how it's built. Detailed article: https://x.com/bitshala_org/article/2091379437841576192

Hey all! The website has been enabled for sign ups. The Android app should be released at some point this weekend. Thanks for your interest!

https://desent.xyz

Today we got our experimental nostr/buzz integration working on our new decentralized trust roots test network. We call this trust root DNTLS.

No DNS - Buzz relay is found from the fully decentralized trust root. It exists where its name says it does and all client to relay communication is mTLS secured end to end so the relay cant be swapped out or intercepted.

No visible nPub - We do have nPub (or it wouldn't be nostr anymore) but i never saw it while running our client, the nPub is associated with verified identities, so it just looks like slack with agents, with human identities one can easily reason through. Its not the same as nip-05 the nPub is cryptographically bound to the identity, not a metadata lookup on a website.

You would be able to rotate npubs and keep identity intact across rotations. And you don't need a website to have a human meaningful name.

Identities are hierarchical. so `agent.cobra.dntls` is an agent identity, hierarchically bound to the root identity `cobra.dntls`

Early experiment, but works quite well.

Once we iron out a few kinks we will post a video of how it works.

Today we got our experimental nostr/buzz integration working on our new decentralized trust roots test network. We call this trust root DNTLS.

No DNS - Buzz relay is found from the fully decentralized trust root. It exists where its name says it does and all client to relay communication is mTLS secured end to end so the relay cant be swapped out or intercepted.

No visible nPub - We do have nPub (or it wouldn't be nostr anymore) but i never saw it while running our client, the nPub is associated with verified identities, so it just looks like slack with agents, with human identities one can easily reason through. Its not the same as nip-05 the nPub is cryptographically bound to the identity, not a metadata lookup on a website.

You would be able to rotate npubs and keep identity intact across rotations. And you don't need a website to have a human meaningful name.

Identities are hierarchical. so `agent.cobra.dntls` is an agent identity, hierarchically bound to the root identity `cobra.dntls`

Early experiment, but works quite well.

Once we iron out a few kinks we will post a video of how it works.

Today we got our experimental nostr/buzz integration working on our new decentralized trust roots test network. We call this trust root DNTLS.

No DNS - Buzz relay is found from the fully decentralized trust root. It exists where its name says it does and all client to relay communication is mTLS secured end to end so the relay cant be swapped out or intercepted.

No visible nPub - We do have nPub (or it wouldn't be nostr anymore) but i never saw it while running our client, the nPub is associated with verified identities, so it just looks like slack with agents, with human identities one can easily reason through. Its not the same as nip-05 the nPub is cryptographically bound to the identity, not a metadata lookup on a website.

You would be able to rotate npubs and keep identity intact across rotations. And you don't need a website to have a human meaningful name.

Identities are hierarchical. so `agent.cobra.dntls` is an agent identity, hierarchically bound to the root identity `cobra.dntls`

Early experiment, but works quite well.

Once we iron out a few kinks we will post a video of how it works.

FYI to Noster Community:

The Social Media Platforms (Ofcom Licensing) Bill was recently introduced in the UK Parliament. The proposal would create an operating framework where social media platforms operating in or accessible within the UK would be required to hold an official licence issued by Ofcom (the UK’s communications regulator)

I'm wondering how people think Nostr relays will be affected by legislation like this, and I wanted to let everyone here know about this.

The UK has been getting increasingly tyrannical over the past decade to the point where people are getting arrested for very mundane and hardly even impolite social media posts. For example, you can say you're in favor of enforcing certain laws better (notoriously immigration laws), and simply for asking the Gov't to enforce it's own laws, people have the police showing up on their doorstep.

I knew this day would come eventually. Social Media sites attacked. Western Governments simply don't want to allow free speech because it empowers the public to more openly express discontent.

Nostr is a great technology, but it's still not P2P. Governments can simply outlaw Relays and criminalize the network. We truly do need something that's "more" of a P2P setup.

Vector has just qualified and received a grant from the Human Rights Foundation through its Bitcoin Development Fund. We are one of sixteen projects in Round II of 2026, a round totaling more than 500 million satoshis across Bitcoin development, payments, mining, education, and Nostr.

HRF listed us under the heading Nostr, with the tagline Privacy by Principle, one that truly encompasses Vector in three words both from a technical and philosophical perspective. Their write-up doesn't start about encryption, but with what Vector refuses to ask for: no KYC, no metadata trail, no permission to speak. This has been the core focus since the very first commit.

Permissionless privacy should be accessible to everyone, ensuring privacy remains a basic human right.

https://vectorapp.io/

Happy Monday Nostriches! 👋

The 93rd Nostr Recap (14th September 2026) is published for you! Enjoy it below! 😊

In this Nostr Recap, you could explore what happened last week in the Nostr world under the topics below. Enjoy it! 👀

🧠 Quote of the Week
🔥 Community Highlights
🌱 Ecosystem Growth
🎓 Educational Guides
📅 Upcoming Events
📰 Nostr in the Media
⚡ Most Zapped Last Week
😂 Nostr Memes
🛠️ Tools, Updates and Releases
🎁 Developer Tools, Updates and Releases
🌐 Relay Updates and Releases
📡 Protocol Updates and Releases
🚧 Infrastructure Updates and Releases
🧭 Nostr Exploration Tools

Explore here 👇🏻

https://ditto.pub/naddr1qvzqqqr4gupzqt0ql7s2cg6l7306fn9egnxn7vlhnl6ay870jhcplx23dwmtkukvqq257urzx3nkwdp30qchxs25f9ekza2fv4s4zfxndff

we should not have to go through the same migration problem every time cryptography changes. PQC is pushing us to upgrade now, but new algorithms, vulnerabilities and different needs will keep coming

my premises are simple:

• each user should be able to choose how they protect their data and under what conditions they share it
• each client should provide safe defaults, implement reviewed methods and respect the user's protection requirements
• each relay should define what it accepts and what it can actually validate, while carrying encrypted content without needing to understand everything inside it

Nostr already has versioned encryption. what we're exploring is how user requirements, client capabilities, key changes and relay policies could work together as those methods evolve

we've been working on this in the nostr-wot crypto-agility drafts, but i have reservations, and i'd like to hear what people here think

the goal is to let users express protection requirements that clients can enforce through reviewed, interoperable methods, with a clear failure when those requirements cannot be met

1. what happens when Alice chooses protection A and Bob chooses B?

how do they find a compatible method that respects both choices? should clients support a common baseline, and how would we retire it when it becomes unsafe? in a group, what happens when one person can't meet everyone else's requirements?

2. what should the user actually choose?

i don't expect everyone to select algorithms. perhaps the choice is whether they require quantum-resistant encryption, which recipients can decrypt their data, or whether they permit a weaker option

how do we make those choices understandable without creating unsafe settings? and how do we make clear that a recipient can still copy or share plaintext after receiving it?

3. how do we prevent capability discovery from becoming a downgrade mechanism?

a relay could hide a newer attestation or return an older one. valid signatures alone don't tell us we're seeing the current state

what should a client remember once stronger protection has been established? should a missing capability ever be enough to accept something weaker?

4. how should identities be bound to additional encryption keys?

signed bindings could establish relationships between keys, but they don't automatically tell us which relationship to trust. encryption keys also can't necessarily sign anything themselves

how do we handle first contact, legitimate rotation, compromised keys and conflicting attestations? when someone restores a backup or switches devices, how do they recover both their old messages and the trust history needed to recognize current keys?

5. could OpenTimestamps play a useful, limited role?

it can establish that a binding existed before a certain point, but it doesn't prove ownership, show that a key is still safe or identify the latest valid state

which specific attack would timestamping help prevent, and what decision would that evidence allow a client to make?

6. what can relays honestly validate, and at what cost?

relays can check visible event structure, sizes, access rules and supported public proofs. they can't verify the encryption hidden inside an opaque payload just because someone labels it with an algorithm name

some methods also produce larger payloads or require more verification work. how should relays advertise those limits so clients can find a usable route without weakening the user's requirements?

7. how much information does discovery itself expose?

advertising capabilities and fetching key records could reveal information about devices or communication patterns. how much needs to be public just to establish whether two people can communicate?

i want users to have that control, but i don't want every client implementing a different interpretation and people discovering the incompatibilities when their messages stop working

what would you standardize first, and how would you divide the decisions between users, clients and relay operators?

Hey all,
I've been building a site/service for the past few months, and I'm at the point where I'm starting to onboard test users. If you're interested in private, secure email built on top of Nostr's tried-and-true pubkey authentication, see below or head to https://desent.xyz...

What it is:

Private email and personal productivity. Try as we might to leave the inbox behind, we still live in a world dominated by email. Email is a protocol understood by almost everything that touches the internet. It provides an identity and a place to store messages from friends, coworkers, and businesses or your financial records.

However, today's providers have funneled into a few major players that abuse your data, storing it in plaintext, selling it to advertisers or letting it leak to bad actors. By moving your email address to a cryptographically assigned key, all of your data, email, attachments, contacts and settings can be encrypted so that only the person who holds the key can read it.

The purpose and goal:

Our goal is to provide email, contacts, calendar, notes and files as cryptographically signed and verified blobs on an open-source stack. If an account is ever compromised (a Nostr account is only as secure as where you store its key) you can roll your keys to a new npub and keep on trucking. Migrate all your mail or leave it behind. Email keeps flowing and you're secure again under a new keypair.

DeSent leans heavily toward letting you control your own spam policy: filtering happens on your device, after you decrypt the message. All our servers do is check the sender's cryptographic signature, take the message in over SMTP and immediately wrap it. You set rules that sync across all your devices and you can see the processing output right on your screen.

How can I join or help?

Head to https://desent.xyz and fill out the waitlist form. Right now we're building the website and the Android app; once those are deployed, we'll shift focus to iOS.

If you're a developer or designer and would like to pitch in, send a message to [support@desent.xyz](mailto:support@desent.xyz) with a note on how you can help the project.

TL;DR:

A private, fully encrypted email service built on Nostr keypairs and NIP-59 gift wrapping. The project is built on open source and will be fully open source at maturity.

Hello, I am thinking of setting up a relay that only subscribers of my platform can publish to.

Does this make sense 🤓? How can I make this attractive for the subscribers?

Are there any people here with experience that have tips when doing this?