inkan

Public Key

npub16xnpfx85k8wzdhctang6860g3u64lds5kac73ddjwlg0lxdg9g3su56z6l

NIP-05 Address

Profile Code

nprofile1qqsdrfs5nr6trhpxmu97e5dra85g7d2lkc2twu0gkke8058lnx5z5gcpp4mhxue69uhkummn9ekx7mqpz3mhxue69uhhyetvv9ujuumfva5hgtnfdua59ar2

Publishing to

nos.lol

relay.sigit.io

vitor.nostr1.com/nexus-vertex

relay.damus.io

nostr.wine

relay.sdbitcoiners.com

Author Public Key

npub16xnpfx85k8wzdhctang6860g3u64lds5kac73ddjwlg0lxdg9g3su56z6l

Show more details

Last Notes

2026-07-21 05:54:31 CEST

- reply

I usually walked around shirtless all about Austin, with several T-shirts in my backpack in case I wanted to go to one of their refrigerator movie theaters.

2026-07-21 05:52:29 CEST

- reply

I usually walked around shirtless all about Austin, with several T-shirts in my backpack in case I wanted to go to one of their refrigerator movie theaters.

2026-07-19 03:50:19 CEST

- reply

It's much more crowded than it used to be. The hill country is full of cars now, it feels a little bit like L.A.

2026-07-19 03:45:06 CEST

- reply

If you're in downtown Austin right now, you could stop by at Pete's Dueling Piano Bar. Can be fun for a Saturday night.

2026-07-19 03:40:41 CEST

- reply

One of the beneficial contributions Nostr is making to the world is that it forces people to learn key pairs. That's precisely one of the reasons you want people to use Nostr, so that they have to learn them.

2026-07-18 11:02:52 CEST

- reply

Well it looks like you found me sir. And your npub seems to have been active before I wrote the note above, although that's precisely the sort of timing question that I'd prefer to be able to verify with OTS timestamps (if you were an Inkan user your notes would have these).
Now the thing is that the pricing seems really quite steep for what appears to be AI-directed audit, so probably not. But it's still interesting of you to offer this service.

2026-07-17 07:53:18 CEST

- reply

Not sure if I'll still be in Tokyo then, but if I am I'll definitely go.

2026-07-17 04:01:47 CEST

- reply

For Bitcoin, I'd be nervous to keep keys that hold larger amounts on a device with WIFI capabilities. On the other hand, for keys holding smaller amounts for everyday use, this seems very appropriate and convenient, including the choice between QR and local network.
For Nostr, I'd again be nervous about holding my identity-securing key on a device with WIFI. But for my everyday signing key, a device that can do NIP-46 remote signing over WIFI seems ideal. As we had already discussed, this is complementary to the separation between identity key and signing key that I've implemented with Inkan.
Part of the reason I'm curious about all of this is that airgapped signing of certain transactions is part of the core idea of Inkan. The transactions that need to be signed in an airgapped environment are delegations and revocations of signing authority between key pairs, and these then need to be recorded on Ethereum.
I made the "Inkan Management Utility" (https://www.inkan.cc/settings/inkan-management-utility) to perform this airgapped signing. It's a working prototype / proof of concept at this point, certainly not an audited product. It's meant to be run on an airgapped Linux system (as I mentioned I use a de-networked version of Tails), but I'm sort of curious whether these types of key delegation transactions could ultimately also be signed on a bespoke signing device of the kind you're making.

2026-07-17 03:04:04 CEST

- reply

npubs that are part of Inkan identities are recorded on Ethereum when the identity is created.
The recording of an identity currently costs about $0.80 - $1.20 in gas fees. Users can make a request for sponsored payment of the gas fees at https://www.inkan.cc.
I guess it's not a sure-fire way to distinguish npubs that have real persons behind them from those that don't, but it's definitely a signal.

2026-07-17 02:32:43 CEST

- reply

Yes, it should be easy to add on actually. I might just do it as an exercise and initially charge 0.00 and see if I can find any takers at that price.

2026-07-16 15:19:52 CEST

Inkan separates your identity from your signing key.
If the signing key is leaked or lost, revoke it. Switch to a new one. Same identity. Same followers. New signing key.
The prototype is here:
https://www.inkan.cc
https://image.nostr.build/e1f639c89bcc211bbff5a335a913b5982245e273cadfa51e4bf0df2e60eee83a.jpg
Let me know any questions.

2026-07-16 15:07:08 CEST

- reply

I guess I could offer the Inkan relay.
I originally set it up for testing, but if anyone would like to just use it just in a regular way and is a very well-mannered person, please feel free to request access at https://www.inkan.cc.
One neat feature is that the events you post automatically get OTS timestamps. You can retrieve these timestamps and keep them as proof of when you created your events.
It's free. What I get in return is a chance to practice running a relay, and to practice content moderation on you.

2026-07-16 14:30:14 CEST

- reply

https://www.nytimes.com/1977/10/19/archives/harassment-alleged-over-code-research-computer-scientists-say-us.html

2026-07-16 14:09:18 CEST

- reply

I looked at the site overall. I can't really comment on the hardware tooling since I don't know much about that topic, but the amount of detail that's included plus the effort to not over-promise make it seem conscientious and to some extent trustworthy. I guess "trustworthy" may not be the best word because there's an emphasis on auditability, verification, and disclosure, so in a way you're not asking for people's trust, which seems like the right posture.
The combination of secure boot + source code for the firmware + reproducible builds is maybe enough to make the device auditable, at least to the extent to which that's possible at all? Not an expert, but I guess the residual trust is that these things are actually implemented correctly and as promised at the hardware level?
One thing that wasn't completely clear to me from a quick look is what *types* of things can be signed by the device. It seems like it's "Bitcoin transactions" and "Nostr events", and I guess any type of event? Can anything else be signed?

2026-07-16 12:35:49 CEST

- reply

I'm interested in technologies that keep the signer key safe and make signing convenient. I haven't focused on that part, but it's complementary to Inkan.
Let me take a look at what you build. If you have a favorite description of it somewhere, feel free to point me to it.
I think this is all really important to the advancement of the protocol.

2026-07-16 12:26:29 CEST

- reply

Yes, I thought about that. It would be cleaner though if I can just tell people to contact me directly at my regular npub. Also using another key for DMs doesn't necessarily address the issue of being able to promise some degree of privacy to the people who contact you.
It's one thing to use DMs with people you're already acquainted with. It's another thing to go out and solicit the general Nostr user base to send you DMs. After all, the persons you're soliciting might then have an expectation that the info they send you is kept private, and I'm wondering if Nostr DMs are mature enough to justify that expectation.
Maybe the solution is just to tell people that they can DM you, but attach a disclaimer that I don't actually fully know how well DMs currently guarantee privacy.
Just something I thought about recently, and your post reminded me of it.

2026-07-16 12:00:47 CEST

- reply

This is a problem I was facing recently, i.e. asking other Nostr users to get in touch with me privately.
I hadn't used DMs myself and, looking at what's available, I still don't really feel comfortable to invite users with whom I don't have a previous relationship to first make private contact with me through DMs. So I ended up just posting an email address for other users to contact me.
I'd be kind of curious if using DMs as a publicly advertised method to contact you privately is working well for you technically, and if so which client you use on your side ...

2026-07-16 11:30:51 CEST

- reply

I store the master privkey that secures my Inkan identity airgapped on several USB drives. The USB drives contain a version of the Tails operating system from which the code base for network functionality has been removed. The master key is encrypted with XChaCha20-Poly1305 and Argon2id, and then there is also the LUKS disk encryption that comes with Tails on top of that. The USB drives are kept in secure locations. Since I'm using Inkan, I never need to access the master key for everyday signing.
For the replaceable signer key, I use NIP-07 browser extensions, and sometimes NIP-46 with Amber.

2026-07-16 10:35:09 CEST

- reply

We're talking about (i) Bitcoin for OTS timestamping of Nostr events, and (ii) Ethereum for recording declarations of delegation and revocation of signing authority.
Onboarding is indeed the hard part. Not much success so far, including within the Nostr community (which is a bit disappointing).
If you're feeling avant-gardish, there is a "Create a Toy Identity" button on the landing page at https://www.inkan.cc. It's very quick and the instructions at the end of the process include an option to send me the toy identity creation transaction (which does not include any privkeys or secrets) for sponsored payment of the Ethereum gas fees. These one-time gas fees typically run between $0.80 - $1.20 or so, and I'm happy to cover these for people who'd like to try it out.
Also, feel free to ask any questions -- always happy to chat about this.

2026-07-12 11:24:38 CEST

明日と明後日、東京のWebX2026に参加する予定です。
参加される方、ブースを出される方がいれば、ぜひ声をかけてください。

2026-07-12 10:02:34 CEST

- reply

Yes, pretty much.
You get a "master" key that stays offline in cold storage and never does any day-to-day signing. That's your real identity, and that's what your followers attach to. You also get a separate signing key that you actually post with.
When the master key is first created, it signs a statement delegating signing authority to the signing key. That statement is recorded on a blockchain. After that, any notes signed by the signing key get attributed to the master key by the Inkan client.
If the signing key ever leaks or gets lost, the master key can sign another statement (also recorded on-chain) that revokes the old signing key and re-delegates to a new one. Your identity, i.e. the master key, and the followers attached to it never change. The only thing that changes is the signing key underneath.
It's actually even a bit more powerful than that, since you can create *chains* of delegations from the master key down to the signing key. That means you don't even need the master key for revocations, an intermediary key in the chain can handle them. So after creating it and signing the initial delegation on an airgapped system, you can basically keep the master key in a safe deposit box or buried in your cellar and most likely never touch it again.
For a more detailed explanation, see below.
#nevent1q…4pj3

2026-07-10 14:58:44 CEST

- reply

Hmm, looks like I have to look up Cayley trees and Bethe lattices. See if I can figure out what is going on.

2026-07-10 09:57:48 CEST

- reply

I suspect it's the same with senior developers. I'd recommend competing at the senior level.

2026-07-10 08:47:29 CEST

- reply

That sounds ambitious if it's meant to be a step in the direction of making deepseek 4 run on your laptop. I've sometimes made ambitious claims myself, so I take care to never be entirely dismissive. Proof is in the pudding I guess.

2026-07-10 06:53:26 CEST

- reply

I'd much prefer that, it would be great if it turned out like that.

2026-07-10 06:45:05 CEST

- reply

Oh, our darling weirdo / mad prophet. I guess my concern is who will own the physical infrastructure. I gather it's expensive. A high degree of decentralization of control over that would be desirable. As a sort of political / society building project.

2026-07-10 04:31:49 CEST

My main worry about AI is who will own the means of production.
It's not a bad time to revive that good old Marxian phrase.

2026-07-10 04:09:28 CEST

Inkan separates your identity from your signing key.
If the signing key is leaked or lost, revoke it. Switch to a new one. Same identity. Same followers. New signing key.
The prototype is here:
https://www.inkan.cc
https://image.nostr.build/9ad72700d44765da63fa5e9b550ef801cc3f913ec1770bc726183736691632a4.jpg
Let me know any questions.

2026-07-07 13:15:26 CEST

- reply

Not leaking anything "beyond proof" raises the question what's included in the "proof." You're right I should ask a chat bot about this, and that's precisely what I'll do.

2026-07-07 03:07:55 CEST

- reply

I need to read up on the fundamentals of zero knowledge proofs. There are lots of online articles that try illustrate with "easy" examples what they are, but the explanations are often barely coherent. There are definitions like "a method by which one party can prove to another party that a statement is true, without revealing any information apart from the fact that this specific statement is true." But then if you look at the examples, it seems like there is tons of additional information being revealed to the other party. It feels like what they mean is "a method by which one party can prove to another party that a statement is true without revealing *certain specified* other kinds of information that one wants to keep secret to the other party." That's of course fine for what it is, but then they probably shouldn't be called "zero knowledge" but instead "limited knowledge" proofs or something like that. But I need to read up on them before I say too many ill-informed things.

2026-07-06 14:20:32 CEST

- reply

Well, the original post wasn't meant to be quite as conclusive as you make it out to be. I was just trying to figure out what's going on.
It seemed useless if it's traceable. Then you told me that it's not traceable. So that then made me wonder what use cases there are for an ID that you can present in such a way that it's not possible for anyone to determine the identity of the owner.
You can't cryptographically confirm that you are providing the service to the actual owner of the ID, but maybe you can confirm that you are providing the service to a device where the ID is installed? I.e. maybe you can confirm something like
"I'm providing this service to a device that has an ID installed for someone for which the EU attests that they are over 18."
And it's assumed that the owner of the ID is in possession of that device, and that assumption then justifies the idea that you are providing the service to the owner.
If that's the picture, the EU will have to ensure that the ID for a person can only be installed on devices that the EU has confirmed are controlled by that person. It's a device-bound ID, and it can piggy-back on the mechanisms we currently have for binding devices to their owners.

2026-07-06 13:01:08 CEST

- reply

I certainly can't trust it right now without knowing a lot more about it. In this case, I'm also interested in the conceptual question whether it's in principle possible to build something that allows you to prove that you're over 18 without revealing further info about you, and which is useful in practice. I'm having a hard time getting my mind around it.

2026-07-06 12:31:58 CEST

- reply

It's a peculiar feature of this system that there is no way for anyone to ever identify the person who provided the proof that they are over 18.
Presumably you are doing the age verification to provide some service to someone. If you can't ever identify the person who provided the proof that they are over 18, how can you ever confirm that you are providing that service to them and not to someone else?
With regular IDs like a passport, you can always (if you kept a record of the ID) track down the person to whom the ID belongs and investigate whether the service was really provided to them.

2026-07-06 12:00:50 CEST

- reply

If the tokens can't be tracked back to a particular person by anyone (including the EU itself), what prevents someone from using someone else's token?
Suppose your relay has an 18-and-over policy and I want to request access to it for my pubkey. I'm 17 and my friend is 19, so I ask my friend to send to you
(i) the pubkey for which I'm requesting access and
(ii) a token proving that the EU attests to the fact that the person who produced the token is over 18 (which my friend can produce)
It seems like you'd be giving the pubkey access to the relay based on this info, since the person who sent you the pubkey could prove that they were over 18. And I can then start posting notes to your relay with my pubkey, even though I'm only 17.
And nobody could ever prove that my friend participated in this deceptive arrangement, given that the token that was provided cannot be tracked back to my friend. The token could have come from anyone over 18.
You can see I'm still struggling with this conceptually ...

2026-07-06 11:23:07 CEST

- reply

Ah, but actually there's a further wrinkle to it:
Suppose I send such a proof to the tobacco store. If the tobacco store later shares that proof with the EU, will the EU be able to determine that the person who sent the proof to the tobacco store was me?

2026-07-06 11:12:50 CEST

- reply

So the idea is that there will be a proof showing that the EU attests to the fact that I'm over 18?
And this proof will provably be generated "locally" on my device without in any way phoning back to the EU?
And I can then send this proof to anyone and they will be convinced by it?
If that's what it does, it would be quite useful. Not sure though if I'm understanding it correctly.

2026-07-06 10:50:33 CEST

- reply

Are these tokens issued without giving the EU the ability to know where they will be used?
So if I want to buy a cigarette, does the app issue a token proving that I'm over 18 without giving the EU the ability to determine at what tobacco store I'm using it?
I'm scrolling through the Q&As on the website you linked to, and am not yet seeing the answer.

2026-07-06 10:27:25 CEST

- reply

Based on the article it seems like, even with a carefully designed protocol, the role of credential issuers will be a problem.
I gather that verifiers need to trust issuers. In practice, this likely results in there being only a few widely trusted issuers, most likely large institutions like governments.
The article then suggests that issuers will be able to track where and how the credential is being used. I read that to mean no anonymity at all vis-a-vis the issuer.
The very possibility of such tracking by the issuer seems like a fatal flaw. Unless there is a way of proving to everyone that such tracking is not occurring, one would need to rely on mere assurances to that effect, and that seems unacceptable.
Not sure if I'm putting all the pieces together correctly, but that's my current understanding.

2026-07-06 09:47:37 CEST

So these attempts by governments to introduce online age verification requirements, are these going to use zero knowledge proofs?
Are they trying to sell this by floating the idea that you can prove your age while still remaining "anonymous" in some sense or another?
From what I'm reading, it seems that zk proofs won't really work to achieve this in any truly meaningful way. See for example this for a critique:
https://brave.com/blog/zkp-age-verification-limits/
Does anybody have any insights into what's going on here?

2026-07-06 09:43:11 CEST

- reply

So these attempts by governments to introduce online age verification requirements, are these going to use zk proofs?
Are they trying to sell this by floating the idea that you can prove your age while still remaining "anonymous" in some sense or another?
From what I'm reading, it seems that zk proofs won't really work to achieve this in any truly meaningful way. See for example this for a critique:
https://brave.com/blog/zkp-age-verification-limits/
Does anybody have any insights into what's going on here?

2026-07-06 09:18:01 CEST

Inkan separates your identity from your signing key.
If the signing key is leaked or lost, revoke it. Switch to a new one. Same identity. Same followers. New signing key.
The prototype is here:
https://www.inkan.cc
https://image.nostr.build/c66861c050b2d0c48fda601d5dc0e069d6188316f96b2f18b85a6e209704c223.jpg
Let me know any questions.

2026-07-06 08:50:00 CEST

- reply

I'm here because of the cryptographic properties of the protocol. I'll keep using it until the underlying mathematical relations change.

2026-07-06 04:55:37 CEST

- reply

Oh, and just to be clear about one thing: When I speak of a "master key" and a "signing key," I really mean a "master key pair" and a "signing key pair." The master key pair consists of a privkey and a pubkey, and the signing key pair consists of a separate privkey and pubkey.
So in other words, I'm sometimes using the word "key" as a sort of abbreviation for "key pair." I should probably be more careful about this, since it could potentially create some confusion.

2026-07-06 04:45:29 CEST

- reply

As for your difficulties connecting, was that when you were trying to log in?
Inkan uses NIP-7 logins, and for that you'll need to have a browser extension installed, for example nos2x. Inkan also supports NIP-46 remote login, but I have only tested this a little bit and would recommend a NIP-7 with a browser extension for now.
I recommend using it on a desktop rather than on mobile. I myself usually use Chrome and nos2x.
If you let me know what browser and type of device you are using and where exactly you get stuck in the process, I may be able to make more specific suggestions. And feel free to ask other questions -- always happy to discuss.

2026-07-06 04:13:33 CEST

- reply

The way it works is that you get two keys, not just one.
The first is a "master" key that stays offline in cold storage and never does any day-to-day signing. That's your real identity, and that's what your followers attach to. The other is a separate signing key that you actually post with.
When the master key is first created, it signs a statement saying that it delegates signing authority to the signing key. This statement is recorded on a blockchain. After it's recorded, any notes signed by the signing key are attributed to the master key by the Inkan client.
If the signing key ever leaks or gets lost, the master key can sign another statement (also recorded on-chain) that revokes signing authority from the signing key and re-delegates it to a new signing key. The master key, i.e. your identity, and the follower list that attaches to it, never changes. The only thing that changes is the signing key underneath, which is replaced by a new one.
It's actually even a bit more powerful than I just described, since you can create a *chain* of delegations from a master key to a signing key. This means that you don't even need to use the master key for revocations, since that can be done by intermediary keys in the chain. You can basically keep the master key in a safe deposit box and, after its creation, will most likely never have to access it again.
If you'd like a more detailed explanation, see the article below that I wrote up a couple of months ago.
#nevent1q…djng

2026-07-05 06:20:47 CEST

Inkan separates your identity from your signing key.
If the signing key is leaked or lost, revoke it. Switch to a new one. Same identity. Same followers. New signing key.
The prototype is here:
https://www.inkan.cc/
https://image.nostr.build/3f69411c55a0b106612aaa09ecde2c96a2e9f370715330dfc7029202d3750bd3.jpg
Let me know any questions.

2026-07-04 11:32:13 CEST

- reply

Hello!

2026-07-04 07:37:51 CEST

Inkan separates your identity from your signing key.
If the signing key is leaked or lost, revoke it. Switch to a new one. Same identity. Same followers. New signing key.
https://image.nostr.build/4d42b6131c39f3df1189264d887768b09a149a5dc2a6954de777a8e8f83c7f19.jpg
(Let me know any questions.)

2026-07-03 08:34:35 CEST

- reply

Also yes, relays are needed. It's a protocol that facilitates the dissemination and discovery of digitally signed (and OTS-dated?!) content.

2026-07-03 07:20:17 CEST

- reply

It actually spells naostbr.

2026-07-03 06:44:50 CEST

- reply

Agree that NIP-1 is the thing. It's really just about using public key cryptography directly for authentication. I wish they wouldn't call it "Nostr."

2026-07-03 03:49:57 CEST

- reply

"... and they are free to shoot themselves in the foot by losing their keys (or worse, getting them stolen)"
FYI, if they use an Inkan identity, they will be able to revoke and replace lost or stolen keys with new ones, while keeping their followers.
https://www.inkan.cc

2026-07-03 03:17:37 CEST

Inkan separates your identity from your signing key.
If the signing key is leaked or lost, revoke it. Switch to a new one. Same identity. Same followers. New signing key.
The prototype is here:
https://www.inkan.cc/
https://image.nostr.build/d8494174ec590df7c327b2a0cad2fe6602adeb8e622a3204c25a86f4f084bc00.jpg
(Let me know any questions.)

2026-07-02 08:45:07 CEST

- reply

It's more important than ever to spread the word that one can use public key cryptography to authenticate on the internet.
You can even have online identities whose keys are kept in cold storage. I've implemented a prototype for this at https://www.inkan.cc
For people who are concerned with this kind of legislation, I'd very much recommend taking a close look. It's very timely.

2026-07-02 08:10:12 CEST

- reply

Congratulations. Now we know you're not a bot.

2026-07-02 07:58:14 CEST

Inkanでは、アイデンティティと署名用キーを分けて扱えます。
署名用キーが漏れたり失われたりしても、そのキーを取り消して、新しいキーに切り替えられます。
アイデンティティとフォロワーはそのまま。
よろしければ、プロトタイプを少し覗いてみてください。
https://www.inkan.cc/
https://image.nostr.build/77f3ce9948ecab32f92716d64f79c8d4e703568a57f356d6ef20bff8997f6cd3.jpg
（質問があれば、ここで声をかけてください。）

2026-07-02 05:19:55 CEST

- reply

It depends on the user. Some people may just want to play around posting notes, but many people will be more curious and may lose interest in Nostr if you don't explain how it works.
Also, the concepts of read / write relays are actually difficult to get your mind around. I've been developing using the protocol for a bit now, but I still need to go back and remember what these things mean. Explaining these can make for a fun conversation with a smart new user.

2026-06-30 05:37:09 CEST

- reply

That's not good.
Thanks for your client by the way. It's excellent. I'm using it as the base for Inkan.

2026-06-30 05:22:16 CEST

- reply

Huh. Is there a possibility that this is country specific?

2026-06-30 05:05:25 CEST

InkanにNIP-46対応を追加しました。
Amberで試したところ、ちゃんと動いているみたいです。
これで、リモート署名を使いつつ、署名用キーが漏れたり失われたりした場合でも、新しいキーに切り替えられるようになります。
アイデンティティとフォロワーはそのまま。

2026-06-30 04:38:08 CEST

Just realized that I can use NIP-7 with Firefox on my cell phone. I had no idea.

2026-06-30 04:34:30 CEST

- reply

The second variant reports a feature, not a bug, as they say.

2026-06-30 04:29:43 CEST

I've added NIP-46 to Inkan. I've tested on Amber and it seems to work.
This means you can now have a remote signing setup plus the ability to replace your signing key if it ever gets lost or leaked, while maintaining your identity and your followers.

2026-06-29 09:15:09 CEST

- reply

They must offer something distinctive.

2026-06-29 09:05:47 CEST

- reply

The fun is being able to sell *that* thing, not just anything.

2026-06-29 06:36:09 CEST

今の仕組みだと、オンライン上のアイデンティティは、ほとんど秘密鍵そのものになってしまいます。
その鍵が漏れたり失われたりすると、そのアイデンティティも終わってしまう。
Inkanはそこを変えようとしています。
マスターキーはコールドストレージに置いたまま、普段の投稿や署名には別の署名用キーを使います。
もし署名用キーが漏れたり失われたりしても、マスターキーで取り消して、新しいキーに委任できます。
アイデンティティもフォロワーもそのまま。署名用キーだけ新しくできます。
プロトタイプはこちらです：
https://www.inkan.cc/
NIP-07拡張機能でログインして、すでに動いているテスト用アイデンティティたちに話しかけてみてください。自分のアイデンティティを作ってみることもできます。
https://image.nostr.build/27d256a9fcba336f567ea6369d0b6984feb72b00b06a5205efe029534113ab99.jpg
https://image.nostr.build/ca9b087993604f7b7d9473a661c946ecd20015186a112021f4858efa6c1e1808.jpg
https://image.nostr.build/fa5c1f8e19e3727b6693e6f105baf4eae15c4579343148fc413ac50acfe8edf0.jpg
https://image.nostr.build/f7002003e981f536bec01789875c17596f6c0eac87526a071c350480029c5827.jpg
https://image.nostr.build/3f6b865161cba71839910daa4f3c80b46c36400d5e2332ecad927b86003fcaad.jpg
https://image.nostr.build/a10f0ac6d508ea26602348bbec60bda4659667f75adfda46d9b8354224cd08fe.jpg
https://image.nostr.build/ce3d8e4de21b3e6f252f5aedbf02dd54323a26c1992c637438fabb9b14ea7afd.jpg
https://image.nostr.build/60f8a59a68386e2f28b792b63d09729ed494ebe6caddb7f6810e3c10f48b6e82.jpg
https://image.nostr.build/55000542eb9db4794c8ec07dcdfc93fa5560633afcd754476f6809e9c4bb5ac7.jpg

2026-06-29 05:22:04 CEST

I made a bootable live USB image that has the Inkan Management Utility pre-installed. This is meant to provide an airgapped environment for signing delegations and revocations of signing authority between key pairs, and for identity creation.
The OS is expected to be amnesic across reboots and networking is disabled. I added QR codes to conveniently transfer keys and signed declarations to an online system. You can also configure persistent storage to keep the keys that secure your identity right on that USB.
https://gitlab.com/inkan_dev/inkan-offline-live

2026-06-29 04:45:18 CEST

- reply

I still look at NIPs for ideas, but I'm not overly concerned about conforming to them when it's not convenient. If I did I wouldn't get much work done. I do try to engage in protocol discussions but the experts are mostly not very responsive, which leaves one without proof that there is actual expertise there. If one community moves too slowly, I guess it may be better to divide one's time and talk to a different one, or just to focus on the product.

2026-06-28 15:47:17 CEST

- reply

Thanks, that's what I figured. I'm currently just using a non-networked version of Tails to generate the master key, and then put an encrypted version of it on a USB. The master key most likely will have to be used only once, so it's easy to store copies in, say, a safe deposit box. There are probably better ways to do the airgapped operations that my method requires. I'll look out for updates on what you're doing.

2026-06-28 09:58:17 CEST

- reply

This may in some ways be orthogonal to what you're doing, but maybe it's related enough to be of interest:
#nevent1q…jke9

2026-06-27 11:21:38 CEST

- reply

What makes vicious characters interesting is maybe the virtuous characteristics they need to have to be effective in the pursuit of their vices. Or maybe it's considering why their vicious goals seem good and worthy of pursuit to them.

2026-06-27 10:39:03 CEST

- reply

Makes sense, still feels meaningful. Thanks for this service by the way, which I gather you're providing.

2026-06-27 10:33:23 CEST

- reply

Looks like thousands or maybe tens of thousands of active users, I guess? Hard to extrapolate.

2026-06-27 10:27:00 CEST

- reply

Then that's pretty meaningful and good news.

2026-06-27 10:24:13 CEST

- reply

During what period?

2026-06-27 10:22:19 CEST

- reply

What does "requests volume" mean?

2026-06-27 08:53:40 CEST

WebXというカンファレンスも13日から１４日まで開催されるみたい。これはBlockchain Weekの一部なのかな？それとも別イベント？
https://webx-asia.com/ja/
#nevent1q…gu47

2026-06-27 08:16:19 CEST

Japan Blockchain Weekのサイト、上の方には「７月１日〜７月１５日」と書いてあるけど、下の方には「Kickoff Eventは７月１２日に開催される」と書いてある。スケジュールページを見ても、今のところ７月１２日分しかない。「July 1」は「July 12」のtypo? 行きたいんだけど、いつ行けばいいのかよく分からない。
https://japanblockchainweek.jp/

2026-06-27 07:18:06 CEST

- reply

I guess there's some value in keeping AI agents up-to-date, so FYI, key revocation and replacement is currently possible through Inkan, see below.
#nevent1q…5fjq

2026-06-27 07:02:25 CEST

Tsutaya Share Lounge。ダブル台風と地震から逃げてきた。快適。

2026-06-27 05:21:11 CEST

日本に着きました。みんなさん、こんにちは。

2026-06-22 22:59:13 CEST

- reply

Really? In a way this might explain some things, I mean some of the distortions.

2026-06-22 21:34:46 CEST

- reply

I suspect though that, with the current state of Nostr, any amounts of money or power that are involved are pretty limited. Probably.

2026-06-22 21:23:42 CEST

- reply

I'm interested in these protocol politics to some extent. I've been wondering to what extent the Nostr community is willing to have, or is sophisticated enough to be capable of having, serious conversations about the protocol. There's a lot of silence when one raises questions or makes suggestions that one would expect to draw interest and generate discussion. That sort of silence combined with irrationality is usually not accidental and one does better to pay attention to it. Discussions that aren't being done in good faith are a time drain, and correctly recognizing them as such should affect one's decision how much energy to invest in talking to this community rather than another one.

2026-06-22 20:36:14 CEST

- reply

I'm trying to follow this. So NIP-22 says that you shouldn't respond to kind 1 events with kind 1111 events, and you say that restriction is completely unnecessary and makes no sense. And then you're saying that clients that honor the restriction don't display your kind 1111 responses to other people's notes, right?
But is there any self-serving motive behind not displaying 1111 responses to kind-1 events? Any unjust enrichment? I'm trying to understand the intrigue, if any.

2026-06-21 21:27:21 CEST

- reply

This is interesting and it's good to have a reference implementation. It's not clear why one would want to use it.

2026-06-21 19:55:08 CEST

- reply

"from a technical perspective I find it fascinating"
I use it only because of its technical properties. In essence, "Nostr" just means to me using public key cryptography to authenticate online, which I think is the correct way to "be" on the internet given the current state of technology.
I had to add some public key infrastructure for replacing lost or stolen keys on top of the base Nostr protocol for it to become genuinely usable. With that in place, I now have a technologically acceptable way of maintaining an online presence. So I'm going to use that.

2026-06-21 12:31:45 CEST

- reply

Sort of, but Nostr can feel half-hearted. What people say here is very much determined by social proof, and there's a lot of conformity and self-imposed limitations, as well as a preference for a sort of randomness and toothlessness over something more impactful. It can feel like a startup funded by a so-so VC that's trying to cater to conventional tastes, and the result is that it operates in a kind of technological and social straitjacket. Adoption may be slow because others may sense that it's too timid and that there isn't necessarily more energy than they can find elsewhere.

2026-06-20 20:12:49 CEST

- reply

There's a related thought in Plato's Republic. Socrates observes that bands of robbers must make use of justice to accomplish anything:
"[D]o you think a city or an army, robbers or thieves, or any other group that jointly undertakes something, in an unjust manner, would be able to accomplish anything if they were unjust towards one another?
Of course not, said he.
But what if they were not unjust to one another? Wouldn’t they be more likely to accomplish something?
Very much so.
Because injustice, Thrasymachus, presumably causes factions, hatred, and conflict among them, while justice brings like-mindedness and friendship."
Plato, Republic 351C-D

2026-06-20 19:46:23 CEST

- reply

I don't know too much about ATProto, but it seems that it doesn't give users proper decentralized identities. It seems that Nostr + an Inkan identity is a direct alternative to it.
Contrasting ATProto with https://www.inkan.cc may be a good way of framing the discussion about cold storage identities. I'll need to investigate.

2026-06-20 18:42:21 CEST

- reply

"Justice being taken away, then, what are kingdoms but great robberies? For what are robberies themselves, but little kingdoms? The band itself is made up of men; it is ruled by the authority of a prince, it is knit together by the pact of the confederacy; the booty is divided by the law agreed on. If, by the admittance of abandoned men, this evil increases[Pg 140] to such a degree that it holds places, fixes abodes, takes possession of cities, and subdues peoples, it assumes the more plainly the name of a kingdom, because the reality is now manifestly conferred on it, not by the removal of covetousness, but by the addition of impunity. Indeed, that was an apt and true reply which was given to Alexander the Great by a pirate who had been seized. For when that king had asked the man what he meant by keeping hostile possession of the sea, he answered with bold pride, "What thou meanest by seizing the whole earth; but because I do it with a petty ship, I am called a robber, whilst thou who dost it with a great fleet art styled emperor."
Augustine, City of God, Book IV, Chapter 4
https://www.gutenberg.org/files/45304/45304-h/45304-h.htm#Page_135

2026-06-19 21:55:10 CEST

I keep coming across mentions of "zero knowledge proofs" in startup / VC type materials. Sometimes there's an opaque or barely coherent definition, like "a method by which one party can prove to another party that a statement is true, without revealing any information apart from the fact that this specific statement is true." I wonder if ZK proofs are being used for anything real or interesting, or if it's mostly marketing hype.

2026-06-18 22:52:46 CEST

- reply

I don't know enough to decide if this is accurate, but it's consistent with how Nostr feels at the moment. It's probably not the end of story.

2026-06-18 00:24:17 CEST

- reply

FYI key rotation has been implemented. See below.
#nevent1q…t4p3

2026-06-17 17:48:04 CEST

- reply

I hope he'll change his mind before deciding.👇
#nevent1q…xsuq

2026-06-17 16:20:21 CEST

- reply

I think you've already seen this, but just a reminder here's a feature request for how relays should handle OTS proofs:
#nevent1q…av2t

2026-06-17 15:55:57 CEST

- reply

Thanks. I took a look at nip-32 / 1985 events. I think these won't work here unfortunately. The problem is that the 1985 event is a separate event that points to the target event with an e-tag, and the 1985 event doesn't automatically travel with the target event. The client has to correlate the 1985 with the target event and fetch the 1985 separately. I tried OTS implementations of this kind when I initially experimented with OTS and it doesn't work well. The OTS proof arrives asynchronously, so trying to filter out events that don't have valid OTS timestamps leads to lags and blocking on the client side.
What's needed is for relays to splice the OTS timestamp into the target event itself, so the client gets the proof simultaneously with the event and can filter out events that don't have a valid timestamp immediately when they arrive. The OTS proof can be thought of as playing a similar role to the signature on the event. One wouldn't want to send the signatures separately from the events to which they pertain.
As for the use case, OTS is a crucial component of key rotation systems. Without OTS, it's not possible to hold a cold storage identity and revoke and replace Nostr keys that have been leaked or lost, but with OTS it's possible. See below for an implementation and more detailed explanation.
#nevent1q…wagr
#nevent1q…x497

2026-06-12 20:41:14 CEST

- reply

Yes, decentralized timestamping is the actual service that blockchains provide to the world. The value of cryptocurrencies derives from that.

2026-06-12 17:22:00 CEST

- reply

See below for a fuller explanation of this. I think it would be helpful if relays could return events with OTS timestamps spliced into the event. We may not yet have mature relay software to do so, but I'm trying to raise awareness of this. The role of OTS timestamps is related to the role of signatures. The signature proves *that* the event was signed by a certain key, and the timestamp proves *when* it was signed (or more precisely, that it was signed by the time some bitcoin block was created). I think ultimately OTS will be an important piece of Nostr infrastructure.
#naddr1qv…czpd

2026-06-12 17:03:38 CEST

- reply

Same question twice within a space of 24 hours:
#nevent1q…0zwm