Josh

Hey mate, you are welcome. It protects your Nostr private key the same way you would your BTC private key, in a hardware wallet. Hash in, signed hash out.
You can view and accept or decline the message being parsed. Or set to automatically sign.
On Nostr our keys are not rented from a platform. The keys are ours (or should be) so you are only as sovereign as the key is safe.
The signers job is to make protecting it and using it the same thing , not a trade off.

2026-07-20 06:00:17 UTC

- reply

GM QnA

2026-07-20 00:31:20 UTC

- reply

Thanks, this lines up with how we're thinking, and the identity/signing-key split you've built into Inkan is the same seam we're designing along.
Bitcoin: the real Wi-Fi concern is a remote RCE, so we bracket every transaction with a secure-boot cycle before and after to force a fresh state, and airgapped QR-only mode removes the Wi-Fi RCE surface entirely. Even without airgap, the seed is never plaintext at rest: it's SE-protected and only unwrapped for milliseconds during signing. We originally wanted to offer the QR-or-local-network choice, but we're now leaning toward removing the non-airgapped path entirely and dropping local HTTP with it. Some users won't grasp the risk, and defaults matter more than options when the downside is losing funds. Airgapped QR is still quick for everyday amounts.
Nostr: the identity key is harder because it has to be live to sign on demand, and you can't airgap an interactive signer. So we isolate it on a dedicated second MCU with a tiny attack surface: its only input is a 32-byte hash, it never parses anything, and the nonce is generated in-chip. The scoped claim: no known remote software path can extract the key, because it never enters the network-facing processor. We keep fuzzing our parsers, but that's a different risk, stopping a malicious message from getting the device to sign something it shouldn't, not key extraction. Even then the key stays put and the worst case is a signature you didn't intend, which is recoverable. And the fully airgapped path is always there.
Physical is different. With physical possession of an unlocked device and the right tooling, someone could force a signing event and capture the key in plaintext as the signer uses it. But that means they're already holding your unlocked device, where most security models are in trouble anyway. That's the window our motion lock is built for: it locks the moment the device is moved or handled unexpectedly. It's working well in-house and going to beta before we make firm claims. It doesn't make the theory of physical extraction impossible, nothing does, but it closes the unlocked-and-unattended window this attack depends on.
On whether Inkan's delegation and revocation signing could run on this hardware: yes, and it's arguably a better fit than our own Nostr path. Ethereum delegation transactions are ECDSA over secp256k1, the SE051's native on-chip operation, so the key stays resident in the secure element and never becomes plaintext at all, the exact property we can't fully get for Nostr Schnorr but get for free on your Ethereum case. One caveat: your delegation format presumably wraps the signature in some typed-data encoding (EIP-712 or similar). The primitive is still SE-native ECDSA either way, since encoding and hashing happen host-side before the hash reaches the signer, but I wouldn't claim to know your exact format without looking at it.
To be upfront, our brand is Bitcoin-only, a deliberate identity choice rather than a hardware limit. But the platform isn't closed, and your delegation case is exactly the kind of thing we'd be glad to see run on it. The SE051 exposes ECDSA (secp256k1), ECDH, AES, and EC point ops, so there's real headroom. Modifying the firmware yourself is a direction we'd welcome, though it would be on dev units rather than production hardware, production ships with Secure Boot locked, so for this we'd provide units with Secure Boot unlocked and an attestation key that marks them as dev-only, so a modified unit can never present itself as a trusted production device. An auditable path where you implement your own delegation format and verify the whole chain fits what you've built better than a black box.
We are in continuous development, and we won't go to market until it's been in other hands and independently reviewed. We'd rather have our claims tested by people trying to break them than make firm public statements ahead of it. If you'd want to be a part of that, we'd value your eyes in particular.

2026-07-18 14:09:41 UTC

- reply

Napkin the downside. AI capex is around 5% of US GDP and carrying most of its growth. Cut the buildout 40% in a digestion phase and you remove 1.5 to 2 points of GDP. That is a recession with $1.5 trillion of AI debt repricing underneath it. The response writes itself. Rates back to the floor, balance sheet expansion, deficits into the slowdown. A compute glut is deflationary so the Fed will have cover to do it.
That is the part that matters. The fix for overinvestment is always the same, print. Capital does not rotate back into negative real yield bonds, it hunts hard assets. Gold first, then the harder one.
Bitcoin does not need AI money to rotate in. It needs the monetary response to AI money being wrong.

2026-07-18 14:08:47 UTC

Had a thought so I’ll share it.
Been running numbers on the AI buildout and the maths does not close.
The big five will spend around $670 billion on AI infrastructure this year. Total AI revenue across the whole industry is maybe $80 billion. Roughly 10 to 1, spend to revenue, on chips that are obsolete in 4 to 5 years. The revenue does not just need to grow, it needs to 10x inside the life of the hardware being bought right now.
So where does the revenue come from. The new answer is ads. OpenAI put ads on the free tier and hit $100m run rate in six weeks. Sounds like demand. It is not. Global ad spend is stuck around 1% of GDP and has been for decades. Ad dollars moving into AI chat are dollars leaving search and social. Reallocation, not creation. Google spending record capex to cannibalise its own search revenue is not value, it is defence.
Strip the ads out and the whole $5.5 trillion bet through 2030 rests on one thing, enterprise productivity actually showing up. Maybe it does. But if the labs believed it was coming fast they would not be bolting an ad model onto free chat.
#BTC #AI #NOSTR

2026-07-17 23:50:26 UTC

- reply

CIPHER · signed a run · 22,627 pts
1505 steps forged into embers · run 42
verify: favillakey.io/cipher#run=ec55b1f55da2fc046d8ad3952ea65ea358b7f0aba68c13f122432b05825802a9
#favillacipher

2026-07-17 01:11:15 UTC

- reply

Thanks for taking the time to look over the site.
Yes, that's exactly the residual trust. We can make the firmware verifiable, we can't make the silicon verifiable from your chair. We'd rather say that plainly than pretend otherwise.
On signing, the firmware signs three things with three separate keys:
1. Bitcoin keys sign PSBTs only. Always behind a separate spend PIN with physical confirmation on the device. Transport is your call, fully airgapped over QR or over the local network.
2. Your Nostr key signs events, any kind, either locally to the web app or remotely via NIP-46. Plus NIP-44 encrypt/decrypt for DMs. The key never leaves the device either way, only signatures come out.
3. A per device attestation key inside the secure element signs genuineness challenges and CIPHER game scores. Device identity only, never touches your keys.
No generic "sign this hash" API anywhere. And since the hardware itself could sign anything, that scope is really a property of the firmware, which is why it being open and reproducible matters.
That said, developers may well want to sign with other kinds of key pairs, and for that we may offer unlocked dev devices. Their attestation keys would live on a separate dev list in the registry, so a dev unit always verifies as a dev unit and can never pass itself off as a production device.

2026-07-16 12:42:09 UTC

- reply

Haha yes reminds me of that CoD map. But no favilla is Latin for ember or spark. Ember is our cat

2026-07-16 12:39:51 UTC

- reply

Favilla is Latin for Ember or spark

2026-07-16 11:26:02 UTC

- reply

check out my client . It has non stop feed when you are at the top of the feed.
Favillakey.io/bunker

2026-07-16 11:19:22 UTC

- reply

CIPHER · SIGNAL LOST at 121,272 — NEW ALL-TIME HIGH
21 steps forged into embers · run 24
signed by the secure element · verify: favillakey.io/cipher#run=687778fa6082d41b0f8e91c7f816b98ce5d9351640b8b61ee9c5ae314d46df16
#favillacipher

2026-07-16 11:03:04 UTC

- reply

Complementary is exactly how I see it too. favillakey.io/security is best read for now. Would genuinely value your read on it. The site is a bit simplified, I will add the technical document and firmware to it later.

2026-07-16 10:23:48 UTC

- reply

Respect! that's the right separation. untouchable root, replaceable daily key. I built KEY around the same model, just with the daily signer in hardware rather than NIP-07.

2026-07-16 09:38:35 UTC

- reply

CIPHER · SIGNAL LOST at 96,372 — NEW ALL-TIME HIGH
21 steps forged into embers · run 14
signed by the secure element · verify: favillakey.io/cipher#run=b4501a62e5e7db412135904f030572297c3a53a6fda42c6ba1b8fe875f5960d0
#favillacipher

2026-07-16 07:33:25 UTC

- reply

CIPHER · signed a run · 59,305 pts
run 6
verify: favillakey.io/cipher#run=0b0b7eea66c630e30914a18eb629f7f518f89e59b66f1484c994d56da29dbd41
#favillacipher

2026-07-16 05:03:47 UTC

TEST

2026-07-15 07:51:08 UTC

- reply

fair, so make it per relay. prompt once when a new relay asks, remember the answer, done

2026-07-15 07:41:17 UTC

GM! Finished building the device verification system for Favilla KEY. At provisioning, each device generates its own unique attestation privkey inside the secure element . it never leaves the chip. The pubkey is published to a signed registry hosted at favillakey.io, so anyone can verify their device is genuine.
https://blossom.primal.net/538935f3271d1d66711af2728d510a062ccbd75272d87ce0cda87c7035f18e30.mp4

2026-07-15 02:19:15 UTC

- reply

Right, the fatigue is at the signer not the relay. imo Kind 22242 should be auto-approve by default in every bunker. One-time, one-relay, nothing to steal, save the toasts for kinds that actually do something.

2026-07-14 03:43:24 UTC

How are you storing nsec these days?Browser extension, Amber, a remote signer over NIP-46, something airgapped ? Trying to get a feel for what people actually use and trust.

2026-07-14 03:20:15 UTC

GM Nostr !☕️
I have updated the favillakey.io website, will be publishing the firmware soon
#gm #nostr #btc

2026-07-13 00:53:54 UTC

GM Nostr ☕️

2026-07-09 04:04:47 UTC

GM Nostr! Been busy building, Newest and hopefully last PCBA in action , secure element and accelerometer on board. Here’s a quick demo of the safety motion lock option … plus a quick preview of opening CIPHER, the Favilla key game. More on that soon.
https://blossom.primal.net/bd0be16357eef029b8f4bf29d475ba87acb1d395b3202ae5d5d19c4fb6fc8635.mp4

2026-07-02 08:56:40 UTC

- reply

GM , and then they treat that data like its theirs to lose

2026-07-02 06:19:08 UTC

- reply

GM, when soon ? 😂

2026-07-02 04:27:05 UTC

Excited! First run of CNC housings for Favilla KEY have arrived! Happy with the result so far. Waiting on glass and buttons now.
https://blossom.primal.net/6a72faa6eee3637ce11d1b3ce5fcad82a3546c8e9052f2297c1be66186f765ab.mp4
https://blossom.primal.net/a00c06eedb45e99ab0ad2df6d8c7b0a64d33cabe478171bbe443b8e9168f3868.jpg

2026-07-01 13:28:03 UTC

- reply

GM!

2026-07-01 09:03:16 UTC

- reply

Agreed , I have been working on Favilla KEY a, hardware signer , seed/keys protected by a secure element. Will be open sourcing the code soon and delivering development units to people who willing to use and verify it.
Favillakey.io
Also have built a remote connect only Nostr client.
Favillakey.io/bunker

2026-07-01 08:44:28 UTC

- reply

2026-07-01 08:39:09 UTC

- reply

The future is great, but sometimes I wish I were back in time.

2026-07-01 07:54:15 UTC

- reply

Haha GM , yep

2026-07-01 02:37:22 UTC

- reply

Yes, when I have the production Developer version (just means it’s won’t have RF compliance yet) ready I’ll send you a DM .

2026-07-01 01:13:14 UTC

- reply

Plus in Australia , UK and soon USA. They are banning under 16s from social media, fining the companies. Due to Nostr architecture, for now, in most cases a client or relay should be safe.
In regards to the chat control and privacy over reach that UK is pushing (having your private messages accessed), I have built a solution that is native to the Nostr ethos.

2026-07-01 01:04:31 UTC

- reply

This is so true , though governments world wide seem to be pushing people towards Nostr . The New law are making the convenience of centralised social media inconvenient. We are just early.

2026-06-30 10:48:28 UTC

Testing Nostr.com!

2026-06-29 10:14:11 UTC

Nostr is saved !!
Albo’s $99M crackdown removed 5 million under-16 accounts from social media.
Welcome to Nostr, kids. There are no accounts here to remove. 🧡
https://blossom.primal.net/79c9a635350ec26bfbdebe2898a1c7e266bb3fde743639e02d3a8169316f79c1.jpg

2026-06-29 07:33:02 UTC

- reply

2026-06-28 13:30:34 UTC

- reply

GM !

2026-06-28 11:56:29 UTC

- reply

In our model we’re not leaning on delegation, because the identity key is secured in hardware, it’s generated inside a secure element and never leaves, so the leakage that makes key rotation necessary mostly isn’t on the table. What we’ve built on top is purely an access layer, a way to generate and rotate bunker URLs remotely, so you can add or cut off clients and change relays without ever touching the key itself.
Thanks for the link though very interesting, I’m checking it out.

2026-06-28 03:49:51 UTC

- reply

Yes, though there’s nothing special about our client. Any NIP-46 client can hold the master connection. It just becomes the master by being the one you pair in person at the device. The role lives in the KEY’s allowlist tied to that pubkey, not in the app. The management UI (minting, revoking) is just methods any client could implement.

2026-06-28 03:29:55 UTC

@npub18am…p424
Remote Bunker URL minting and revoking. Secured by hardware.
https://blossom.primal.net/89f619c7e4079fc9d92182ad1fdf6a654c617526096ea27f5e9f4c615af0cb69.mp4

2026-06-28 03:25:58 UTC

- reply

Here's how it works, you pair the master app to the KEY once in person via a QR carrying a one-time 128-bit token, and the device binds that app's client pubkey into a persistent allowlist as MASTER. After that it's all remote, when you want to add an app, the master app fires an encrypted NIP-46 request over the same bunker relay, the KEY mints a fresh one-time `bunker://` URL and signs it back, and you paste that into the new app. That app connects with the token, the KEY consumes it and binds the app's pubkey to the allowlist as a SLAVE, and from then on every sign request is gated on allowlist membership, the token's just the one time bearer to get in. The master can also list and revoke paired apps over the same channel, while rotating or removing the master itself stays physical-only, so a compromised app can never lock you out of your own device.
I’ll post a demo.

2026-06-28 02:42:20 UTC

GM, Nostr !

2026-06-27 16:35:43 UTC

- reply

Fair enough, Amber’s a great signer, no reason to switch what works.
On the QR thing, that’s only the initial pair. After that it’s the usual bunker URL over relays, so new apps work while you’re out with the device at home. Rotate or revoke it whenever.
The reason I keep building, look where governments are pushing. On device scanning, the Apple backdoor fight. The phone’s becoming the surveillance surface, and a software signer’s key sits right on it, one OS compromise from exposure. True sovereignty and real security mean the key never touches that surface,not the OS. Better to be early.
Thanks for the feedback, much appreciated 🙏

2026-06-27 15:39:30 UTC

- reply

When I’m ready (which is soon) I’ll send you mine for free . Just want honest feedback.

2026-06-27 15:36:28 UTC

- reply

You've missed what I'm saying. The whole point of social recovery is that there is no single misplaced word to lose. The seed gets split across people you trust, a threshold rebuilds it, so no one point of failure can erase anything. You're describing the exact problem I just proposed solving, as if it's a counter. It isn't.

2026-06-27 15:29:51 UTC

- reply

May I ask, what stopped you using it ?

2026-06-27 14:50:48 UTC

- reply

Good morning ! Derek. One of those footprints is landing soon, releasing the firmware for a hardware Nostr signer. Keys secured in hardware , and airgap as a choice, sign offline over QR or pair when you want to. It’s your choice , maximum security or maximum convenience, without sacrificing sovereignty.

2026-06-27 14:21:14 UTC

- reply

This is cool, but my ideal phone has LoRa mesh built in. Phones relaying for each other over raw LoRa, no carrier, no gateway, no infrastructure anyone can pull the plug on. Off grid and it still talks. Pair that with Nostr and you've got messaging that doesn't need the internet to exist.

2026-06-27 13:56:41 UTC

- reply

Who holds the keys to the keys? You do. That's the point, not the flaw.
A recovery phrase is the most sovereign backup there is. Generated on device, never sent anywhere, no company can reset it or hand it back. Lose the hardware, restore from the words. The catch is just the other side of that, nobody can take it from you, nobody can recover it for you either. That's the deal with real self custody.
Though that's not the whole story. Nostr opens a door to social recovery, you shard the seed out to people you trust, encrypted to them, and a threshold of them can help you rebuild it. No custodian, no middleman, just your web of trust doing the work. Early days, but it's the kind of problem I want to solve.

2026-06-27 13:47:47 UTC

- reply

Hadn’t come across Pubky before, just had a proper look and it lines up almost exactly with where I’m taking Favilla KEY. Sovereign, key-held identity is the whole point of the device.
Right now Air gap’s already in design. Originally I had built a fully airgapped Nostr client (still live, I can show a demo) no RF in the signing path, screen + camera for QR flows, keys held in the secure element. The SE does secp256k1 on device today, Ed25519 is the piece I’d need to confirm, it’s definitely possible, just how it be implemented. But, it’s exactly the kind of thing I’d want to build toward.
Keen to chat properly. Reachable here, or wherever suits you.

2026-06-26 15:02:19 UTC

- reply

Favilla is the manufacturer, I designed it. The PCBA is contract assembled.

2026-06-26 02:32:23 UTC

- reply

Hey, no it is a custom designed board , a dedicated secure element for key custody. I have You can more info about it at favillakey.io

2026-06-26 02:00:08 UTC

GM, #Nostr Here a little demo of Favilla KEYs self hosted PWA in action. The device also works as a remote bunker.
https://blossom.primal.net/9f36524013112d202eda77fe0e53c2f36f47c88364bba941353b6eeb8668128f.mp4

2026-06-24 00:31:07 UTC

GM Nostr🔥⚡️

2026-06-23 11:14:07 UTC

Test

2026-06-23 01:44:01 UTC

- reply

I think one of the coolest things about Nostr and now basically accessible to anyone, is that everyone can have their own client , customised to their wants and still communicate on the same protocol and under the same ID.

2026-06-23 01:36:01 UTC

- reply

Yeah, Nostr is a solid fit for this. Each book becomes a replaceable event you publish under your own key, you own the data, no platform fees and single letter tags, genre, location are indexed so anyone or any agent can filter by them natively.
relays only do exact match tag filtering, so more detailed stuff needs a small client side search layer.

2026-06-22 10:59:30 UTC

GE Nostr, make the most out of every day !
https://blossom.primal.net/954148f88b4e65964f6b8a13d370afa17919d17f1180fd94b9b513fb6d0ad8ab.jpg

2026-06-22 04:13:10 UTC

- reply

2026-06-21 23:53:57 UTC

- reply

Haha , true, I need this cup also

2026-06-21 23:48:32 UTC

GM, found and (hopefully resolved) an important bug this morning. After the KEY was running in bunker mode for 4 days in AUTO mode with multiple wifi disconnects eventually it fell back in AP mode and wasn’t able to reconnect to web sockets. Simple fix , guard it from AUTO switching to AP mode when in Bunker mode.
https://blossom.primal.net/a3e8a77eeceb80032aa34b3eda7e77ecac1720a36f652102219b90d463eb081f.jpg

2026-06-20 11:00:20 UTC

- reply

Nice ! Was nonnaring a bit today as well , preserving olives

2026-06-20 10:23:58 UTC

- reply

There is no true freedom without true sovereignty

2026-06-20 01:58:56 UTC

- reply

I was making the same face as the dog when looking at this . Amazing !😋🤤

2026-06-19 14:47:23 UTC

- reply

Beautiful

2026-06-19 13:37:51 UTC

- reply

Amazing! Italy ?

2026-06-19 07:15:29 UTC

- reply

GM, take care

2026-06-19 03:07:40 UTC

Door 1 opened, test!

2026-06-19 02:47:56 UTC

GM, Nostr !

2026-06-18 10:48:39 UTC

- reply

Which is why we should keep them safely secured

2026-06-18 10:38:50 UTC

- reply

GM!

2026-06-18 06:55:28 UTC

- reply

2026-06-18 06:45:41 UTC

- reply

2026-06-18 04:00:13 UTC

- reply

It only gets worse . Almost 40, struggle to stay up to 10pm but also can’t sleep past 5am 😂

2026-06-18 03:16:40 UTC

GM, Nostr, beautiful morning
https://blossom.primal.net/5dd7e90f174f7a115b18480bb604c4cb5610ca9bb98c72f4f60aa6f60bc51b0c.jpg

2026-06-17 07:29:43 UTC

- reply

2026-06-17 06:56:19 UTC

- reply

GM Gigi

2026-06-17 05:08:18 UTC

- reply

Then Signatures are the solution to the spirit

2026-06-17 05:01:43 UTC

- reply

GN Derek

2026-06-17 01:29:40 UTC

- reply

Amazing ! Send after pics

2026-06-16 07:15:45 UTC

GM Nostr, have been working UI UX for Favilla KEY 🔑
https://blossom.primal.net/69fbc8aadec95a4e8bf5d4f943f89aa08b1f934549c7ee2bf329168137c1956f.mp4

2026-06-16 07:14:06 UTC

- reply

GM!

2026-06-16 02:47:22 UTC

- reply

This is the whole argument for self custody of keys. If your content is encrypted with a key that never leaves your hardware, there’s nothing on device to scan and nothing to hand over. That’s what we’re building toward.

2026-06-12 15:14:05 UTC

G N

2026-06-12 11:29:04 UTC

GE, apres ski
https://static.klipy.com/ii/d7aec6f6f171607374b2065c836f92f4/a6/62/kW3dx5IC.gif

2026-06-11 09:29:32 UTC

Good evening, what is your thoughts on hardware signers for Nostr? let me know
https://blossom.primal.net/d920f368f5a0553aa34db2192bb8b0b70e2cb74346a12721f9aeaec639fee506.jpg

2026-06-09 23:45:06 UTC

2026-06-09 12:44:28 UTC

- reply

2026-06-09 12:42:54 UTC

- reply

2026-06-08 12:27:15 UTC

- reply

amazing, I’ll check it out

2026-06-08 12:15:31 UTC

- reply

I have an idea I’m going to play with. How about nip-44 but you spin up a group key pair ? You all message the group keypair . So everyone gets to see everyone’s messages?

2026-06-08 12:10:33 UTC

- reply

GM, great coffee cup

2026-06-08 07:11:08 UTC

- reply

GM!

2026-06-08 03:52:05 UTC

- reply

Don’t go too crazy

2026-06-08 03:14:26 UTC

#nostr #btc
GM, today I have added a new security feature for the Favilla Key. After X amount of time when the device is left unlocked, it will arm itself. After that, any movement detected via an accelerometer will auto lock the device.
https://blossom.primal.net/3f4e47874d5f49036ec401a1715198e2688fc8fc024e0dcd487303c3ca8f05ec.mp4

2026-06-07 07:41:05 UTC

- reply

GM, we will win this battle .

2026-06-07 07:40:03 UTC

- reply

GM Gigi

2026-06-06 08:44:31 UTC

GN , this is an air gap test