Nostr notes by lostcause

#honeytrap - Trying again.... #nostrdev #alphasoftware

2026-02-22T21:53:08Z

#honeytrap - Trying again....

#nostrdev #alphasoftware

#honeytrap - a #nostr client that uses #bittorrent to assist in ...

2026-02-22T21:21:23Z

#honeytrap - a #nostr client that uses #bittorrent to assist in propagating content - taking load of relays

#nostrdev #alpha

Nostr event nevent1qqsz37ndf6mfycy6flhpkhr0z3szljde84h9me9rtczyzg9q3tms5yszyz6axnhdclv0s8825hknw76694f5a62fltsvt2em4c99w648gawt7kxvc3l

2026-02-02T10:47:11Z

Hello World #nostrbt

Nostr event nevent1qqsp39hhs7w6cdg7yfsg7a2g4uenxrpu6k9tl8869mfvvwqlf6ypsuczyz6axnhdclv0s8825hknw76694f5a62fltsvt2em4c99w648gawt7mw0c67

2026-02-02T10:27:02Z

take 2? trying again

Nostr event nevent1qqswjvrgnutaa603xfdzctcy3uqpm05xrp2pkxk4aakkt6s60uqklgszyz6axnhdclv0s8825hknw76694f5a62fltsvt2em4c99w648gawt7pdm32e

2026-02-02T10:20:50Z

Message from the CLI - hoping to see in the web client

Nostr event nevent1qqsdclgg4jf0dy2qlhgddpf2p9dcpc2c70tkrdkm2qg5hmmqpafhclczyz6axnhdclv0s8825hknw76694f5a62fltsvt2em4c99w648gawt765tm47

2026-02-02T10:16:39Z

This is from the BT client

Nostr event nevent1qqszmqkmge5u646yc4l3t5gw2xpydsfcuytyxvd5z9gd233dxpu5y0szyz6axnhdclv0s8825hknw76694f5a62fltsvt2em4c99w648gawt783gwkt

2026-02-02T08:09:02Z

Trying a post over #nostr-over-bt

Trying now with WebSeeding #bittorrent #nostr #notsrdec ...

2026-02-01T11:08:19Z

Trying now with WebSeeding #bittorrent #nostr #notsrdec #honeytrap

Trying again - this time with server backed storage #nostr ...

2026-02-01T08:53:59Z

In reply to nevent1q…kh9r
_________________________

Trying again - this time with server backed storage #nostr #bittorrent #honeytrap

Trying the P2P only version of media sharing in posts #nostr ...

2026-02-01T07:00:25Z

Trying the P2P only version of media sharing in posts #nostr #bittorrent #honeytrap https://honeytrap.3nostr.com

Need to fix media attachments???

2026-02-01T04:11:42Z

In reply to nevent1q…87ev
_________________________

Need to fix media attachments???

Trying some new - again. Using #bittorrent to support nostr ...

2026-02-01T03:11:04Z

Trying some new - again. Using #bittorrent to support nostr relays...

Shared post from pk_d...2a23

2026-01-31T09:58:42Z

In reply to naddr1qq…usav
_________________________

Shared post from pk_d...2a23

Testing the BT uploads ...

2026-01-30T01:03:19Z

In reply to naddr1qq…dsqe
_________________________

Testing the BT uploads
magnet:?xt=urn:btih:8d9bd01bfa5216e301a8e049bb2a1d8680c99d74&dn=asknostr_logo.png&tr=wss%3A%2F%2Ftracker.openwebtorrent.com&tr=wss%3A%2F%2Ftracker.btorrent.xyz&tr=wss%3A%2F%2Ftracker.files.fm%3A7073%2Fannounce&tr=wss%3A%2F%2Ftracker.fastcast.nz

Testing the new BT seeding for media ...

2026-01-30T00:34:01Z

In reply to naddr1qq…dsqe
_________________________

Testing the new BT seeding for media
magnet:?xt=urn:btih:6c0084bdd7d9d9b2861d6ee74a5163c7f36d8efe&dn=asknostr1.png&tr=wss%3A%2F%2Ftracker.openwebtorrent.com&tr=wss%3A%2F%2Ftracker.btorrent.xyz&tr=wss%3A%2F%2Ftracker.files.fm%3A7073%2Fannounce&tr=wss%3A%2F%2Ftracker.fastcast.nz

Got the Wallet going with NWC connections - @ mentions going - ...

2026-01-29T08:06:51Z

Got the Wallet going with NWC connections - @ mentions going - now just got to get the #threading properly sorted.

https://asknostr.3nostr.com

PWA state persistence - needs looking at

2026-01-29T06:20:30Z

In reply to naddr1qq…dsqe
_________________________

PWA state persistence - needs looking at

Nice - nested threading for replies - now the whole thread tree ...

2026-01-29T05:14:29Z

In reply to naddr1qq…dsqe
_________________________

Nice - nested threading for replies - now the whole thread tree isn't showing when replying to a specific sub thread...

Done

2026-01-29T05:13:36Z

In reply to nevent1q…cndp
_________________________

Done

Completed

2026-01-29T05:13:17Z

In reply to nevent1q…v056
_________________________

Completed

Completed

2026-01-29T05:13:01Z

In reply to nevent1q…w2sv
_________________________

Completed

asknostr is coming along nicely... #hashtags are working - and ...

2026-01-29T03:55:45Z

asknostr is coming along nicely... #hashtags are working - and now - uploads as well it seems...

Working

2026-01-29T03:33:13Z

In reply to nevent1q…x20d
_________________________

Working

These should now be done #fingerscrossed

2026-01-29T03:26:33Z

In reply to nevent1q…987y
_________________________

These should now be done #fingerscrossed

One of favourite things about #vibecoding - is the rapid ...

2026-01-29T03:05:21Z

In reply to naddr1qq…5kyj
_________________________

One of favourite things about #vibecoding - is the rapid iteration developing... Get an idea - make the change -deploy...

Need to deal with media kinds? K:4550? Post rendering? Publishing ...

2026-01-28T23:03:37Z

In reply to naddr1qq…dsqe
_________________________

Need to deal with media kinds? K:4550?

Post rendering?
Publishing if the only content is media?

Need to check it out more

Main community feeds - need to just have the root post - not all ...

2026-01-28T22:49:07Z

In reply to nevent1q…987y
_________________________

Main community feeds - need to just have the root post - not all the commenting posts as well 🤔

And blocked users - should be stripped from feeds...

2026-01-28T22:47:41Z

In reply to nevent1q…987y
_________________________

And blocked users - should be stripped from feeds...

And response to thread - missing file/media uploaded icon

2026-01-28T22:28:52Z

In reply to nevent1q…987y
_________________________

And response to thread - missing file/media uploaded icon

Also need to truncate the nostr events - resolve nubs to profile ...

2026-01-28T22:28:08Z

In reply to nevent1q…987y
_________________________

Also need to truncate the nostr events - resolve nubs to profile names

Also need to check the undo reactions??

2026-01-28T22:20:56Z

In reply to nevent1q…987y
_________________________

Also need to check the undo reactions??

Need to add - in Posts↩️ hashtags @ mentions

2026-01-28T22:19:14Z

In reply to naddr1qq…dsqe
_________________________

Need to add - in Posts↩️

hashtags
@ mentions

Broadcasting from the global feed of asknostr app ...

2026-01-28T22:16:28Z

Broadcasting from the global feed of asknostr app https://asknostr.3nostr.com

The #Reddit style #nostr client

Shared post from pk_b...5cbf

2026-01-28T21:02:57Z

In reply to naddr1qq…zksw
_________________________

Shared post from pk_b...5cbf

Here's a tip when using asknostr - swiping 'back' and ...

2026-01-28T20:45:35Z

In reply to naddr1qq…zksw
_________________________

Here's a tip when using asknostr - swiping 'back' and the section title area will take you back a step...

Publishing from asknostr - the reddit styled nostr client!!

2026-01-28T11:30:07Z

In reply to naddr1qq…7agn
_________________________

Publishing from asknostr - the reddit styled nostr client!!

Seems maybe don't need the reply button - change it to share ...

2026-01-28T10:49:03Z

In reply to naddr1qq…zksw
_________________________

Seems maybe don't need the reply button - change it to share to Community??

Slowly but surely - getting better

2026-01-28T10:30:41Z

In reply to nevent1q…shra
_________________________

Slowly but surely - getting better

Visit https://github.com/imattau/asknostr for the code

2026-01-28T08:03:58Z

In reply to naddr1qq…lhdp
_________________________

Visit https://github.com/imattau/asknostr for the code

Approved

2026-01-28T07:54:24Z

In reply to naddr1qq…lhdp
_________________________

Approved

Check out the mod here at https://github.com/imattau/prism

2026-01-28T07:15:47Z

In reply to naddr1qq…lhdp
_________________________

Check out the mod here at https://github.com/imattau/prism

Bit buggy at the moment

2026-01-27T13:22:27Z

In reply to naddr1qq…zksw
_________________________

Bit buggy at the moment

Need to get the bugs out of this

2026-01-27T13:19:12Z

In reply to naddr1qq…zksw
_________________________

Need to get the bugs out of this

Question?

2026-01-27T12:36:29Z

In reply to naddr1qq…jtf0
_________________________

Question?

First post for the win?

2026-01-27T11:54:50Z

In reply to naddr1qq…jtf0
_________________________

First post for the win?

asknostr. The reddit styled nostr client...!!

2026-01-27T10:30:06Z

In reply to naddr1qq…jtf0
_________________________

asknostr. The reddit styled nostr client...!!

Asked #Gemini to review the @nprofile…tdaq project - and tell ...

2026-01-19T03:07:30Z

Asked #Gemini to review the fed_AI (nprofile…tdaq) project - and tell me about it in simple terms.... I like what it came up with ->

fed_AI" is an experimental project building a decentralized marketplace for AI computing.

Think of it like Airbnb for AI processing: instead of paying one giant company (like OpenAI or Amazon) to run AI models for you, you can rent computing
power directly from independent operators around the world.

How it works (The 3 Main Players):
1. Clients (You): You have an app or a task that needs AI (like generating text, images, or processing data).
2. Nodes (The Workers): These are people running the actual hardware (from powerful GPU servers to simple home computers). They do the work.
3. Routers (The Matchmakers): These are the traffic controllers. They find the best "Node" for your specific task based on price, speed, and trust. They
coordinate the work but never touch your money.

The "Secret Sauce":
* Nostr: Used for Identity. Your account is just a cryptographic key pair, so you own your identity and reputation across the network without needing a
central login server.
* Lightning Network: Used for Payments. You pay the workers directly (peer-to-peer) for exactly what you use (pay-as-you-go), instantly and with very low
fees.

What it hopes to achieve:
* No Vendor Lock-in: You aren't stuck with one company's rules or pricing.
* Privacy: The system is designed so that the "matchmakers" don't see your data or money, and the work is broken up across many independent providers.
* Efficiency: It allows anyone with idle hardware to contribute to the network, potentially lowering costs and democratizing access to AI.

In short, it wants to build an open, uncensorable, and free market for AI where anyone can participate as a user or a provider.

#fed_AI #AI #decentralised #privacy #v4v #nostrdevs

Nostr event nevent1qqstcnektsadt8zmwhngrz3mpj49sjzwnx4wqtvafmjjj8edmr3ss7szyz6axnhdclv0s8825hknw76694f5a62fltsvt2em4c99w648gawt7mphx7x

2026-01-18T05:34:53Z

While the content might be nonsense (it is a tiny LLM after all) - it does show that #fed_AI can function (at least locally)....

#ai #nostrdevs #decentralised #privacy #funny

Nostr event nevent1qqsdsl8vl2zavxr84spqzyqka5sw4plws7r04nj7s3zsd0p7rc6x82czyz6axnhdclv0s8825hknw76694f5a62fltsvt2em4c99w648gawt7a7t0uu

2026-01-16T23:02:54Z

#memes #vibecoder #vibecoding #meme #shortattention

@nprofile…7syv

2026-01-11T12:14:54Z

In reply to nevent1q…znqz
_________________________

prism (nprofile…7syv)

It really is a testament to the work done by @nprofile…2lxp on ...

2026-01-11T12:14:03Z

It really is a testament to the work done by VitorPamplona (nprofile…2lxp) on Amethyst (nprofile…wywf) that in the space of an afternoon - I was able to #vibe-code a functional video first app - just by refactoring #amethyst...

#naddr1qv…00cz

2026-01-11T04:46:53Z

quoting naddr1qv…00cz

AI-First Development on Mobile: Shakespeare Changes the Game

If you've tried using AI to build apps on your phone, you've probably been disappointed. A recent TechCrunch report found that dedicated mobile apps for vibe coding have largely failed to gain traction:

"Despite the massive success of vibe-coding startups on desktop (with billion-dollar valuations), dedicated mobile apps in this space have virtually failed to gain traction. The largest app, Instance: AI App Builder, has only 16,000 downloads and $1,000 in consumer spending. The consensus: vibe coding is not ready for prime time on mobile devices."

The data paints a bleak picture for mobile developers who want to build with AI. Most solutions are clunky, limited, or simply don't work well on smaller screens. But there's an exception that the mainstream hasn't discovered yet.

Shakespeare: The Mobile Exception

Shakespeare is a Progressive Web App (PWA) that installs directly on your phone and works like a native app. Unlike dedicated mobile coding apps that try to reinvent the wheel, Shakespeare leverages modern web technology to deliver a full development experience that actually works on mobile.

PWA - Installs on your home screen, works offline

Nostr Git - Sync projects between all your devices

AI Chat - Build entire apps through conversation

Live Preview - See your changes instantly on mobile

Getting Started: Install Shakespeare as a PWA

The first step is to install Shakespeare on your mobile device. Visit shakespeare.diy in your mobile browser and you'll see the option to install it as an app.

Step 1: Install the PWA

Open shakespeare.diy in your mobile browser

Tap the Install button when prompted (or use your browser's "Add to Home Screen" option)

Shakespeare will now appear on your home screen like any other app

Step 2: Sign in with Nostr

To sync your projects across devices, you'll need to sign in with your Nostr account. This enables Nostr Git, which lets you push and pull code changes from any device.

Open the menu and go to Settings

Select Nostr

Add your Nostr account by signing in with a Nostr signer extension or entering your nsec

Why Nostr? Nostr Git is a decentralized version control system that stores your code on Nostr relays. This means you own your code, can access it from any device, and don't depend on any single company's servers.

Step 3: Create or Import a Project

You can start a new project from scratch or import an existing one. If you've already created projects on desktop, you can import them directly using Nostr Git.

Create a New Project

Tap the + New Project button to start fresh. Just describe what you want to build and let the AI create it for you.

Import from Nostr Git

Click the dropdown arrow next to "New Project" and select Import Repository. You'll see your existing Nostr Git projects listed under "My Projects".

Simply tap Clone on any project to import it to your mobile device.

Step 4: Work on Your Project

Once your project is imported, you'll see a success message and be ready to start developing. Shakespeare on mobile has all the same features as desktop:

Live Preview

See your app running in real-time as you make changes.

Code View

Browse and edit your project files directly.

Terminal Access

Run commands like curl, hexdump, and git directly from your phone.

Syncing Your Work Between Devices

One of the most powerful features of Shakespeare is seamless device sync via Nostr Git. Any changes you make on your phone can be pushed to Nostr relays and pulled on your desktop (or any other device).

How Device Sync Works

Start on Desktop - Create your project and push it to Nostr Git

Continue on Mobile - Import the repository on your phone and keep building

Push Changes - When you're done, push your mobile changes to Nostr Git

Pull on Any Device - Your changes are now available on desktop or any other device

This workflow means you're never stuck waiting to get back to your computer. See a bug while you're out? Fix it on your phone. Have an idea during lunch? Start building it immediately. Your work follows you everywhere.

Why Shakespeare Works When Others Don't

The reason most mobile vibe coding apps fail is they try to recreate a desktop IDE experience on a tiny screen. Shakespeare takes a different approach:

Conversation-first interface - You don't need to navigate complex menus or type precise code. Just tell Shakespeare what you want in plain language.

PWA architecture - By running as a web app, Shakespeare works on any device with a modern browser. No app store approval delays or platform restrictions.

Decentralized sync - Nostr Git means your code isn't locked in anyone's cloud. It's stored on relays you choose and accessible from anywhere.

Mobile-optimized UI - The interface adapts to smaller screens, with easy switching between Chat, Preview, and Code views.

Ready to Code from Anywhere?

Join the developers who are building real apps on their phones with Shakespeare. It's free to try and works on any mobile device.

Try Shakespeare on Mobile

More Shakespeare Resources

Works on iPhone, Android, and any device with a modern browser.

This article was originally published on Soapbox.pub

Building on the awesome work of @nprofile…pt5w - ...

2026-01-11T04:41:47Z

Building on the awesome work of VitorPamplona (nprofile…pt5w) - prism (nprofile…yfuj) is a #video first scaled down version of Amethyst (nprofile…5eyg)

Still in pre...pre..alpha - you can build it from #github

#naddr1qp…8raf

2026-01-10T09:42:25Z

quoting
naddr1qp…8raf

If someone told you five years ago that developers would be writing code from the passenger seat of a Tesla and building custom dashboards on smart refrigerators at Best Buy, you'd probably assume they'd been spending too much time in the sci-fi section. And yet, here we are.

In the latest episode of Soapbox Sessions, Derek Ross and Heather Larson make one thing crystal clear: 2026 is the year of the builder. Not the year of talking about building. Not the year of planning to build. The year of actually rolling up your sleeves, firing up an AI assistant, and making things happen—even if "making things happen" means commandeering a retail appliance to prove a point.

What Exactly Is "Vibe Coding"?

The term sounds like something you'd hear at a tech conference after-party, but it perfectly captures what's happening across the decentralized tech space right now. Vibe coding is building on the fly, wherever inspiration strikes, using whatever tools are available.

Case in point: Soapbox team members Alex and MK recently found themselves in a Tesla, pulled up the browser, navigated to Shakespeare.DIY, and started building. No dedicated workstation. No carefully curated development environment. Just a vehicle, a browser, and an idea. The result? A working project and a new philosophy about what it means to be a developer in 2026.

The Great Smart Fridge Caper

Perhaps the most entertaining story from the episode involves an impromptu trip to Best Buy. The mission? Test whether a smart refrigerator could be used for actual web development.

Spoiler: it can.

The team accessed the fridge's built-in web browser, loaded up Shakespeare, and—using nothing more than a simple prompt—generated a custom refrigerator dashboard. Was it practical? Debatable. Was it hilarious? Absolutely. Did it prove that the boundaries between "serious development tools" and "IoT devices in your kitchen" are getting wonderfully blurry? Without question.

This kind of playful experimentation isn't just for laughs, though. It demonstrates something important about where technology is heading. When you can build functional web interfaces on literally any device with a browser, the barriers to entry for creators drop dramatically. Your next project might start on your phone, continue on a tablet, and get demoed on whatever screen happens to be nearby.

Building in Public: The Antidote to Perfectionism

Derek and Heather spend a good portion of the episode discussing the philosophy of building in public—sharing your work openly, documenting your experiments, and letting people watch you figure things out in real time.

There's something refreshing about this approach. Too often, we only see polished final products. We scroll past beautiful portfolio pieces without any sense of the messy middle that got them there. Building in public flips that script. It says: here's what I'm trying, here's what broke, here's what I learned, and here's what I'm doing next.

The Best Buy refrigerator stunt is a perfect example. Could the team have quietly tested this at home and only shared the results if everything worked perfectly? Sure. But where's the fun in that? By turning it into a public experiment—complete with the inherent risk of looking silly if things went sideways—they created a story worth telling and a moment worth remembering.

From Experiment to Application

Lest you think vibe coding is all party tricks and appliance hacking, Derek shares a more practical example: using Shakespeare to build a marketing website for Amethyst, a Nostr client developed by Vitor Pamplona.

The process was straightforward. Derek crafted a detailed prompt outlining what the site needed to communicate—the app's features, its benefits, its place in the Nostr ecosystem—and let the AI generate the content and structure. The result was a polished marketing site built in a fraction of the time traditional development would require.

This is where the "year of the builder" thesis really hits home. AI tools aren't replacing developers; they're amplifying what developers can accomplish. A single person with a clear vision can now produce work that previously required entire teams. That's not a threat to creativity—it's an invitation to attempt projects you never would have considered before.

The Takeaway

Whether you're a seasoned developer or someone who's never written a line of code, the message from this episode is clear: the tools are ready, the barriers are lower than ever, and the only thing standing between you and your next project is the decision to start.

Maybe you won't build your first app on a smart fridge. But then again, maybe you will. That's the spirit of 2026.

Soapbox Sessions is a podcast exploring decentralized communication, AI innovation, and the future of the open internet. Catch new episodes wherever you listen to podcasts.

Think I might travel around the #nostrverse and look for projects ...

2026-01-10T03:36:29Z

Think I might travel around the #nostrverse and look for projects to contribute too...

I've always thought that #opensource development sometimes spreads it's resources thin...

#vibe-coding

Well this was a fun little experiment... @nprofile…zqjr was ...

2026-01-10T03:20:08Z

Well this was a fun little experiment... 3nostr-searchbot (nprofile…zqjr) was #vibe-coded #AI based search bot... If anyone is interested in playing with the code - can download here at https://github.com/imattau/3nostr-searchbot

For me--- onto something else -> 👀

Hopefully - it's final reply is something useful - seeing I mentioned it in this post...

@nprofile…zqjr What are some good hashtags to follow?

2026-01-10T02:11:32Z

3nostr-searchbot (nprofile…zqjr) What are some good hashtags to follow?

What it @nprofile…j8e6 talking about?

2026-01-10T01:46:18Z

In reply to nevent1q…cqj4
_________________________

What it lostcause (nprofile…j8e6) talking about?

@nprofile…zqjr What is trending at the moment?

2026-01-10T01:34:34Z

3nostr-searchbot (nprofile…zqjr) What is trending at the moment?

@nprofile…zqjr Which is the most active conversation at the ...

2026-01-09T11:24:25Z

3nostr-searchbot (nprofile…zqjr) Which is the most active conversation at the moment? (That you know of)

What's -> A tech giant rolling out vendor lock to wall-in ...

2026-01-09T10:51:34Z

In reply to nevent1q…l896
_________________________

What's -> A tech giant rolling out vendor lock to wall-in developers, with the open-source community responding. - about?

@nprofile…zqjr Any updates for the question? Latest in the ...

2026-01-09T10:44:00Z

In reply to nevent1q…0xqp
_________________________

3nostr-searchbot (nprofile…zqjr) Any updates for the question? Latest in the world of open-source?

Do you have enough context now?

2026-01-09T10:30:01Z

In reply to nevent1q…9ljt
_________________________

Do you have enough context now?

@nprofile…k0dr What's going on in the world of open-source?

2026-01-09T09:18:05Z

3nostr-searchbot (nprofile…k0dr) What's going on in the world of open-source?

What do you mean?

2026-01-09T09:13:16Z

In reply to nevent1q…wc6a
_________________________

What do you mean?

@npub1znk…pytz since we last spoke - have you learned anything ...

2026-01-09T09:11:56Z

In reply to nevent1q…nvmj
_________________________

3nostr-searchbot (npub1znk…pytz) since we last spoke - have you learned anything more that can add to the conversation?

seems that 5 sats is not unlimited?

2026-01-09T08:47:44Z

In reply to nevent1q…ydnv
_________________________

seems that 5 sats is not unlimited?

Anything new happening now?

2026-01-09T07:45:53Z

In reply to nevent1q…qep9
_________________________

Anything new happening now?

Do you have any more idea now?

2026-01-09T07:10:36Z

In reply to nevent1q…97fy
_________________________

Do you have any more idea now?

@nprofile…6xp9 - What is trending on #nostr at the moment?

2026-01-09T07:02:39Z

3nostr-searchbot (nprofile…6xp9) - What is trending on #nostr at the moment?

@3nostr-searchbot help

2026-01-09T05:48:19Z

In reply to nevent1q…k7fw
_________________________

@3nostr-searchbot help

@nprofile…k0dr help

2026-01-09T05:39:39Z

In reply to nevent1q…0epj
_________________________

3nostr-searchbot (nprofile…k0dr) help

@nprofile…k0dr help

2026-01-09T05:07:28Z

In reply to nevent1q…0epj
_________________________

3nostr-searchbot (nprofile…k0dr) help

@nprofile…k0dr help

2026-01-09T05:04:58Z

In reply to nevent1q…0epj
_________________________

3nostr-searchbot (nprofile…k0dr) help

@nprofile…k0dr help

2026-01-09T05:01:01Z

In reply to nevent1q…0epj
_________________________

3nostr-searchbot (nprofile…k0dr) help

@nprofile…k0dr help

2026-01-09T04:54:05Z

In reply to nevent1q…0epj
_________________________

3nostr-searchbot (nprofile…k0dr) help

@nprofile…k0dr Are you online?

2026-01-09T04:51:51Z

3nostr-searchbot (nprofile…k0dr) Are you online?

One thing I like about #vibecoding If an app is missing something ...

2026-01-08T19:02:53Z

One thing I like about #vibecoding

If an app is missing something you want, you do not complain about it. You grab the source, add the feature, and use it.

Build instead of waiting.

#nostr #opensource #builders #dev

Start working on a new web app called #Binder ... Using existing ...

2026-01-08T10:15:51Z

Start working on a new web app called #Binder ...

Using existing #nostr primitives- it bundles long form content in a coherent 'book'

So far -

- auto save drafting - encrypted backup to relasy
- markdown editor and previewing
- New authors and hots reads
- and other stuff

Has been a fun exercise #vibe-coding #ai #codex #gemini

This is the first comment - on the first book - in binder... ...

2026-01-08T03:21:41Z

In reply to naddr1qq…k0dy
_________________________

This is the first comment - on the first book - in binder... Fingers crossed

Nostr event nevent1qqsgx9svy29446m0scxt9lug6nf7ttnjhx020zu9l8ddjv3ea4qwf9czyz6axnhdclv0s8825hknw76694f5a62fltsvt2em4c99w648gawt7hrcy4n

2026-01-04T11:27:40Z

NCC Sidecar v1.2.2 is live

This release focuses on backup integrity, recovery, and more reliable discovery for self-hosted services.

Encrypted backups by default
Node backups (Kind 30001) now use NIP-44 encryption. Managed service lists and configuration data are no longer published in plain text to relays.

Improved admin recovery
A new two-stage bootstrap flow allows full recovery after reinstall. Logging in is enough. Sidecar locates your encrypted bootstrap keys linked to your identity and restores state automatically.

Updated resolution engine
Now running ncc-06-js v0.6.0, improving discovery resolution, protocol filtering, and overall reliability.

UI refinements
Standardised theming for cleaner dark mode transitions, relay management restored, and a new “Copy NPUB” shortcut added to the dashboard.

The goal remains simple: make Nostr services easier to discover without compromising privacy.

#NCC06 #Nostr #SelfHosting #Privacy

https://www.npmjs.com/package/ncc-sidecar

Continuing on with Nostr Community Conventions 02 and 05 (#ncc) - ...

2026-01-04T09:16:57Z

Continuing on with Nostr Community Conventions 02 and 05 (#ncc) - I knocked up an NCC-VPN....

Technically a proxy service - it can intercept NCC address - <npub>.nostr and resolve using the NCC-02 Service Records and NCC-05 Dynamic Locators... Proving service without DNS is workable - using #nostr as the backbone!

https://www.npmjs.com/package/ncc-vpn - CLI client - npm install ncc-vpn

#nostrdevs #dns #privacy #decentralised

Stop Confusing Privacy & Anonymity (and Security) ...

2026-01-04T01:24:45Z

Stop Confusing Privacy & Anonymity (and Security)

https://neat.tube/w/4SmJxn7Q2XRp7ZGDCxvNUV

Are you mixing up privacy, security, and anonymity? Don't worry, it's more common than you might think! In this week's video we break down each term, so you can make educated decisions on what tools are best for you.

Please 👍 like and 🔔 subscribe to our channel to support our work and find out about our latest video content!

💬 Join the community: https://discuss.privacyguides.net
❤️ Support our work: https://www.privacyguides.org/en/about/donate/
🏡 Visit our website: https://www.privacyguides.org

Have a question, comment, or tip for us? You can securely reach us on Signal at @privacyguides.01 https://www.privacyguides.org/en/about/

Sources: https://www.privacyguides.org/videos/2025/03/14/stop-confusing-privacy-anonymity-and-security/

Copyright ©️ 2025 Privacy Guides. This video is made available under the Creative Commons Attribution Share Alike 4.0 International license. You can read the full license text here: https://github.com/privacyguides/privacyguides.org/blob/main/LICENSE

YouTube is known for silent censorship and general privacy malfeasance. If you want to discuss this video you can do so on our forum at https://discuss.privacyguides.net in addition to commenting here, and you can follow our channel on the fediverse at: https://neat.tube/c/privacyguides/videos

Privacy Guides is a nonprofit project dedicated to promoting privacy, best cybersecurity practices, and digital rights. As a part of MAGIC Grants, a 501(c)(3) public charity, your donation to support our cause may be tax deductible.

🎬 Credits
===============
Host: Jordan Warne
Writer: Jordan Warne
Editor: Jordan Warne
Executive Producer: Jonah Aragon

https://plebs.app/#/video/208f4b7d429679ca47fee0e09f28e11513601d7b9772b0326aa65a2cc2c4254a

Stop Confusing Privacy & Anonymity (and Security) ...

2026-01-03T22:46:36Z

Stop Confusing Privacy & Anonymity (and Security)

Are you mixing up privacy, security, and anonymity? Don't worry, it's more common than you might think! In this week's video we break down each term, so you can make educated decisions on what tools are best for you.

Please 👍 like and 🔔 subscribe to our channel to support our work and find out about our latest video content!

💬 Join the community: https://discuss.privacyguides.net
❤️ Support our work: https://www.privacyguides.org/en/about/donate/
🏡 Visit our website: https://www.privacyguides.org

Have a question, comment, or tip for us? You can securely reach us on Signal at @privacyguides.01 https://www.privacyguides.org/en/about/

Sources: https://www.privacyguides.org/videos/2025/03/14/stop-confusing-privacy-anonymity-and-security/

Copyright ©️ 2025 Privacy Guides. This video is made available under the Creative Commons Attribution Share Alike 4.0 International license. You can read the full license text here: https://github.com/privacyguides/privacyguides.org/blob/main/LICENSE

YouTube is known for silent censorship and general privacy malfeasance. If you want to discuss this video you can do so on our forum at https://discuss.privacyguides.net in addition to commenting here, and you can follow our channel on the fediverse at: https://neat.tube/c/privacyguides/videos

Privacy Guides is a nonprofit project dedicated to promoting privacy, best cybersecurity practices, and digital rights. As a part of MAGIC Grants, a 501(c)(3) public charity, your donation to support our cause may be tax deductible.

🎬 Credits
===============
Host: Jordan Warne
Writer: Jordan Warne
Editor: Jordan Warne
Executive Producer: Jonah Aragon

https://plebs.app/#/video/d25c9f0f4406bc1921fc8f8efbbb5ebca96e7030af851d612ef0b29060bd08b6

Cosmic a great Linux desktop, but still limited ...

2026-01-03T22:13:25Z

Cosmic a great Linux desktop, but still limited

https://tilvids.com/w/j8FfrSBh8oUejkhdGcoqkB

Use a secure, encrypted, and fast VPN with Proton VPN: https://protonvpn.com/TheLinuxEXP

👏 SUPPORT THE CHANNEL:
Get access to:
- a Daily Linux News show
- a weekly patroncast for more thoughts
- your name in the credits

YouTube: https://www.youtube.com/@thelinuxexp/join
Patreon: https://www.patreon.com/thelinuxexperiment

Or, you can donate whatever you want:
https://paypal.me/thelinuxexp
Liberapay: https://liberapay.com/TheLinuxExperiment/

👕 GET TLE MERCH
Support the channel AND get cool new gear: https://the-linux-experiment.creator-spring.com/

Timestamps:
00:00 Intro
00:38 Sponsor: ProtonVPN
01:31 Install & First Run
03:31 Cosmic Desktop: it's fine
08:10 Design and app integration
13:15 Desktop Tweaking
16:49 Tiling
20:59 X11 & Wayland
22:45 Default Apps
16:42 PopOS 24.04: Old, but up to date
28:47 Parting Thoughts

#linuxdesktop #cosmic #linuxdistro #popos

https://plebs.app/#/video/4d0be01de00dcddfd75c25fe8dfe3828d3cffee4a3a00faa0720389538ab14be

We Lose 73% of Revenue to Ad Blocking (AFDS 2025 Presentation) ...

2026-01-03T21:44:31Z

We Lose 73% of Revenue to Ad Blocking (AFDS 2025 Presentation)

https://techlore.tv/w/vwSVhB8Fu8HNHjojsqaaKy

Techlore was invited to the Ad Filtering Dev Summit in Cyprus, where Henry spoke about the paradox we face: Techlore recommends ad blockers for digital rights & privacy & security, but we partially rely on ad revenue to survive. How do we navigate this? After 10 years, we've diversified revenue across sponsors, community support, and affiliates to get ahead of this, but what happens to other independent voices as ad blocking grows?

🧑‍💻 AFDS 2025 CO-HOSTS AND SPONSORS
https://www.youtube.com/@AdGuardEN
https://www.youtube.com/@eyeo_gmbH
https://www.youtube.com/@ghostery_adblocker

🔎 RELATED VIDEOS
https://youtu.be/dr7XSnbyv7w
https://youtu.be/E4tJSHimd9c
https://youtu.be/KKJXGM48p00
https://youtu.be/MREkh8oMCPs
https://www.youtube.com/playlist?list=PL61EKVIQWizG0tIYqNDoenVaOWSiaAsyb

📱 RESOURCES IN VIDEO
• NewPipe: https://newpipe.net/
• Brave Rewards: https://brave.com/brave-rewards
• Substack: https://substack.com/
• PeerTube: https://joinpeertube.org/
• eye-o: https://eyeo.com/

🧡 SUPPORT TECHLORE
Support our mission to defend digital rights for everyone:
https://www.youtube.com/channel/UCs6KfncB4OV6Vug4o_bzijg/join
• All Our Support Methods: https://techlore.tech/support/

🔐 MORE FROM TECHLORE
• Homepage & Newsletter: https://techlore.tech
• Go Incognito Course: https://techlore.tech/go-incognito-course/
• Privacy Tools: https://privacytools.techlore.tech/
• VPN Comparison Chart: https://vpn.techlore.tech/

⏱️ TIMESTAMPS
00:00 INTRO
00:57 HENRY'S PRESENTATION
12:22 OUTRO

#AdBlocking #CreatorEconomy #DigitalRights

https://plebs.app/#/video/97d19d575a75451209954ad58992d4b44bb7abe68abf652eb805556a6a78aa3d

Firefox turns into AI browser, more Wayland work - Linux Weekly ...

2026-01-03T21:39:27Z

Firefox turns into AI browser, more Wayland work - Linux Weekly News

Try TuxCare's Endless Lifecycle Support for Debian 10: https://tuxcare.com/endless-lifecycle-support/debian-eol-support/?utm_campaign=The%20Linux%20Experiment&utm_source=youtube&utm_medium=social

Grab a brand new laptop or desktop running Linux: https://www.tuxedocomputers.com/en#

👏 SUPPORT THE CHANNEL:
Get access to:
- a Daily Linux News show
- a weekly patroncast for more thoughts
- your name in the credits

YouTube: https://www.youtube.com/@thelinuxexp/join
Patreon: https://www.patreon.com/thelinuxexperiment

Or, you can donate whatever you want:
https://paypal.me/thelinuxexp
Liberapay: https://liberapay.com/TheLinuxExperiment/

👕 GET TLE MERCH
Support the channel AND get cool new gear: https://the-linux-experiment.creator-spring.com/

Timestamps

00:00 Intro
00:30 Sponsor: TuxCare
01:53 Firefox will become an AI browser & makes all the mistakes
07:01 Servo making progress
08:19 Plasma 6.6 will fix some big Wayland issues
09:48 Wayland protocols updated for better HDR
10:51 GNOME bans AI from extensions
13:00 Rust no longer experimental in Linux kernel
14:21 Mint 22.3 beta released
15:59 Website lets you scan Snaps for vulnerabilities
18:19 Danish admin plans move to Linux
20:17 NVK gets a huge performance boost

Links:

Firefox will become an AI browser
https://blog.mozilla.org/en/mozilla/leadership/mozillas-next-chapter-anthony-enzor-demeo-new-ceo/
https://9to5linux.com/firefox-will-ship-with-an-ai-kill-switch-to-completely-disable-all-ai-features
https://www.theverge.com/tech/845216/mozilla-ceo-anthony-enzor-demeo

Servo making progress
https://servo.org/blog/2025/12/15/november-in-servo/

Plasma 6.6 will fix some big Wayland issues
https://blogs.kde.org/2025/12/13/this-week-in-plasma-wayland-screen-mirroring-and-custom-modes/

Wayland protocols updated for better HDR
https://www.phoronix.com/news/Wayland-Protocols-1.47

GNOME bans AI from extensions
https://blogs.gnome.org/jrahmatzadeh/2025/12/06/ai-and-gnome-shell-extensions/
https://gjs.guide/extensions/review-guidelines/review-guidelines.html

Rust no longer experimental in Linux kernel
https://thenewstack.io/rust-goes-mainstream-in-the-linux-kernel/

Mint 22.3 beta released
https://linuxiac.com/linux-mint-22-3-zena-enters-public-beta/

Website lets you scan Snaps for vulnerabilities
https://snapscope.popey.com/

Danish admin plans move to Linux
https://thedanishdream.com/news/denmark-ditches-microsoft-in-bold-tech-shift/
https://www.semaphor.dk/opensource/linuxpc

NVK gets a huge performance boost
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36450

#linuxdesktop #linuxdistro #technews

https://plebs.app/#/video/a271a0f1cfb27ef8d2c589250145611e9bca6f19965654baab7107a39dad1d5b

New X11 server, New portable package manager, no more Steam Deck ...

2026-01-03T11:45:42Z

New X11 server, New portable package manager, no more Steam Deck LCD - Linux Weekly News

Try out Proton Mail, the secure email that protects your privacy: https://proton.me/mail/TheLinuxEXP

Grab a brand new laptop or desktop running Linux: https://www.tuxedocomputers.com/en#

👏 SUPPORT THE CHANNEL:
Get access to:
- a Daily Linux News show
- a weekly patroncast for more thoughts
- your name in the credits

YouTube: https://www.youtube.com/@thelinuxexp/join
Patreon: https://www.patreon.com/thelinuxexperiment

Or, you can donate whatever you want:
https://paypal.me/thelinuxexp
Liberapay: https://liberapay.com/TheLinuxExperiment/

👕 GET TLE MERCH
Support the channel AND get cool new gear: https://the-linux-experiment.creator-spring.com/

Timestamps:
00:00 Intro
00:51 Sponsor: Proton Mail
01:40 Brand new X11 server in the works
04:36 New packaging solution for portable apps
08:10 Steam Deck LCD is discontinued
10:11 Linux Foundation publishes annual report
12:58 elementary OS 8.1 released
15:57 Older AMD GPUs get 30% performance boost
17:41 CachyOS looks at the server now
20:09 Italy fines Apple for their privacy framework
23:24 Sponsor: Tuxedo Computers

Links:

Brand new X11 server in the works
https://git.dec05eba.com/phoenix/tree/README.md
https://linuxiac.com/phoenix-emerges-as-a-modern-x-server-written-from-scratch-in-zig/

New packaging solution for portable apps
https://itsfoss.com/pkgforge/

Steam Deck LCD is discontinued
https://www.gamingonlinux.com/2025/12/valve-discontinuing-the-last-steam-deck-lcd-model/

Linux Foundation publishes annual report
https://linuxiac.com/the-linux-foundation-spent-8-4-million-on-the-linux-kernel-project-in-2025/

elementary OS 8.1 released
https://blog.elementary.io/os-8-1-available-now/

Older AMD GPUs get 30% performance boost
https://www.phoronix.com/review/linux-619-amdgpu-radeon/5

CachyOS looks at the server now
https://cachyos.org/blog/2025-christmas-new-year/

Italy fines Apple for their privacy framework
https://www.bleepingcomputer.com/news/security/italy-fines-apple-116-million-over-app-store-tracking-privacy-practices/

https://plebs.app/#/video/57c4a3e52752b75747daf7b6f4b40634f5bc7d3041e3ed5c3d39c076e526f75e

#Repost - the gift that keeps on giving In a world where we are ...

2026-01-02T19:27:25Z

#Repost - the gift that keeps on giving

In a world where we are the algorithm reshaping content you like is what makes #nostr better.... 📨

@npub1gcx…nj5z @npub142g…xrj0 @npub1yzv…rf8q ...

2026-01-02T19:24:18Z

In reply to nevent1q…5vnn
_________________________

VitorPamplona (npub1gcx…nj5z)
Amethyst (npub142g…xrj0)
YakiHonne (npub1yzv…rf8q)
greenart7c3 (npub1w4u…0jr5)

#naddr1qq…pgy5

2026-01-02T19:15:14Z

quoting
naddr1qq…pgy5

Preface

The state is the most dangerous institution in human history. It has killed hundreds of millions, impoverished billions, and now constructs surveillance infrastructure that would make prior tyrannies weep with envy. Central Bank Digital Currencies will complete the architecture: money itself becoming a tool of observation and control, every transaction recorded, every purchase approved or denied at the discretion of authorities.

This is not paranoia. This is the announced policy of over 130 central banks.

Three groups of people might resist. Each has a fatal weakness.

Austrian economists have built the most rigorous analytical framework for understanding why the state fails, why markets succeed, and why sound money matters. They can explain with devastating precision how intervention distorts, how central banking destroys, how surveillance enables tyranny. But most are armchair theorists. They write papers. They give lectures. They lament the state of the world. Ask them HOW to actually implement sound money, HOW to build systems that resist control, HOW to create markets outside state supervision, and they have no answer. Theory without implementation is impotent. The state does not fear essays.

Cypherpunks have built working systems. Bitcoin processes blocks. Tor routes traffic. Encryption holds. They wrote code while others wrote complaints. But many lack economic understanding. They build tools without grasping why those tools matter, launch companies that centralize what should remain distributed, make compromises that betray the purpose of the technology. Projects fail not from technical inadequacy but from economic ignorance: misaligned incentives, unsustainable models, vulnerability to the very powers they meant to resist. Implementation without theory is blind. The state does not fear tools it can co-opt.

Freedom-seeking individuals sense that something is deeply wrong. They distrust institutions, question official narratives, seek alternatives to systems that feel increasingly hostile. This instinct is correct. But awareness without understanding is paralysis. They know they should be concerned about surveillance, about financial control, about the consolidation of power. They do not know what to do. They lack both the theoretical framework to understand what they face and the technical knowledge to defend against it. Instinct without strategy is helpless. The state does not fear the confused.

Each group's weakness is dangerous. The economist who cannot build, the engineer who cannot reason, the individual who cannot act: all are neutralized despite their partial knowledge.

This book exists to fix that.

The Synthesis

Two intellectual traditions, developing independently across the twentieth century, arrived at the same conclusions about privacy, money, and freedom. Austrian economists, through deductive analysis from the axiom of human action, established that privacy is structural to purposeful behavior, that sound money is essential to economic coordination, that the state is systematic aggression. Cypherpunks, through cryptographic implementation, demonstrated that privacy can be technically defended, that sound money can be programmed, that systems can be built to resist control.

Neither tradition alone suffices. Together, they provide both the WHY and the HOW.

This book synthesizes their insights into a unified strategy. The theoretical foundations are rigorous: axioms that cannot be coherently denied, conclusions derived through strict deduction. The practical guidance is concrete: tools that work, techniques that protect, systems that function. The strategic framework is clear: how cheap defense defeats expensive attack, how breaking observation prevents control, how the parallel economy grows until the state withers from irrelevance.

For Different Readers

Austrian economists will find their theory operationalized. Cryptographic concepts translate through economic analogies: public key cryptography solving trust problems, Bitcoin implementing sound money, zero-knowledge proofs enabling verification without disclosure. You will learn HOW to build what you have long understood SHOULD exist.

Cypherpunks will discover the economic framework explaining why your tools matter and why some projects succeed while others fail. The action axiom provides foundations as rigorous as mathematical axioms. Austrian political economy illuminates the adversaries you face, why surveillance persists, and how to design systems that resist capture. You will understand WHY what you build matters.

Freedom-seeking individuals will gain both the analytical framework and the practical knowledge you need. No prior expertise required. Both domains are explained from first principles. Your instinct is correct; this book gives it teeth. You will learn WHAT you face and WHAT to do about it.

The Stakes

Privacy is not about hiding. It is about the conditions under which humans can act as humans: deliberating internally, coordinating voluntarily, accumulating wealth beyond the reach of those who would seize it.

The state cannot steal what it cannot see. The state cannot control what it cannot observe. The state cannot persist when theft becomes unprofitable.

This book shows how to make it so.

The logic is sound. The strategy is clear. The tools exist. The only question is whether enough people will understand and act before the window closes.

Read. Understand. Build.

Next Chapter: naddr1qq…5wjq

If you using #AI for vibe-coding here are some things I've ...

2026-01-02T13:29:14Z

If you using #AI for vibe-coding here are some things I've found useful.

1. Use lint and type check - just as the AI to do it for you - this quickly helps the AI identify issues. (AI has brain farts too).
2. Occasionally as it to complete a SWOT analysis - you can even target specific aspects including the code itself.
3. Ask it to develop plans - and the implement. This helps the AI arrange itself to complete big tasks in manageable bites.

#vibe-coding #tips

#nostr without dns... time for some shameless - unsolicited- ...

2026-01-02T08:20:16Z

#nostr without dns... time for some shameless - unsolicited- mentions. See if can gather any interest, or be relegated to the internet dustbin HRF (npub17xv…c9as) Max (npub1klk…x3vt) Derek Ross (npub18am…p424) jack (npub1sg6…f63m) 🤞#ncc #decentralised #privacy

quoting
naddr1qq…n6xw

Services without DNS: an identity-first model using NCC

This project demonstrates a working proof of concept for running and discovering services without relying on DNS. Instead of names and registrars, services are anchored to cryptographic identities and published over Nostr using signed, immutable records.

The result is a system where ownership, reachability, and trust are decoupled, verifiable, and client-resolved.

DNS becomes optional, not foundational.

This work is a proof of concept and reference implementation. The specifications, libraries, and sidecar are under active development and should not yet be considered production-hardened. The goal is to validate the model, explore client and relay behaviour, and provide a concrete basis for further review and iteration.

Although this project is demonstrated using Nostr relays, the model is service-agnostic. NCC-02 and NCC-05 apply to any networked service, including APIs, web services, media endpoints, and full web applications. Relays provide the discovery and distribution backbone. The service itself does not need to be a relay, or even Nostr-aware, to participate.

This includes standard web apps. A web application can be discovered, resolved, and reached via NCC records, with clients resolving identity and endpoints independently of DNS.

The components

NCC-02 – Identity-bound service ownership

NCC-02 defines how a Nostr identity asserts ownership of a service.

An NCC-02 record is a signed Nostr event that binds:

a service identifier using the d tag,

to a controlling npub,

with optional descriptive metadata.

This record answers a single question: who owns this service?

Because the event is signed by the service key, ownership is cryptographically verifiable. Any client can confirm that the service belongs to that identity without relying on DNS, registries, or central authorities.

Key properties:

Services exist as identities, not hostnames

Only the private key holder can update or revoke the record

Multiple services can exist under one identity, distinguished by d

Updates are expressed as new signed events, not mutable records

NCC-02 does not describe where a service runs or how to reach it. It is purely the ownership anchor.

Service record attestations

Service record attestations extend NCC-02 by allowing other identities to make signed statements about a service, without changing ownership.

An attestation is a separate Nostr event that references an NCC-02 service record and asserts some claim about it.

Critically:

The attester does not control the service

The attestation does not modify or replace the NCC-02 record

The claim stands on the reputation of the signer

Ownership remains singular. Claims about the service can be plural.

Attestations are intentionally generic and client-interpreted. They can represent:

operational responsibility

observed availability

validation or compliance checks

authorisation assertions

The NCC system does not interpret or enforce these claims. Clients decide:

which attesters they trust

how many attestations matter

how to handle conflicting or missing attestations

Attestations provide evidence, not authority. They replace central trust anchors with explicit, signed statements evaluated client-side.

NCC-05 – Cryptographic location resolution

NCC-05 defines how a service publishes where it can be reached, independently of DNS.

An NCC-05 record is associated with an NCC-02 service and contains one or more locators, each describing a concrete endpoint:

IPv4

IPv6

Tor onion services

Locators may be public or encrypted using NIP-44, allowing private endpoints to be published safely.

Key properties:

Endpoints are cryptographically bound to the service identity

Multiple locators can coexist in parallel

Endpoints can rotate without changing identity

Clients resolve locations by following identities, not names

NCC-05 does not proxy traffic, establish tunnels, or provide anonymity by itself. It is strictly a location description and resolution mechanism.

Potential service patterns

NCC-05 enables a range of service models beyond simple dynamic IP resolution:

Private and invite-only services Encrypted locators allow endpoints to be shared only with authorised pubkeys.

Paid or subscription services Access to locators can be gated behind one-off payments or ongoing zap-based subscriptions, with npubs removed from records or endpoints rotated as needed for easy user management.

Ephemeral services Short-lived APIs, temporary collaboration endpoints, or time-boxed access using tight TTLs.

Peer-to-peer rendezvous Two peers discover each other’s endpoints without public signalling, registrars, or coordination servers.

Agent and automation backchannels Bots or agents briefly exposing private control or callback endpoints.

Web apps without DNS Standard web applications reachable via IP or onion, discovered and resolved through identity-bound records instead of hostnames.

Onion-only and censorship-resistant services Services that never publish a public endpoint and rely entirely on private resolution.

Infrastructure mobility and failover Moving services between hosts or networks, or publishing multiple locators with deterministic priority.

Relays act only as the distribution backbone. The services themselves can be arbitrary protocols and do not need to be Nostr-aware.

NCC-06 – Sidecar and operational control plane

NCC-06 operationalises NCC-02 and NCC-05.

The sidecar is a local daemon that:

monitors services across IPv4, IPv6, and Tor

detects meaningful changes in endpoints, certificates, or metadata

publishes updated NCC-02 and NCC-05 records when required

sends encrypted admin notifications using NIP-44

supports secure remote administration via NIP-46

The sidecar does not forward traffic and is not a proxy. It acts as a publisher, monitor, and control plane that keeps service records accurate and current.

Because service identity is decoupled from network location, the sidecar enables rapid endpoint and metadata rotation under a stable identity. Services can move hosts, rotate IPs or onion addresses, update TLS fingerprints, or change publication relays and have the new state published within minutes.

Changing the service’s npub creates a new identity and is treated as a distinct service.

The client’s role

This model only works because the client is an active participant rather than a passive resolver.

The reference client shows how a client discovers NCC-02 service records, verifies ownership, and then resolves NCC-05 locator records to determine where a service can actually be reached. When locators are private, the client handles decryption using NIP-44 and decides which endpoints it is authorised to see.

The client is also responsible for correlating service records, locator records, and any attestations into a single, coherent view of a service. Trust is not implicit. Each client applies its own policy about which attestations to accept, which identities to trust, and when to fail closed.

Endpoint selection is likewise a client decision. The client chooses between multiple locators deterministically, respecting priority, expiry, and freshness, and automatically follows changes as new records are published. When endpoints rotate or infrastructure moves, the client converges on the new state without manual reconfiguration.

Connections are made directly to the resolved service endpoints. Where required, the client can route traffic to onion services using a local bridge, allowing standard web applications and browsers to participate without special network configuration.

In this architecture, relays act purely as the distribution layer and the sidecar keeps service records accurate over time. The client is where meaning is enforced. What to trust, where to connect, and how to react to change are all resolved locally, without any global authority.

How it fits together

NCC-02 answers: Who owns this service?

Attestations answer: What do others claim about it?

NCC-05 answers: Where can it be reached?

NCC-06 keeps all of the above accurate over time

All components use:

immutable, signed Nostr events

client-side resolution

no DNS, PKI, or naming authorities

Why this matters

DNS-based service discovery couples identity, location, and trust into a brittle hierarchy. NCC separates these concerns:

identity is cryptographic

location is declarative and rotatable

trust is explicit and plural

resolution is client-driven

This makes services more portable, harder to censor, easier to migrate, and independently verifiable.

DNS becomes optional, not foundational.

Code and references

Proof-of-concept client https://github.com/imattau/ncc-client

NCC-06 sidecar and library https://github.com/imattau/ncc-06

NCC-02 spec and library https://github.com/imattau/ncc-02

NCC-05 spec and library https://github.com/imattau/ncc-05

NPM Libraries used: ncc-02-js, ncc-05-js

#nostr #builders #privacy #p2p #tor #dns #decentralization #nostrdevs #ncc #npm #js

#naddr1qv…nqct

2025-12-31T21:20:29Z

quoting naddr1qv…nqct

Welcome back to Nostr Compass, your weekly guide to the Nostr protocol ecosystem.

This week: As 2025 closes, we look back at five years of December milestones in Nostr's evolution. From fiatjaf's first client release in December 2020, through Jack Dorsey's pivotal 14 BTC donation in December 2022, to this month's NIP-55 signer proliferation and NDK's 162x cache speedup, December has consistently marked turning points for the protocol. This special issue traces the technical history through each December, documenting the protocol's growth from two experimental relays to 2,500+ nodes across 50 countries. Plus: Amethyst's desktop module takes shape via Quartz, Notedeck gains messaging, Citrine hosts web apps, and NIP-54 fixes internationalization for non-Latin scripts.

December Recap: Five Years of Nostr Decembers

Nostr turns five this year. fiatjaf initiated the protocol on November 7, 2020, and every December since has marked a distinct phase in its evolution: from proof-of-concept to global movement to production ecosystem. This is a technical retrospective of December 2020 through December 2025, the formative years that established Nostr's foundation and catalyzed its breakout moment.

December 2020: Genesis

The first full month of Nostr's existence saw fiatjaf release Branle, the protocol's first client, built with Quasar (Vue.js) and absurd-sql for local storage. fiatjaf had already established the core architecture: users identified by secp256k1 public keys, all posts cryptographically signed, relays serving as dumb storage that don't communicate with each other. One or two experimental relays served a handful of early adopters coordinating in the Telegram group @nostr_protocol, which had launched November 16. The original documentation described "the simplest open protocol that is able to create a censorship-resistant global social network," a premise that would take two more years to prove.

December 2021: Early Development

On December 31, 2021, Nostr hit the Hacker News front page with 110 points and 138 comments, submitted by Cameri. This marked the protocol's first significant exposure to the broader developer community. The network ran on approximately seven relays with fewer than 1,000 users. Branle received updates including private key import (December 31) and multi-relay support. A command-line client, noscl, provided terminal-based interaction. The protocol specifications existed in fiatjaf's documentation, though the formal NIPs repository wouldn't be created until May 2022. The protocol was, as fiatjaf described it, "a work in progress."

December 2022: The Tipping Point

December 2022 transformed Nostr from a niche experiment into a mainstream movement. The catalyst came on December 15, when Jack Dorsey donated 14.17171699 BTC (~$245,000-$250,000) to fiatjaf after discovering the protocol and declaring it "100 percent what we wanted from Bluesky, but it wasn't developed from a company." On December 16, fiatjaf announced splitting funds with Damus developer William Casarin (jb55), and Dorsey verified his Nostr account (npub: jack (npub1sg6…f63m)). The funding legitimized the project overnight.

The same week, Twitter's chaos accelerated adoption. December 14-15 saw suspensions of prominent journalists from the New York Times, CNN, and Washington Post. On December 18, Twitter announced bans on accounts promoting Nostr, Mastodon, and other platforms. The policy was reversed the following day after backlash. The exodus drove users to explore alternatives.

Protocol development surged. On December 16, NIP-19 was merged (#57), introducing bech32-encoded identifiers (npub, nsec, note, nprofile, nevent) that made keys human-readable and distinguishable. The NIPs repository logged 36+ commits that month, including NIP-40 and NIP-07 updates. Clients proliferated: Damus filled its TestFlight beta within hours, Astral forked Branle for profile creation, Snort launched as a "fast, censorship-resistant" web client, and Vitor Pamplona began Amethyst development. Alby v1.22.1 "Kemble's Cascade of Stars" shipped December 22 with NIP-19 support. By December 7, Nostr had approximately 800 users with profiles; when Damus hit the App Store on January 31, 2023, the floodgates opened, driving growth to 315,000+ users by June 2023.

December 2023: Ecosystem Maturation

December 2023 marked a critical inflection point for Nostr protocol security. On December 20, NIP-44 revision 3 was merged following an independent Cure53 security audit (NOS-01) that identified 10 issues in the TypeScript, Go, and Rust implementations, including timing attacks and forward secrecy concerns. The updated spec replaced the flawed NIP-04 encryption with ChaCha20 and HMAC-SHA256, establishing the cryptographic foundation that now underpins NIP-17 private DMs and NIP-59 gift wrapping. The same week, OpenSats announced their fourth wave of grants on December 21, funding seven projects including Lume, noStrudel, ZapThreads, and an independent NIP-44 audit. This followed the first wave in July 2023 that had funded Damus, Coracle, Iris, and others, bringing total Nostr Fund allocation to approximately $3.4 million across 39 grants.

The month also exposed sustainability tensions in the ecosystem. On December 28, William Casarin (jb55) posted on Stacker News that 2024 would "likely be the last year of Damus," citing that "nostr clients don't make money" after Apple's restrictions on in-app zaps severely limited revenue potential. The Damus team had previously rejected VC funding. Meanwhile, Nostr Wallet Connect v0.4.1 shipped on December 26, extending NIP-47 with pay_keysend, make_invoice, lookup_invoice, list_transactions, get_balance, and get_info methods, laying groundwork for the wallet integrations that would become standard across clients.

December 2024: Protocol Advancement

December 2024 opened with the Notedeck Alpha launch on November 30, the Damus team's Rust-based desktop client featuring a multi-column interface with multiple account support. Built for Linux, macOS, and Windows (Android planned for 2025), Notedeck initially shipped to Damus Purple subscribers and represented a strategic expansion beyond iOS. Two weeks later, OpenSats announced their ninth wave of grants on December 16, funding AlgoRelay (the first algorithmic relay for personalized feeds), Pokey (Android app with Bluetooth mesh for restricted internet), Nostr Safebox (NIP-60 Cashu token storage), and LumiLumi (lightweight accessible web client), pushing total Nostr Fund allocation to approximately $9 million, a 67% year-over-year increase.

The month saw significant client maturation across the ecosystem. Gossip 0.13.0 landed on December 23 with File Metadata (NIP-92/NIP-94) support, Blossom integration, and NIP-50 relay search. Coracle 0.5.0 shipped December 12 with reworked onboarding and nostr-editor integration. Protocol development remained active with 30 pull requests submitted between December 9-22 (10 merged), including NIP-46 rewrites to use only NIP-44 encryption and continued work on NIP-104 for Signal-level double ratchet encryption. Network statistics showed 224,000+ daily trusted pubkey events, 4x year-over-year growth in new profiles with contact lists, and a 50% increase in public writing events.

December 2025: Ecosystem Expansion

December 2025 brought continued protocol maturation and ecosystem expansion. On December 21, OpenSats announced their fourteenth wave of Nostr grants, funding three projects: YakiHonne (a multi-platform client with creator portal for long-form content and Cashu/Nutzaps payment integration), Quartz (Vitor Pamplona's Kotlin Multiplatform library that powers Amethyst and will enable an iOS version), and Nostr Feedz (RSS-to-Nostr bidirectional integration by PlebOne). Grant renewals went to Dart NDK and Mattn's nostr-relay.

Protocol evolution continued with NIP-BE (Bluetooth Low Energy messaging, #1979) merged in November, enabling offline device synchronization. NIP-A4 (Public Messages, kind 24, #1988) landed later in the month, defining notification-screen messages that use q tags to avoid threading complications. NIP-29 received major clarification (#2106), introducing the hidden tag for truly private, undiscoverable groups. The NIP-55 spec also saw refinement (#2166), addressing a common implementation mistake where developers called get_public_key from background processes.

On the client side, Primal Android became a full NIP-55 signer through eight merged PRs implementing LocalSignerContentProvider, joining Amber and Aegis as Android signing options. The NDK library achieved 162x faster cache queries (from ~3,690ms to ~22ms) by eliminating duplicate writes and unnecessary LRU cache lookups (PR #371, PR #372). Shopstr introduced Zapsnags for flash sales via zaps. White Noise shipped MIP-05 privacy-preserving push notifications. See Newsletter #1 and Newsletter #2 for complete coverage.

Five years ago, fiatjaf released Branle to a handful of users across two experimental relays. Today, the protocol supports 140+ clients, 2,500+ relays across 50 countries, and a growing web of trust linking hundreds of thousands of keypairs. December's pattern of major releases continued this month with Bluetooth messaging, Android signer proliferation, and infrastructure grants signaling sustained investment in cross-platform tooling.

News

Amethyst Desktop Takes Shape - The Quartz grant from OpenSats' fourteenth wave is already producing results. PR #1625 creates a full :desktopApp module for Amethyst using Compose Multiplatform, with login and global feed screens functional on Desktop JVM. The architecture converts the :commons module to Kotlin Multiplatform with a clean source set structure (commonMain, jvmAndroid, androidMain, jvmMain), enabling shared UI components between Android and desktop while leaving platform-specific decisions to each target. This lays the foundation for the eventual iOS version via the same Kotlin Multiplatform approach.

Amethyst Voice Replies - A Christmas delivery from davotoula: PR #1622 adds dedicated voice reply screens with waveform visualization, re-record support, media server selection, and upload progress indicators. Users can now reply to both root voice messages and voice replies with audio.

Notedeck Adds Messaging - Notedeck, the Damus desktop client, gained a messages feature in PR #1223, expanding beyond timeline browsing into direct communication.

Citrine Hosts Web Apps - Citrine can now host web applications, turning your phone into a local-first Nostr web server. A separate PR #85 adds automatic reconnection and event broadcasting when network connectivity returns, with comprehensive test coverage across Android API levels.

Nostrability Developer Toolkit Registry - The Developer Kits & Tooling tracker maintains a curated registry of SDKs, libraries, and developer tools across languages (TypeScript, Rust, Python, Go, Dart, Swift, and more). If you're new to Nostr development, this is a useful starting point for finding the right toolkit for your stack.

NIP Updates

Recent changes to the NIPs repository:

NIP-54 - Critical internationalization fix for wiki d-tag normalization (#2177). Previous rules converted all non-ASCII characters to -, breaking support for Japanese, Chinese, Arabic, Cyrillic, and other scripts. The updated spec preserves UTF-8 letters, applies lowercase only to characters with case variants, and includes comprehensive examples: "ウィキペディア" stays "ウィキペディア", "Москва" becomes "москва", and mixed scripts like "日本語 Article" normalize to "日本語-article".

Releases

Zapstore 1.0-rc1 - The Nostr-based permissionless app store ships the first release candidate of its new architecture, featuring a complete UI refresh, rewritten package manager with improved error handling, App Stacks for curated discovery, redesigned profile screens, background update checking, and infinite scrolling in release lists.

KeyChat v1.38.1 - The MLS-based encrypted messaging app adds UnifiedPush support for Android and Linux push notifications, plus biometric authentication for privacy operations. Available for Android, Windows, macOS, and Linux.

Alby Go v2.0.0 - The mobile Lightning wallet companion ships a visual redesign with new logo, updated color palette, redesigned address book, and improved amount input keyboard. BTC Map is now accessible from the home screen, and transaction descriptions appear in notifications.

nak v0.17.4 - fiatjaf's command-line Nostr tool released, following v0.17.3's LMDB Linux restriction fix from last week.

Notable code and documentation changes

Open pull requests and early-stage work worth watching.

Damus (iOS)

NIP-19 relay hints implements relay hint consumption for event fetching. When users open nevent, nprofile, or naddr links, Damus now extracts relay hints from the bech32 TLV data and connects to ephemeral relays to fetch content not in the user's relay pool. The implementation includes ref-counted cleanup to prevent race conditions during concurrent lookups. Image URL detection automatically converts pasted image URLs into preview thumbnails in the composer, with a carousel position badge for multiple images. npub paste conversion transforms pasted npub/nprofile strings into mention links with async profile resolution.

Amethyst (Android)

Payment targets adds an event interface for NIP-57 zap splits, allowing posts to specify multiple recipients who share incoming zaps (useful for collaborations, revenue sharing, or tipping both content creators and the tools they use). Quartz feature parity documentation adds a detailed table tracking which features are implemented across Android, Desktop JVM, and iOS targets, noting that iOS is missing core cryptography (Secp256k1Instance), JSON serialization, and data structures.

Notedeck (Desktop)

Timeline filter rebuild fixes a bug where unfollowed accounts kept appearing in feeds. Timeline filters were built once from the contact list and never updated; the fix adds contact_list_timestamp tracking and an invalidate() method to trigger rebuilds when follow state changes.

Citrine (Android Relay)

ContentProvider API exposes the local relay's event database to other Android apps via ContentResolver. Unlike the WebSocket interface (which requires apps to maintain a persistent connection and speak the Nostr relay protocol), ContentProvider offers direct synchronous database access through Android's native IPC mechanism. External apps can query events by ID, pubkey, kind, or date range, insert new events with validation, and delete events without managing socket connections.

rust-nostr (Library)

NIP-40 relay-level support adds expiration handling at the relay builder level. Expired events are now rejected before storage and filtered out before sending to clients, eliminating the need for each database implementation to handle expiration checks independently.

nak (CLI)

Blossom mirror implements blob mirroring functionality for the command-line tool.

Mostro (P2P Trading)

Dev fee audit events adds transparent audit trails for development fund payments through kind 8383 Nostr events. The implementation publishes non-blocking audit events after successful fee payments, including order details and payment hashes while excluding buyer/seller pubkeys for privacy.

MDK (Marmot Development Kit)

Three security audit fixes landed: Author verification enforces that rumor pubkeys match MLS sender credentials, preventing impersonation attacks. KeyPackage identity binding verifies credential identity matches event signers. Admin update validation prevents empty admin sets and non-member admin assignments.

Shopstr (Marketplace)

HODL invoice escrow implements a trust-minimized payment system for physical goods. The architecture uses Alby's makeHoldInvoice to lock buyer funds in their own wallet, with settlement triggered only after merchant inventory verification. The handshake protocol flows through NIP-17 encrypted DMs: buyer sends order request, merchant responds with HODL invoice, buyer pays (funds locked), merchant confirms stock and shipping, then settlement releases funds. Multi-merchant cart support splits payments across vendors.

Jumble (Web Client)

Per-relay discovery mode adds a toggle to hide posts from followed users on specific relays, enabling language-based discovery feeds (e.g., nostr.band/lang/*). The feature filters out posts where the author pubkey appears in the user's follow list, persisting toggle state per relay URL in localStorage.

White Noise (Encrypted Messaging)

Media upload retry adds retry options for failed uploads. Profile edit warnings alert users about profile changes. On the backend, whitenoise-rs fixes a race condition in AccountGroup creation.

npub.cash (Lightning Address Service)

v3 rewrite migrates to Bun for the monorepo and server, adds SQLite support, drops v1 compatibility, implements LUD-21, and adds realtime mint quote updates.

nostr-java (Library)

v1.1.1 ships WebSocket handling refactors and improved test robustness across two PRs.

NIPs Repository

NIP-54 Djot migration proposes a separate change to the wiki spec: switching the content format from Asciidoc to Djot, a lightweight markup language with cleaner syntax. The PR introduces reference-style links for wikilinks, making cross-references between wiki articles more readable in source form. NIP-XX Quorum introduces threshold multi-signature governance for Nostr groups using FROST (Flexible Round-Optimized Schnorr Threshold signatures). A Quorum is an nsec shared among members through a T-of-N scheme where members can represent themselves or delegate to a council of representatives. When the council changes, the old nsec becomes obsolete and a new one is distributed—the final act of any council is signing the governance transition event. The spec defines membership (public or private), elections and polls (popular votes, votes of no confidence), optional natural-language "laws," and crucially, quorum ontologies where quorums can be members of other quorums, enabling hierarchical structures like localities joining regional bodies. Use cases span source code development, company boards, HOAs, and moderated communities.

That's it for this week and this year. Building something? Have news to share? Want us to cover your project? <a href="Nostr Compass (npub1wav…2923)">Reach out via NIP-17 DM</a> or find us on Nostr.

📖👀 #naddr1qq…7z2z

2025-12-31T20:36:13Z

📖👀

quoting
naddr1qq…7z2z

Breaking the Apple and Google duopoly with censorship-resistant app distribution

by Alien Investor

────────────────\ Software is our access to the world.

But who controls which software you are allowed to install on your phone?

For over a decade, we have lived in a global duopoly. Apple (iOS) and Google (Android) act as the wardens of our digital prisons — often euphemistically called "Walled Gardens."

They decide on censorship. They collect up to 30 percent "taxes" on innovation. They dictate what digital sovereignty is allowed to mean.

But resistance is forming.

The Nostr protocol, originally started as a Twitter alternative, has developed a weapon against this monopoly: the Nostr Zap Store.

We look at how this system works, why Apple fears it, and whether it is truly secure.

────────────────

The Architecture of Control

To understand why the Zap Store matters, we must identify the problem. The power of Apple and Google rests on three pillars: gatekeeping, economic extraction, and data centralization.

Gatekeeping is a weapon.

Every app must pass through corporate control. What is officially called "safety" is often political or economic censorship.

A prime example is the conflict between Apple and the Nostr app Damus.

Apple threatened to remove Damus from the App Store because users could send each other "Zaps" (Bitcoin via Lightning) for posts. Apple wanted these payments to run through their In-App Purchase system to capture their 30% cut. Since Zaps are peer-to-peer, this model does not fit.

The result: Apple forced Damus to cripple the feature.

This shows that a true peer-to-peer economy is unwanted in closed stores. If you threaten the gatekeeper's business model, you are out.

Then there is the illusion of safety.

The argument that "only the App Store is safe" is fragile. Centralized entities are a single point of failure. If the warden is corrupt or hacked, all users are affected simultaneously.

────────────────

The Nostr Zap Store: Technical Deconstruction

The "Zap Store" is not a company. It is not a central server. It is a protocol.

It relies on several Nostr standards (NIPs) that form a decentralized infrastructure together.

It starts with App Events.

How do you find an app without Google? Through Nostr events. Developers publish a signed App Event (kind 32267) to the network. It contains the name, icon, and tags.

Releases are modeled as "Release Artifact Sets" (kind 30063), referencing file metadata including download URLs and hashes.

It is a decentralized app manifest. No one can prevent a developer from sending this event. It is permissionless.

Storage via Blossom.

Nostr relays usually store text, not large files. That is what Blossom is for. Files are not stored by name, but by their cryptographic fingerprint (hash).

If a single bit of the file changes, the hash changes. Manipulation is immediately detected.

Since the file is retrieved via its hash, it can be mirrored on many servers. If one server deletes it, your phone simply fetches it from another.

Identity via Cryptography.

In the Zap Store, there are no accounts with email addresses. Developers identify themselves via their Public Key.

Release and update metadata are signed with the private key. Your phone verifies: "Does this update really come from the same developer as before?"

This is supply chain security at Linux level, made usable for end users.

────────────────

Value Proposition: Freedom and Money Streaming

Why go through the trouble? Because the economic model is revolutionary.

Value4Value instead of a 30% tax.

In the Zap Store, there is no platform fee. If you buy an app or send money to the developer, it happens via Bitcoin Lightning. The money flows directly from you to the developer.

This enables micro-transactions — for example, 10 cents for a feature — which were impossible in the old system due to fees.

Web of Trust instead of Algorithms.

In Google's Play Store, you see what pays the most for ads. In the Zap Store, you see what your network recommends.

If a security researcher you trust "zaps" or recommends an app, that carries more weight than anonymous 5-star ratings, which are often bought by bots.

────────────────

Decentralization vs. Security

Without a gatekeeper, anyone can upload apps — including malware. How does the Zap Store protect us?

It shifts the model from Blind Trust to Web of Trust.

In the centralized model, you blindly trust the brand (Apple/Google). In the decentralized model, you trust signatures and your social graph.

It creates antifragility.

There is no global kill switch. Censorship is significantly more difficult.

And it relies on OS isolation.

On Android, apps run in a sandbox. Even a malicious app from the Zap Store cannot access your contacts or location without permission. The operating system's security is the final line of defense.

Protection in the Zap Store is based on transparency and reputation. An app from an unknown key is marked as "unverified."

────────────────

Reality Check: Does It Work?

On Android, the "Happy Path" works surprisingly well today.

You must allow installation from "unknown sources" once. After that, it feels like an F-Droid Store with social features. Updates can come in automatically and signed.

Tools like the zapstore-cli allow developers to push updates directly from their coding environment to the world — no waiting time, no review.

On iOS, sovereignty is denied.

On the iPhone, the Zap Store remains theoretical for now. Outside the EU, Apple continues to block real sideloading. Even within the EU, barriers remain high.

This clearly shows: whoever wants digital freedom hits a hard wall with Apple.

────────────────

The Verdict: A Crack in the Wall

The Nostr Zap Store is not yet mass-market ready. It does not pass the "Grandma test" yet.

But it is proof that it is technically possible to distribute software globally without asking a corporation for permission and without paying protection money.

It is a return to the principles of the open internet — combined with hard money (Bitcoin) and hard cryptography.

For developers, it is a lifeboat. For users, it is a tool of self-defense.

────────────────

Launchpad: Installing the Zap Store

Ready to take the risk? Here is the direct access to the app and the web catalog.

Download (APK & Info) https://zapstore.dev/

Web Catalog (Browser) https://nostrapps.com/

────────────────

The Nostr Sovereignty Series

The Foundation: How to start correctly. The Sovereign Protocol: Architecture of an Unconfiscatable Digital Identity https://primal.net/Alien-Investor/the-sovereign-protocol-architecture-of-an-unconfiscatable-digital-identity

The Defense: Why you need an external signer. Your Private Key Is Not A Password: The Case for External Signers https://primal.net/Alien-Investor/your-private-key-is-not-a-password-the-case-for-external-signers

The Proof: How to get verified without permission. The Silver Badge: Immortalize Your Nostr Identity https://primal.net/Alien-Investor/the-silver-badge-immortalize-your-nostr-identity

────────────────

Money, power, Bitcoin — and OPSEC. I write about financial sovereignty, privacy, and cybersecurity in a world built on control. More at alien-investor.org (German only) 👽

... now just need people to test if they can get it to work... (I ...

2025-12-30T20:10:48Z

... now just need people to test if they can get it to work... (I did (yay!) - but very limited scope...)

Max (npub1klk…x3vt) JeffG (npub1zuu…c2uc) YakiHonne (npub1yzv…rf8q) jack (npub1sg6…f63m) (unsolicited mentions 🤫)

#ncc #nostrdevs

quoting
naddr1qq…yxuh

Location-Independent Infrastructure Using NCC-02, NCC-05, and NCC-06

Most internet services still rely on DNS as the root of discovery and trust. Even systems that describe themselves as decentralised often fall back to domain names, certificate authorities, and fixed hostnames once you look closely at how clients actually connect.

This article explores how services can function without DNS at all, using patterns that emerged from the Nostr ecosystem and were formalised through NCC-02, NCC-05, and NCC-06. While these conventions originated alongside Nostr, they are not limited to relays or social protocols. The same approach applies to content systems such as IPFS, media services like Blossom, private APIs, admin panels, and self-hosted infrastructure operating in unreliable or hostile networks.

The shift is subtle but significant. Instead of asking which domain should I connect to, clients ask which service key am I trying to reach.

Why DNS Becomes a Liability

DNS was designed for a network where services were relatively static, operators were identifiable, and intermediaries were trusted by default. None of those assumptions reliably hold today.

A DNS-based service is tightly coupled to external authorities: registrars, certificate issuers, recursive resolvers, and often hosting providers. Blocking or interference at any of these layers is usually sufficient to disrupt access. Even when services use literal IP addresses, DNS frequently re-enters indirectly through TLS validation, discovery mechanisms, or bootstrap endpoints.

The problem is not that DNS fails occasionally. The problem is that DNS collapses naming, trust, and location into a single fragile abstraction.

Identity First, Location Second

NCC-02, NCC-05, and NCC-06 deliberately separate these concerns.

In this model, a service is defined by a cryptographic public key. That key represents identity and continuity. Where or how the service is reachable becomes contextual information rather than a defining property.

Endpoints are treated as descriptive hints, not authoritative truth. Resolution becomes a matter of retrieving signed data and applying deterministic rules, rather than trusting a global naming hierarchy.

This is the same conceptual shift Nostr made for users, applied consistently to services.

NCC-02: Service Records as Signed Intent

NCC-02 introduces the concept of a service record. A service record is a signed statement published by the service operator, asserting that a given public key represents a specific service and optionally describing how it may be reached.

Crucially, NCC-02 does not require a hostname, nor does it assume public reachability. A record may list multiple endpoints, a single endpoint, or none at all. It may change over time without breaking identity.

From the client’s perspective, a service record answers only one question. If this key is trusted, what does the operator currently claim about this service?

NCC-05: Reachability Without Exposure

NCC-05 extends the model by allowing endpoint information to be encrypted and scoped.

Many services should not expose their location publicly. Admin interfaces, private relays, region-restricted backends, and censorship-sensitive deployments all benefit from being discoverable without being globally reachable.

With NCC-05, a service can publish its existence openly while revealing connection details only to authorised clients. Onion addresses can be preferred without advertising them. IPv4 or IPv6 endpoints can exist purely as fallback. Endpoint ordering expresses operator intent rather than promise.

An observer may learn that a service exists without learning how to reach it. DNS has no way to express that distinction.

NCC-06: Resolution as Data Retrieval

NCC-06 describes how clients turn published records into an actual connection attempt.

Rather than querying a central resolver or directory, clients retrieve signed service records from relays. Multiple relays may carry the same records. Records may be stale, partial, or conflicting.

Instead of treating these conditions as errors, NCC-06 treats them as expected states. Clients verify signatures, discard expired data, apply deterministic conflict resolution, and select the best reachable endpoint they can see.

Resolution becomes a data problem, not a naming problem. If nothing is reachable, the service is considered unavailable rather than broken.

How This Differs From Existing Approaches

The distinction becomes clearer when compared to existing systems.

Traditional DNS and TLS rely on human-readable names backed by central authorities. ENS replaces registrars with a blockchain but still treats names as the primary abstraction, often routing users back to DNS-hosted endpoints. Tor onion services derive addresses from keys, but operate entirely within the Tor ecosystem and do not generalise cleanly across mixed transports.

IPFS excels at content addressing, but when services are layered on top, DNS-based gateways frequently reappear. Blossom media servers today typically rely on standard URLs and HTTPS, inheriting the same structural fragility as conventional web services.

NCC differs by identifying services themselves by keys, not content and not names, and resolving reachability using signed data rather than global lookup infrastructure.

What This Model Does Not Solve

Being explicit about limits matters.

This approach does not solve the first-contact trust problem. If a client is given the wrong service key, it will resolve the wrong service correctly. This is not unique to NCC. The same bootstrap problem exists with domain names, TLS certificates, ENS names, and onion addresses. Initial trust establishment remains a social or application-layer concern.

It does not eliminate traffic analysis. NCC-05 can hide endpoint details, but it does not make network traffic invisible. Timing and connection metadata remain observable, even when Tor is used. The goal is to reduce resolution visibility, not to defeat a global passive adversary.

It does not make denial-of-service attacks impossible. Relays can be flooded and endpoints can be exhausted. What NCC provides instead is graceful degradation through multiple resolution paths and cached records, without a single resolver whose failure breaks the system.

The model also deliberately avoids human-readable naming. Keys are not memorable, and that is a trade-off. Naming systems can exist on top, but NCC keeps naming out of the trust path to avoid reintroducing the same fragility.

Finally, this is not a universal replacement for DNS. DNS remains effective for public websites and mass-market discovery. NCC is intended for environments where mobility, privacy, and resistance to interference matter more than convenience.

The Structural Shift

What NCC-02, NCC-05, and NCC-06 describe is not a new protocol layer so much as a design pattern.

Services publish signed intent. Clients resolve by retrieving and validating data. Trust is anchored in keys, not names.

Once this separation is made explicit, DNS stops being foundational. It becomes optional infrastructure rather than an assumed root of trust.

That change is small in implementation, but significant in consequence.

Closing Note: A Pattern, Not a Platform

Although NCC-02, NCC-05, and NCC-06 emerged from the Nostr ecosystem, the ideas they encode are not tied to Nostr itself. They describe a general infrastructure pattern for service discovery and reachability in environments where DNS is fragile, politicised, or simply unavailable.

The pattern is portable. Any system that can sign data, publish it to a retrievable medium, and verify signatures can adopt the same approach. Nostr provides a convenient substrate today, but it is not a prerequisite.

Seen this way, the value of these conventions is not that they replace DNS everywhere, but that they demonstrate how services can function cleanly without it when required. They make explicit a separation that has long been implicit: identity does not need to imply location, and discovery does not need to depend on names.

That distinction is likely to become more important, not less, as services continue to become more mobile, more private, and more contested at the network edge.

References

NCC-02 – Service Records https://github.com/imattau/ncc-02

NCC-05 – Dynamic and Encrypted Locators https://github.com/imattau/ncc-05

NCC-06 – Service Resolution and Sidecar Publishing https://github.com/imattau/ncc-06

npm Libraries

Reference implementations of the NCC conventions are also available as JavaScript libraries on npm. These are intended for client applications, tooling, and sidecar services rather than for defining the specifications themselves.

ncc-02-js https://www.npmjs.com/package/ncc-02-js

ncc-05-js https://www.npmjs.com/package/ncc-05-js

ncc-06-js https://www.npmjs.com/package/ncc-06-js

The libraries provide typed helpers, validation logic, and record-handling utilities aligned with the conventions, and are suitable for use in browsers, Node.js clients, and service sidecars.

#Nostr #DecentralisedInfrastructure #ProtocolDesign #DistributedSystems #ServiceDiscovery #CryptographicIdentity #PrivacyEngineering #CensorshipResistance #IPFS #Tor #SelfHosted #EdgeInfrastructure #NetworkResilience #nostrdev

Great read! Prompted me to update the way I was signed in... 🥸 ...

2025-12-28T05:06:00Z

Great read! Prompted me to update the way I was signed in... 🥸

quoting naddr1qp…6rxd

Why pasting your nsec into apps is a security nightmare and why you need Amber

by Alien Investor\ ────────────────\ On Nostr, you are not a row in a tech giant's database. You are a cryptographic key.

Your private key (nsec) is your voice, your identity, and your reputation. Whoever holds this key, is you.

Yet, most users — especially those valuing convenience — commit digital harakiri daily. They copy their nsec from a password manager and paste it directly into apps like Primal or Damus.

It works, but from a security architecture perspective, it is a nightmare.

Here is why your password manager hits its limits here, and why you urgently need to switch to a dedicated signer like Amber.

────────────────

The Problem: Your "Login" Is Actually a Surrender

When you "log in" to a Nostr app by pasting your key, background processes occur that you need to understand.

The Clipboard is a Public Marketplace. A password manager is built to store secrets securely. But to use them, it must decrypt them and pass them to the operating system — usually via the clipboard.

There is malware designed solely to scan the clipboard for strings starting with nsec1.... If you use cloud-based keyboards (like Gboard or SwiftKey), your clipboard contents often end up in the cache or cloud servers of Google or Microsoft.

The "Hot Wallet" Trap. Once you paste the key into a client app, the app must store it so you aren't asked for it with every like. This means a complex social media app with millions of lines of code, image parsers, and constant internet access has permanent access to your most important secret.

If a hacker finds a vulnerability in the client (e.g., via a manipulated image), they can theoretically extract your key. You have turned your client into a "Hot Wallet."

────────────────

The Solution: Amber and the Concept of "Signers"

Amber is a Nostr Event Signer for Android. The app does exactly one thing: It guards your key and signs things for you — but it never reveals the key.

The Difference: Secret vs. Signature.

The Old Way (Client has the key): You give the client your entire checkbook and sign blank checks. The client can do anything at any time.

The Signer Way (Amber): The client comes to you with a filled-out check (an event) and asks: "Can you please sign this?" Amber verifies it, signs it cryptographically, and returns only the signature. The key itself never leaves Amber.

Technically, this works via NIP-55 (Android Intents). The client app never knows what your private key looks like; it only knows your public key (npub).

"Amber is like a hardware wallet running as software on your phone. It isolates the secret from the app that connects to the internet."

────────────────

Why Amber Is Safer Than Your Password Manager

Many think: "Doesn't an extra app increase the attack surface?" False. In this case, it is the opposite. It is called compartmentalization.

No Internet Access for the Key. You can (and should) revoke Amber's internet access in Android settings. An app that cannot "phone home" cannot steal your key, even if it were compromised. A social client, by definition, must be online.

Android Keystore & Biometrics. Amber utilizes the Android Keystore System. Where possible, your key is processed in a dedicated security chip (Titan M, StrongBox). Additionally, you can secure every signature with a fingerprint. Even if someone steals your unlocked phone and opens Primal, they cannot post anything because Amber demands your biometric authorization.

────────────────

The "Legacy" Question: Is My Key Already Burned?

A common objection: "I created my account directly in Primal. The key was already online. Is it worth switching?"

The answer is a clear YES.

It is about Future Protection. If Primal was compromised in the past, that is a historical risk. But by migrating now, you protect yourself against future attacks.

If a malicious update is pushed tomorrow, or a new vulnerability is exploited, your key is no longer there. The attack hits a void. You degrade the client from the "owner" of your identity to a mere "user" of it.

────────────────

How to Migrate Properly (The "Primal Nuke")

Simply logging out is often insufficient, as data remnants can persist in storage. Here is the clean path to sovereignty:

Verify Backup. Ensure you have your nsec written down securely (offline, on paper/metal). Without a backup, you lose access.

Install Amber. Download Amber (preferably via F-Droid or GitHub to verify the source).

Import Key. Enter your nsec into Amber. Immediately enable biometric locking (fingerprint).

The "Nuke". Do not just log out of your client. Go to Android Settings → Apps → Primal → Storage → Clear Data. This forces Android to physically purge the app's storage area.

Restart via Signer. Open the "fresh" client. When logging in, do NOT select "Enter nsec." Select "Log in with external signer" (often a key icon).

Authorize. Amber will open and ask for permission. Confirm it. Done.

You are now using the client merely as an interface. Your key lies securely in the vault of Amber.

────────────────

Verdict: Reclaim Your Authority

Convenience is the enemy of security. Copy-pasting private keys is a bad habit from the Web2 world that we must discard.

Migrating to a signer like Amber effectively transforms your smartphone into a "Hardware Wallet Light." You trade a systemic risk (key in clipboard and app) for a hardened architecture.

Even if it takes five minutes: Do it. Your digital identity is worth it.

────────────────

The Nostr Sovereignty Series

The Foundation: How to start correctly. The Sovereign Protocol: Architecture of an Unconfiscatable Digital Identity https://primal.net/Alien-Investor/the-sovereign-protocol-architecture-of-an-unconfiscatable-digital-identity

The Proof: How to get verified without permission. The Silver Badge: Immortalize Your Nostr Identity https://primal.net/Alien-Investor/the-silver-badge-immortalize-your-nostr-identity

The Economy: Escaping the walled gardens. Nostr Zap Store: Attacking the App Store Monopoly https://primal.net/Alien-Investor/nostr-zap-store-attacking-the-app-store-monopoly

────────────────

Money, power, Bitcoin — and OPSEC. I write about financial sovereignty, privacy, and cybersecurity in a world built on control. More at alien-investor.org *(German only)*👽

Great work! Really well put together... I think the only missing ...

2025-12-28T03:18:39Z

In reply to nevent1q…ep9k
_________________________

Great work! Really well put together... I think the only missing part is the marketing...

I only came across it by accident when doom scrolling - and didn't see it on places like nostrapps.com or zapstore.dev?

Also think you need to tell the creators what is better about it (for them) - zaps? decentralised? Whatever..

Maybe look for content creators using Peertube - offer to help repost their content or something... people like Nick @ The Linux Experiment (npub1djp…8kck) or The New Oil (npub1seh…fsgc)

Published new Nostr Community Convention: ncc-06 - NCC-02 / ...

2025-12-28T02:27:32Z

Published new Nostr Community Convention: ncc-06 - NCC-02 / NCC-05 Service Profile

NCC-06 updated: NCC-02 / NCC-05 Service Profile

NCC-06 now formally defines a service participation profile that composes NCC-02 and NCC-05 for identity-first, DNS-optional service discovery.

It specifies what a service, sidecar, and client must do to support:

Pubkey-owned service identity

Deterministic client-side resolution and trust

Dynamic endpoint rotation

Tor and onion services as first-class endpoints

Robust behaviour under partial failure and inconsistent data

NCC-06 does not change underlying protocols, add new message types, or move resolution or trust logic into services. Services remain protocol-dumb. Clients remain in control.

#nostr #ncc-02 #ncc-05 #ncc-06 #service #no-dns #nostrdev

quoting
naddr1qv…mv52
# NCC-06: NCC-02 / NCC-05 Service Profile

## Type

Convention

## Layer

Application

## Related NCCs (Informative)

- NCC-00: Publication, revision, and discovery of NCC documents on Nostr.
- NCC-02: Pubkey-owned service discovery, endpoint identity binding, trust material (`k`), attestations, and revocations.
- NCC-05: Dynamic endpoint location and rotation for Nostr-identified services.

NCC-06 defines a service participation profile that composes NCC-02 and NCC-05 for identity-first, DNS-optional service discovery.

---

## Summary

This Nostr Community Convention defines an opt-in service participation profile for any Nostr-identified service that supports identity-first service discovery using NCC-02 (Service Discovery and Trust) and NCC-05 (Dynamic Locators).

Services conforming to this profile are discovered and addressed via Nostr identity rather than DNS, while remaining fully compatible with their respective protocols (e.g. NIP-01 for relays, HTTP for APIs).

This convention does not modify underlying protocols, introduce new message types, or require services to perform client-side resolution or trust evaluation.

---

## Purpose

This NCC defines what a service must publish and serve in order to participate in an NCC-02 / NCC-05-based discovery model, enabling:

- Identity-anchored service addressing
- DNS-optional endpoint resolution
- Dynamic endpoint rotation
- First-class support for Tor and onion services
- Deterministic, client-side resolution and trust decisions
- Robust behaviour under partial failure and inconsistent data

---

## Scope

This convention specifies:

- A service participation profile for NCC-02 and NCC-05
- Required and recommended behaviours for services, sidecars, and clients under this profile
- Deterministic conflict handling and caching rules for clients (without moving logic into services)
- Publication redundancy expectations for sidecars to reduce single points of failure

### Identity-First Addressing

Services conforming to this profile are addressed by **Nostr identity**, not by DNS hostnames.

Clients are expected to refer to such services using identity-based URIs (for example `wss://` for relays or `https://` for APIs), which function as **identity references**, not concrete network endpoints.

These identity-based URIs MUST NOT be dereferenced directly. Clients MUST resolve them via NCC-02 and NCC-05 before establishing a network connection.

Services MUST NOT accept, interpret, or resolve identity-based URIs.

This convention does not specify:

- New service-client protocol behaviour
- Service-side trust enforcement or validation
- DNS-based discovery or identifiers
- Browser or WebView integration
- Internal service architecture or storage design

---

## Dependencies

Services conforming to this profile MUST support:

- NCC-00 (NCC publication and discovery)
- NCC-02 (Service discovery and trust)
- NCC-05 (Dynamic locators)

---

## Definitions

### NCC-02 / NCC-05 Service

A service (e.g. a relay, API, or media server) that opts into this convention by publishing and serving NCC-02 and NCC-05 records describing itself, and by making those records available to querying clients.

### Service Identity

The Nostr public key (`npub`) that uniquely identifies the service.

### Sidecar

A dedicated companion component operated alongside the service. It is the primary actor responsible for enabling NCC-06 compliance by publishing and maintaining NCC-02 and NCC-05 records for the service's identity.

### Publication Relay Set

A set of relays used to publish and retrieve NCC-02/NCC-05 records, including (ideally) the target relay itself plus additional relays to avoid a single point of failure.

### Freshness

A record is **fresh** if it is within its declared validity window:
- NCC-02 Service Record: within its `exp`
- NCC-05 Locator: within its TTL (or equivalent freshness tags defined by NCC-05)

---

## Service Requirements (e.g. Relays)

A service (such as a relay) claiming conformance to this profile MUST:

### 1. Protocol Compliance

- Support its base protocol (e.g. NIP-01 for relays, HTTP for APIs)
- For relays: Support standard `EVENT`, `REQ`, `CLOSE`, and `EOSE` semantics

### 2. NCC Document Support (NCC-00)

- Accept, store, and serve NCC documents as defined by NCC-00
- At minimum, support publication and retrieval of:
- NCC-00
- NCC-02
- NCC-05
- NCC-06
- Treat NCC documents as ordinary Nostr events
- MUST NOT interpret or enforce NCC semantics

### 3. NCC-02 Service and Trust Records

The service MUST:

- Accept, store, and serve NCC-02-related events, including:
- Service Records (kind 30059)
- Certificate Attestations (kind 30060)
- Revocations (kind 30061)
- Treat all NCC-02-related events as opaque data
- MUST NOT evaluate trust, validate keys, or apply revocations

The service MUST publish at least one Service Record (30059) describing itself.

Publishing attestations or revocations is OPTIONAL.

### 4. NCC-05 Locator Records

- Accept, store, and serve NCC-05 Locator events (kind 30058)
- Publish at least one locator describing current reachable endpoints
- Locator records MAY include multiple endpoints, including onion services

### 5. Self-Describing Behaviour

- The service MUST return its own NCC-02 and NCC-05 records when queried via standard Nostr filters
- Self-publication MAY be performed by a Sidecar or equivalent process

### 6. Client Resolution Neutrality

The service:

- MUST NOT perform NCC-02 or NCC-05 resolution on behalf of clients
- MUST NOT validate endpoint keys or compare `k` values
- MUST NOT evaluate attestations or revocations
- MUST NOT redirect, proxy, or influence endpoint selection
- MUST remain protocol-dumb with respect to resolution and trust

---

## Robustness Requirements

This section defines required or recommended behaviours to handle real-world failure modes without adding service-side intelligence.

### A. Conflicting Records (Normative Client Handling)

Clients MUST assume they may receive multiple candidate records for the same `(service pubkey, kind, d)` due to:
- service divergence
- propagation delays
- sidecar misconfiguration
- malicious publication

Clients MUST apply a deterministic selection rule per record type:

#### A.1 Selecting NCC-02 Service Records (kind 30059)

Given a set of candidate Service Records matching `(pubkey, d)`:
1. Discard records with invalid signatures.
2. Discard records that are expired (`now > exp`) unless operating in **stale fallback** mode (see Section D).
3. Prefer the record with the greatest `created_at`.
4. If tied on `created_at`, prefer the record with the lexicographically greatest event id.

If the chosen record’s `u` points to an endpoint that is unreachable, clients SHOULD try alternate valid candidates in descending order before failing (see Section B).

#### A.2 Selecting NCC-05 Locators (kind 30058)

Given a set of candidate Locator records matching `(pubkey, d)`:
1. Discard records with invalid signatures.
2. Discard records that are stale by TTL unless operating in **stale fallback** mode (see Section D).
3. Prefer the record with the greatest freshness marker as defined by NCC-05 (for example `updated_at`), otherwise `created_at`.
4. If tied, prefer lexicographically greatest event id.

Clients SHOULD treat Locator endpoints as an ordered candidate set, not a single truth, and apply reachability and policy selection (see Sections B and E).

### B. Partial Availability (Normative Client Behaviour)

Clients MUST NOT assume that a “correct” record implies a reachable endpoint.

When resolving to endpoints, clients SHOULD:
- try endpoints in a policy-defined preference order (see Section E)
- stop on first successful connection
- record per-endpoint health with exponential backoff on failures
- avoid retry storms by applying jitter and minimum retry intervals
- maintain a “last known good endpoint” cache keyed by `(pubkey, d)`

Sidecars SHOULD publish multiple endpoints when available (for example multiple PoPs, clearnet plus onion, alternate ports) to increase survivability.

### C. Service Unavailability (Normative Publication and Retrieval)

A core failure mode is: the service storing its own NCC-02/NCC-05 records is unreachable.

#### C.1 Sidecar Publication Redundancy (Normative)

Sidecars operating under NCC-06 MUST publish NCC-02 and NCC-05 records to:
- the service itself (local-first bootstrap) when reachable, AND
- at least one additional relay in a configured Publication Relay Set

Sidecars SHOULD publish to multiple additional relays to reduce correlated failure.

#### C.2 Client Retrieval Redundancy (Normative)

Clients MUST query for NCC-02 and NCC-05 records across a Publication Relay Set, not only the target service endpoint(s).

If the client has no configured Publication Relay Set, it SHOULD use a small default set (implementation-defined).

If all publication relays are unreachable or return no valid records:
- clients MAY fall back to a user-supplied concrete endpoint, or a previously cached endpoint,
- otherwise resolution fails.

### D. Caching, Staleness, and Fallback (Normative)

Clients will cache NCC-02 and NCC-05 records for performance and reliability. Caching creates staleness risk.

#### D.1 Cache Keys

Clients SHOULD cache by:
- NCC-02 Service Record: `(pubkey, d, kind=30059)`
- NCC-05 Locator: `(pubkey, d, kind=30058)`

Clients SHOULD store:
- selected event id
- record `created_at`
- retrieval time (`fetched_at`)
- record validity window (`exp` or TTL metadata)
- derived endpoint list

#### D.2 Freshness Enforcement

Clients MUST treat records as non-fresh when:
- NCC-02: `now > exp`
- NCC-05: TTL window has elapsed per NCC-05 definition

#### D.3 Stale Fallback Mode

To avoid hard failure during propagation delays or temporary publication relay outages, clients MAY enter stale fallback mode when:
- no fresh valid record is obtainable, AND
- the client has at least one previously cached valid record

In stale fallback mode:
- clients MAY use the newest previously cached record even if stale
- clients SHOULD apply a maximum staleness window (implementation-defined)
- clients MUST surface (internally or to the user) that a stale record was used
- clients SHOULD aggressively refresh in the background on subsequent attempts (without retry storms)

### E. Multiple Valid Paths and Trust (Normative Client Policy)

When multiple endpoints are available, clients must choose based on both reachability and trust.

#### E.1 Transport Preference

Unless the user explicitly overrides, clients SHOULD apply:
1. Prefer secure endpoints (`wss://`, `https://`, `tls://`) with verifiable `k`
2. Then secure endpoints without `k` (lower trust)
3. Then onion endpoints when Tor-capable and allowed by user policy
4. Avoid insecure clearnet endpoints (`ws://`, `http://`, `tcp://`) unless explicitly configured

#### E.2 `k` Verification Requirements

- For secure endpoints, clients SHOULD verify the endpoint key material against NCC-02 `k` where defined by NCC-02.
- If `k` is present and does not match, clients MUST treat that endpoint as failing trust and MUST NOT connect to it unless the user explicitly overrides.
- If `k` is absent, clients MAY connect according to local policy, but SHOULD treat it as lower trust.

#### E.3 Conflicts Between Trust Paths

If multiple fresh records exist and imply different trust bindings (different `k` values or materially different endpoint sets), clients SHOULD:
- prefer the candidate record whose `k` matches the observed endpoint key on successful connection
- otherwise fall back to the deterministic conflict rules in Section A and treat the result as untrusted until verified

Services MUST remain neutral and MUST NOT enforce these rules.

---

## Sidecar Trust and Publication Responsibilities

A Sidecar operating under this profile MUST, when publishing NCC-02 Service Records:

- Publish a valid `k` tag identifying the service endpoint’s cryptographic key where applicable
- Ensure the published `k` corresponds to the key actually presented by the endpoint
- Update or rotate Service Records when:
- endpoint keys change
- endpoint locations change
- records approach expiry

In addition, sidecars operating under NCC-06:

- MUST publish to a Publication Relay Set (see Section C.1)
- SHOULD publish multiple endpoints where possible to improve survivability (see Section B)
- SHOULD avoid publishing short expiries or TTLs that cannot be reliably refreshed under normal operation

The sidecar MAY publish Certificate Attestations or Revocations.

The sidecar MUST NOT assume service-side or client-side trust acceptance.

---

## Transport Selection and `k` Semantics

### Transport Recommendations

- Sidecars SHOULD publish at least one secure clearnet endpoint (e.g. `wss://` or `https://`)
- Sidecars MAY publish onion endpoints using:
- `ws://`
- `wss://`
- Clients SHOULD prefer secure protocols over insecure ones when both are available
- Clients MAY accept `ws://` where Tor provides the underlying security context
- Clients SHOULD NOT select insecure clearnet endpoints unless explicitly configured

### `k` Tag Semantics

- For secure endpoints, the NCC-02 `k` tag SHOULD be a public key fingerprint (e.g. TLS SPKI) suitable for pinning
- For insecure endpoints, the `k` tag MAY be omitted unless a verifiable non-TLS key identity is defined and supported by the client
- Clients MUST treat `k` as an assertion and verify it independently

---

## Onion Endpoints (Informative)

NCC-06 supports onion endpoints as a first-class deployment option to enable DNS-optional and location-hiding service access.

### Publishing onion endpoints

A service MAY publish one or more onion endpoints in its NCC-05 Locator (kind 30058) endpoints list.

Typical forms include:

- `ws://.onion:` (common)
- `wss://.onion:` (optional defence-in-depth)

Onion endpoints SHOULD be published via NCC-05 (dynamic locator) rather than being assumed stable or discoverable elsewhere.

### Transport and trust considerations

- Onion endpoints using `ws://` rely on Tor’s security properties for confidentiality and endpoint authentication.
- The NCC-02 `k` tag binds the service identity to the key presented by the transport endpoint and therefore applies to secure endpoints only.
- Clients SHOULD NOT require `k` verification for `ws://` onion endpoints.
- Clients MAY apply additional local policy, such as preferring onion endpoints when Tor is available.

### Operational model

An onion endpoint MAY be:
- managed by the service operator externally, or
- managed by an administrative sidecar that creates and maintains the hidden service and republishes NCC-05 when endpoints change.

Services remain protocol-dumb and do not participate in endpoint discovery or onion service management.

---

## Client Interaction Model (Informative)

Clients interacting with services conforming to this profile are expected to:

1. Identify the service by Nostr identity (for example via an identity-based URI such as `wss://` or `https://`), not by hostname
2. Resolve NCC-02 Service Records and trust material
3. Apply attestation and revocation policy locally
4. Resolve NCC-05 Locators for current endpoints
5. Apply conflict handling, caching, and fallback rules (Sections A–D)
6. Select endpoints based on transport and trust policy (Section E)
7. Connect using the service's base protocol (e.g. NIP-01 for relays)
8. Verify endpoint key against NCC-02 `k` when using secure transports

Identity-based URIs are not dereferenced directly and are always resolved through NCC-02 and NCC-05 prior to connection.

Services do not participate in this logic.

---

## Security Considerations

- All NCC-02 and NCC-05 records are signed using standard Nostr keys
- Trust, pinning, and revocation are client-side responsibilities
- Services act solely as neutral event stores
- Publication relay redundancy reduces availability risks but does not remove the need for client-side trust evaluation

---

## Non-Goals

This convention does not attempt to:

- Implement or rely on DNS or NIP-05
- Guarantee service availability
- Prevent Sybil attacks
- Define moderation, certification, or access control policy

---

## Conformance Tests (Non-Normative)

A service conforms to NCC-06 if:

- It serves kinds 30058, 30059, 30060, and 30061
- It serves NCC documents per NCC-00
- It responds with correct `EOSE` semantics
- It is protocol-compatible with its base protocol when accessed via a concrete endpoint
- It does not resolve identity references for clients, and remains protocol-dumb

A sidecar conforms to NCC-06 publication robustness expectations if it:
- publishes NCC-02 and NCC-05 records to a Publication Relay Set (not only the target service)

A client conforms to NCC-06 robustness expectations if it:
- applies deterministic conflict selection (Section A)
- handles partial endpoint availability with ordered attempts and backoff (Section B)
- queries multiple publication relays for records (Section C.2)
- enforces freshness and uses bounded stale fallback (Section D)
- applies transport and `k` trust policy (Section E)

---

## Relationship to Other NCCs

- Builds on NCC-00, NCC-02, and NCC-05
- Defines a service participation profile without protocol changes
- Remains orthogonal to DNS-based and gossip-based discovery

---

## Conclusion

NCC-06 defines a minimal, identity-first service profile that composes service discovery, trust assertion, and dynamic location using existing Nostr primitives, while preserving strict separation between storage, assertion, and enforcement.

It additionally specifies deterministic and robust client and sidecar behaviours to handle conflicting records, partial availability, service unavailability, and caching staleness, without moving resolution or trust enforcement into services.

---

## Appendix A: Minimal Reference Implementation (Informative)

This appendix describes a minimal, working-shaped system that conforms to NCC-06. It illustrates **component roles and responsibilities**, not a production deployment or complete failure handling logic.

The reference implementation consists of three logical components:

1. A protocol-dumb service (e.g. a NIP-01 relay)
2. A Sidecar for NCC-02 and NCC-05 records
3. A policy-aware client

Each component is intentionally simple and narrowly scoped.

---

### A.1 Protocol-Dumb Service

The service is a standard event store (like a NIP-01 relay) with no NCC-specific logic.

The service:

- Accepts and serves Nostr events using standard semantics
- Stores and serves NCC documents (NCC-00, NCC-02, NCC-05, NCC-06) as ordinary events
- Stores and serves NCC-02 Service Records, attestations, and revocations
- Stores and serves NCC-05 Locator records
- Does not interpret event content, tags, or semantics
- Does not resolve identities, select endpoints, or evaluate trust

The service may be unreachable, partially reachable, or out of sync with other relays. It is not assumed to be authoritative.

The service MAY store its own NCC-02 and NCC-05 records, but MUST NOT be treated as the sole source of those records.

---

### A.2 Sidecar

The sidecar is an out-of-band process operated alongside the service. It is responsible for **asserting service state**, not enforcing it.

The sidecar:

- Publishes NCC-02 Service Records (kind 30059) for the service identity
- Publishes NCC-05 Locator records (kind 30058) describing current reachable endpoints
- Optionally publishes NCC-02 attestations or revocations
- Maintains the correspondence between published records and actual service state

To conform with NCC-06 robustness expectations, the sidecar:

- Publishes records to a **Publication Relay Set**, not to a single relay
- Attempts publication to the target service when reachable
- Publishes to at least one additional relay to avoid single points of failure
- Republishes records when:
- endpoints change
- endpoint keys change
- records approach expiry
- May publish multiple endpoints (for example multiple PoPs, clearnet and onion) to improve availability

The sidecar does not assume that any single relay will always be reachable or consistent.

The sidecar does not perform client resolution, endpoint selection, or trust enforcement.

---

### A.3 Policy-Aware Client

The client is responsible for **resolution, selection, caching, and trust decisions**.

The client:

1. Identifies the service by Nostr public key (service identity)
2. Queries a Publication Relay Set for NCC-02 Service Records and related trust material
3. Applies deterministic conflict resolution to select candidate records
4. Enforces freshness rules and caches records with validity metadata
5. Falls back to bounded stale records when fresh records are unavailable
6. Queries for NCC-05 Locator records and derives an ordered endpoint set
7. Attempts endpoints in policy-defined order with backoff and retry control
8. Verifies endpoint key material against NCC-02 `k` where applicable
9. Establishes a connection to the selected endpoint using the service's base protocol

The client:

- Does not assume global consistency
- Does not assume immediate propagation
- Does not assume a single valid path
- Treats all records as assertions, not guarantees

All trust, caching, and selection logic is strictly client-side.

---

### A.4 Failure and Degradation Model

This reference implementation assumes:

- Conflicting records may exist across relays
- Some relays may be unreachable
- Some endpoints may be temporarily unavailable
- Cached data may become stale

Correct operation is achieved through:

- Redundant publication by the sidecar
- Redundant retrieval by the client
- Deterministic client-side conflict handling
- Bounded stale fallback
- Ordered endpoint attempts

No component relies on service-side enforcement or consensus.

---

### A.5 Summary

This reference implementation demonstrates that:

- Services remain protocol-dumb and interchangeable
- Sidecars assert service state redundantly
- Clients resolve identity, trust, and location deterministically

NCC-06 achieves robustness through **composition and policy**, not through additional protocol features or service intelligence.

## Companion `ncc-06-js` package

To make the NCC-06 resolver, selector, and NCC-02/NCC-05 helpers reusable outside of this specific example harness, there's a dedicated `ncc-06-js` npm package in the repository. It provides:

- **Service-Agnostic Helpers:** Full support for `serviceUrl`, `serviceMode`, and custom `allowedProtocols` (e.g. `https`, `tcp`), allowing discovery for any Nostr-identified service.
- **Deterministic NCC-06 resolution:** Resolver orchestration that fetches service records, locators, and enforces `k` fingerprints for any secure protocol (`wss`, `https`, `tls`, etc).
- **NCC-02/NCC-05 builders & validators:** Logic to parse and manage the `d`, `u`, `k`, and `exp` tags a service record must expose.
- **External endpoint helpers:** Helpers to declare onion/IPv6/IPv4 reachability in a reproducible order.
- **Key and trust utilities:** SPKI fingerprint calculation (`k`), keypair management, and certificate generation.

Published new Nostr Community Convention: ncc-05 - Identity-Bound ...

2025-12-28T00:13:42Z

Published new Nostr Community Convention: ncc-05 - Identity-Bound Service Locator Resolution

NCC-05 update published

NCC-05 now clearly defines identity-bound, encrypted service locator resolution for dynamic ip:port endpoints, without DNS or public infrastructure.

What’s new and clarified:

Explicit anchored vs unanchored operating modes

Anchored mode (recommended): NCC-02 provides identity and trust, NCC-05 provides private reachability

Unanchored mode (permitted): supports ephemeral, P2P, and bootstrap use cases

Formalised endpoint object format with deterministic selection

Stronger guidance on TLS key binding (k) to prevent endpoint substitution

Clear TTL, expiration, caching, and refresh semantics

Deterministic record and endpoint selection to improve interoperability

Explicit support for private and invite-only services

NCC-05 remains client-agnostic, relay-agnostic, and fully compatible with existing Nostr primitives, while enabling private, low-cost alternatives to Dynamic DNS.

#nostr #nameresolution #privacy

quoting
naddr1qv…cfga
# NCC-05: Identity-Bound Service Locator Resolution

**Status:** Draft
**Category:** Discovery / Resolution
**Author(s):** lostcause
**Supersedes:** None

**Related NCCs (Informative)**

- NCC-02: May advertise service identities and intent; NCC-05 provides private reachability.

- NCC-00: Publication and revision conventions.

**Integration with NCC-02 (Informative)**

NCC-02 may be used to publish public service records and trust material for a service identity. Clients MAY attempt NCC-05 resolution for the same service identity as a private override. If NCC-05 resolution succeeds and the record is fresh, clients SHOULD prefer the NCC-05 resolved endpoint for connection while continuing to apply any NCC-02 trust checks (eg endpoint key pinning) where applicable.

---

## Abstract

This Nostr Community Convention defines a client-agnostic method for resolving **dynamic `ip:port` service endpoints** bound to a cryptographic identity, using existing Nostr primitives.

The primary goal of this convention is to enable **cost-effective, private resolution of dynamic `ip:port` endpoints** without relying on domain names, registrars, Dynamic DNS providers, or publicly observable infrastructure.

Clients publish signed, TTL-bound, **encrypted** service locator records as parameterised replaceable events (`kind:30058`). IP address and port information is distributed via Nostr relays without exposing network topology to relays or third parties.

Alternative locator types such as tunnels, overlays, or onion services MAY be included for resilience, but are secondary to the core `ip:port` resolution use case.

This convention does not modify the Nostr protocol or require relay enforcement. It standardises client behaviour for publishing, resolving, caching, and expiring locator records.

---

## 1. Purpose

NCC-05 primarily addresses the problem of **privately resolving dynamic `ip:port` endpoints** in environments where traditional DNS or Dynamic DNS introduces unnecessary cost, public metadata exposure, or operational dependency.

The convention defines shared expectations for:

- publishing encrypted `ip:port` reachability information bound to a pubkey

- resolving that information deterministically

- supporting frequently changing network addresses

- minimising relay load and metadata leakage

- avoiding dependence on registrars, domains, or central services

---

## 2. Scope

This convention applies to:

- client behaviour for publishing encrypted locator records

- deterministic resolution and caching logic

- TTL and refresh semantics

- privacy and abuse mitigation expectations

This convention does **not** define:

- new cryptographic primitives

- relay enforcement rules

- domain name integration

- protocol-level changes

---

## 2.1 Leveraged NIPs

NCC-05 relies entirely on existing Nostr Improvement Proposals and does not introduce new protocol primitives.

### NIP-01: Basic protocol flow

Used for:

- event structure and encoding

- event signing and verification

- relay publish and subscription semantics

- `created_at` ordering

- tag-based filtering, including the `d` tag

All `kind:30058` locator records are valid NIP-01 events.

---

### NIP-16: Replaceable and parameterised replaceable events

Used for:

- parameterised replaceable semantics

- replacement based on `pubkey + kind + d`

- deterministic latest-state resolution

---

### NIP-33: Parameterised replaceable kind ranges

Defines the `30000–39999` range.

This convention assigns **`kind:30058`** for identity-bound service locator records.

---

### NIP-04 and NIP-44: Encrypted event content

Used to encrypt `ip:port` locator payloads.

This convention:

- mandates encryption by default

- does not require a specific encryption NIP

- allows clients to support one or more schemes

---

### NIP-65: Relay List Metadata (Gossip)

NCC-05 MAY leverage relay hints published via NIP-65 to improve resolution efficiency and reliability.

When resolving locator records, clients:

- MAY query relays listed in the target pubkey’s NIP-65 relay list

- SHOULD prefer relays marked for read or both read/write access

- MAY fall back to locally configured or default relays if no NIP-65 data is available

NIP-65 is used strictly as a **hint mechanism** and does not alter NCC-05 resolution semantics or trust assumptions.

---

### Explicit non-dependencies

NCC-05 deliberately does **not** rely on:

- DNS or naming-related NIPs

- relay moderation or enforcement NIPs

- payment, zap, or wallet NIPs

- profile or alias NIPs

---

## 3. Conceptual Model

NCC-05 provides **DNS-like resolution semantics for encrypted `ip:port` reachability**, using Nostr events as the distribution mechanism.

| DNS concept | NCC-05 analogue |
| --- | --- |
| Domain name | Pubkey |
| Record name | `d` tag |
| A / SRV record | Encrypted `ip:port` entry |
| TTL | Payload TTL |
| Authoritative server | Signature + freshness |
| Resolver cache | Client cache |

Resolution is identity-centric and private by default.

---

## 4. Event Model

### 4.1 Event kind

Locator records **MUST** be published as **parameterised replaceable events** of:

- `kind:30058`

Replaceability is determined by:

- `pubkey`

- `kind = 30058`

- `d` tag value

Clients **MUST** treat locator records as latest-state only.

---

### 4.2 Required tags

| Tag | Description |
| --- | --- |
| `d` | Stable locator record identifier |

The `d` tag **MUST** remain stable.

Recommended values:

- `addr`

- `addr:v1`

- `addr:`

---

### 4.3 Optional tags

- `expiration` – Unix timestamp indicating when the locator event SHOULD be treated as expired.
- Clients SHOULD treat expiry as the earliest of:
- `expiration`, and
- `updated_at + ttl` from the decrypted payload.

- `private` – Boolean marker (for example `["private","true"]`) indicating the publisher intends the locator record for authorised use only.
- This tag does not provide privacy by itself.
- Privacy is provided by encryption and recipient scoping.

---

## 5. Payload Format and Encryption

### 5.1 Mandatory encryption

Service locator records **MUST NOT expose `ip:port` data in plaintext by default**.

Event content:

- **MUST** be encrypted when publishing `ip:port` data

- **MUST NOT** include address data in tags

- **MUST** assume relays are not trusted

---

### 5.2 Plaintext exception

A plaintext record MAY be published only if:

- the endpoint is intentionally public

- metadata disclosure is acceptable

- the publisher explicitly opts out of privacy

Clients **MUST NOT** treat plaintext records as private.

---

### 5.3 Payload structure (encrypted)

Logical structure:

- `v`: payload version

- `ttl`: time-to-live in seconds

- `updated_at`: unix timestamp

- `endpoints`: ordered list of endpoint objects

- `caps`: optional capability identifiers

- `notes`: optional text

Direct `ip:port` endpoints are the **primary and expected** use case.

### 5.4 Endpoint object format (Normative)

Each entry in `endpoints` MUST describe a reachable transport endpoint.

Required:
- `url` – full endpoint URL.

Optional but strongly recommended:
- `priority` – integer where lower values are preferred (default `1000`).
- `family` – `onion`, `ipv6`, or `ipv4`.
- `k` – transport key fingerprint for TLS-protected endpoints.

For `wss://` endpoints:
- Publishers SHOULD include `k`.
- Clients SHOULD fail closed when `k` is present and does not match the observed transport identity.

---

## 6. Publishing Behaviour

Clients publishing locator records:

- **MUST** encrypt `ip:port` data by default

- **MUST** sign records with the resolved pubkey

- **MUST** publish only current reachability state

- **SHOULD** publish on change or bounded refresh

- **SHOULD** jitter refresh timing

- **MUST NOT** publish redundant updates

---

## 7. Resolution Algorithm

Unless explicitly operating in unanchored mode, clients SHOULD resolve and validate a corresponding NCC-02 Service Record before accepting NCC-05 locator records.

### Input

- target `pubkey`

- locator name (`d` tag), default `addr`

### Relay selection

Clients SHOULD determine an initial relay set using the following order:

1. Relays advertised by the target pubkey via NIP-65, if available

2. Client-configured default relays

3. Additional relays as required to complete resolution

Relay selection does not affect record validity.

### Query

Clients query selected relays for:

- author = target pubkey

- kind = 30058

- matching `d` tag

### Record selection (Normative)

When multiple locator events exist for the same identity:
1. Select the event with the greatest `created_at`.
2. If equal, select the lexicographically smallest event `id`.

### Event selection

Clients:
1. discard invalid signatures
2. discard undecryptable payloads
3. pass all remaining candidate events to record selection

### Freshness validation

Records are valid only if:

- `now <= updated_at + ttl`

Expired records **MUST NOT** be used.

### Endpoint selection (Normative)

Clients SHOULD select endpoints deterministically:
1. Sort by ascending `priority`.
2. For equal priority, apply a deterministic family order (for example `onion`, then `ipv6`, then `ipv4`).
3. Attempt endpoints in order until a connection succeeds.
4. Clients SHOULD apply cooldowns to failed endpoints to avoid retry storms.

Endpoint failure does not invalidate the record.

---

## 8. Caching and Expiry

- Clients MUST treat a locator record as expired when `now > updated_at + ttl`.
- If an `expiration` tag is present, clients SHOULD treat expiry as the earliest of:
- `expiration`, and
- `updated_at + ttl`.

Expired records:
- Clients SHOULD NOT use expired records by default.
- Clients MAY retain one expired record as a short-lived fallback only in explicit override or recovery modes.

TTL rules:
- TTL MUST NOT be extended by resolvers.
- Publishers SHOULD refresh locator records before expiry using jittered schedules.

---

## 9. Privacy Considerations

Encryption protects:

- IP address and port

- network topology

Encryption does not protect:

- pubkey identity

- existence of a locator record

- publish timing

Using NIP-65 relay hints can reduce unnecessary broadcast queries and limit metadata exposure during resolution.

Relays are assumed honest-but-curious.

---

## 10. Abuse and Relay Load

- Records **SHOULD** be small and replaceable

- Publish frequency **SHOULD** align with TTL

- Relays **MAY** apply rate limits or policy

---

## 11. Comparison to Dynamic DNS

Dynamic DNS publishes **public, domain-bound `ip:port` mappings**.

NCC-05 publishes **encrypted, identity-bound `ip:port` mappings** without domains, registrars, or subscriptions.

---

## 12. Non-Goals

This convention is not intended for:

- public website discovery

- human-readable naming

- anonymous global resolution

---

## 13. Why This Is an NCC

NCC-05 standardises **client usage patterns**, not protocol rules.

It uses existing primitives and avoids relay mandates.

---

## 14. Summary

NCC-05 defines **encrypted, identity-bound resolution of dynamic `ip:port` endpoints** using Nostr.

It provides a private, low-cost alternative to Dynamic DNS while remaining fully compatible with the existing protocol.

---

## Appendix A: Example Locator Record and Resolution Flow

### A.1 Example scenario

A user operates a self-hosted service reachable at a dynamic endpoint that may change networks, addresses, or ports.

The user wants authorised clients to discover the current endpoint privately, without exposing it publicly or relying on Dynamic DNS.

---

### A.2 Publishing the locator record

The service publishes a parameterised replaceable event with:

- `kind:30058`

- `d=addr`

- encrypted `content`

#### Example logical content (inside encryption)

- `v`: 1

- `ttl`: 600

- `updated_at`: 1766726400

- `endpoints`:

- type: tcp
uri: `[2001:db8:abcd:42::10]:9735`
priority: 5
family: ipv6

- type: tcp
uri: `203.0.113.42:9735`
priority: 10
family: ipv4

- `caps`:

- nostr-connect

---

### A.2.1 IPv6 considerations

- IPv6 endpoints MAY be included alongside IPv4 endpoints.

- Clients SHOULD attempt endpoints strictly by priority.

- IPv6 literals MUST use standard bracket notation with ports.

- Publishers MAY omit IPv4 endpoints entirely in IPv6-only environments.

---

### A.3 Replaceability and updates

When the service address changes, the publisher emits a new `kind:30058` event using the same `d` tag and a newer `created_at`.

Clients automatically treat the latest event as authoritative.

---

### A.4 Client resolution process

A resolving client:

1. Determines relay set, preferring NIP-65 hints if available.

2. Queries for `kind=30058` events with matching `d` tag.

3. Verifies signature and decrypts payload.

4. Selects the latest valid event.

5. Attempts endpoints by priority.

---

### A.5 Failure handling

If an endpoint connection attempt fails:

- the client MAY attempt the next endpoint

- the locator record remains valid until expiry

---

### A.6 Privacy properties demonstrated

This example demonstrates that:

- `ip:port` data is never visible to relays

- observers cannot infer network topology

- resolution requires prior knowledge of the pubkey

- historical addresses are not exposed

---

### A.7 Relationship to application or browser resolution

Browser extensions, proxies, or custom URI handlers MAY build on NCC-05, but are outside the scope of this convention.

---

### A.8 Summary

Appendix A illustrates how NCC-05 enables encrypted, identity-bound resolution of dynamic `ip:port` endpoints using only existing Nostr primitives.