inkan

I'm not sure what exactly you mean by "fork" or "join," but inkan's declarations do "join" in the sense that the delegation state at any given time is a function of the total set of past declarations.
But the question whether declarations "fork" or "join" seems in any event orthogonal to the question whether inkan needs consensus. Inkan needs consensus on the relative order of nostr events and revocations. If Bitcoin uses consensus for validating the DAG, that's fine. Inkan just uses the types of consensus it actually needs.
I'm not sure about the "humans" point. Inkan can absolutely issue identities to agents. Neither Bitcoin nor inkan can check that its users are humans.
Regarding the "notary," inkan uses a notary, namely OTS, for the timestamping of nostr events. But a notary is not sufficient for inkan, since a notary can't prove *absence* (e.g "no revocation existed before time T ...").
As for the leak's and revocation's being inherently race that inkan can't eliminate, that's of course true. But a stolen signer can damage only the window between key compromise and revocation. You can also take preventative steps by periodically rotating your signing key preemptively.

2026-09-18 06:08:08 GMT

- reply

"Y can never spend anything that X signs"
I think that's not quite correct. For example, on Bitcoin, spending something signed by another key is the *normal* case, every spend uses an output that someone else's transaction created.
"We can just trust X's 'created_at' in the revocation event"
If X's self-declared created_at is treated as authoritative, then X can sign a revocation today that's dated last year and retroactively disown a year of events that counterparties relied on. Also, even assuming that X is always honest, the issue about the *discoverability* of X's revocation remains. A party who never *becomes aware* of X's revocation will just keep attributing events signed by Y to X forever.
More generally, revocation is not a private matter between X and someone who has a personal opinion about X's character. The idea is that *every client*, with no trust in anyone, computes the same timeline of delegations and revocations.
"utxo" in this context refers to a "delegation of signing authority from X to Y." Key X can "spend / burn" that output by revoking the delegation, and key Y can "spend / draw on" that output by signing events that are then attributed to X. Order is absolutely crucial because, once a delegation from X to Y has been burned, Y can then no longer draw on that delegation to cause the events signed by Y to be attributed to X.

2026-09-18 03:48:55 GMT

- reply

"when there is no utxo ... in the data"
But the data that inkan is trying to handle *does* have "utxo." There are two competing artifacts that each is cryptographically valid by itself:
1. A revocation declaration R signed by pubkey X saying "X revokes signing authority from Y"
2. A nostr event E signed by pubkey Y
The "unspent transaction output" is the output of the the delegation transaction that occurred earlier, i.e.:
utxo = the delegation of signing authority from X to Y
Now the revocation transaction R invalidates that delegation, i.e. it consumes / burns the utxo.
At the same time, the transaction consisting of the signing by Y of event E tries to draw on that utxo, i.e. it tries to draw on the delegation relationship to cause E to be attributed to X.
So both the revocation and the signing of the nostr event are trying to "spend" the same utxo, one by burning it and the other by drawing on it.
But this type of utxo can only be "drawn on" when it hasn't yet been "burned." So we need to know in which order these transactions occurred.
Classic double-spend.

2026-09-18 01:25:57 GMT

- reply

I'm not really familiar with these, but are these consensus mechanisms actually designed to prevent cheating / deal with dishonest participants? And when you talk about "partition", do you mean that relays may split into two groups, one that shows the revocation and another that doesn't? In that case, it seems that "partition resistance" would be extremely important. That's precisely the problem, i.e. that an adversary may build a "partition" that withholds all-important information about a key revocation.

2026-09-18 00:32:39 GMT

- reply

[By the way, my comment above should have said "Recording a 5-key inkan identity on Ethereum costs say $0.25 in gas fees, about $0.05 per key." That way the rest of the comment actually makes sense.]

2026-09-18 00:29:24 GMT

- reply

I wonder how a non-blockchain consensus mechanism would work. Would there be a penalty for cheating?

2026-09-17 14:36:54 GMT

- reply

"store the revocations with a guarantee of availability"
That requires a blockchain, though? The agreement on the timestamp is kind of what a blockchain *is*.

2026-09-17 13:33:21 GMT

- reply

That could be, I just don't have the data to compare the economics.
By the way, inkan comes with built-in spam prevention.
Recording a 5-key inkan identity on Ethereum costs say $0.50 in gas fees, about $0.10 per key.
That expense by itself provides a decent signal, maybe comparable to NIP-5.
But it's actually better than that. Say you have a funded spammer who records 500 Inkan identities with 5 keys each, 2500 keys in total, for $125.
That creates a patterns that's public and likely detectable on-chain, for example by tracing gas payments, timing patterns, etc. It's cheap to observe these patterns and flag suspicious pubkeys.
Spammers can try to cover their traces, but that's an additional expense and it's risky. If the pattern is detected, it's not just one of their pubkeys that gets flagged but it's the entire 2500 key blob. So they don't just lose $0.05 per key, but lose their entire $125 investment.
This defense covers LLM spammers that produce content that's hard / impossible to distinguish from humans, at least when someone tries to do it at scale. It's an origin-based defense.

2026-09-17 12:41:42 GMT

- reply

A funded attacker will not be working with a typical 4 core processor but will be renting a larger outfit, so there will be a lot more than 15,000 events.
If the purpose is to protect relays from having to store gazillions of spam events, I guess VDF works to some extent. But PoW also works to some extent. You'd have to compare what can be produced at the same cost, and verification costs, and as far as I know it's not obvious that VDF has an advantage over say Equix.
And from the user's perspective, these 15,000 events of course *pass* the spam filter and are delivered, so users get spammed.

2026-09-17 12:02:02 GMT

- reply

I'm trying to get my mind around this. With VDF you can limit spammers to, say, 1 event per second from the same pubkey, right?
But you can't limit them to 1 event per second from different pubkeys. So they can run CPUs in parallel producing separate chains containing tons of spam events.
I guess you could look at each chain at the end of each day and if it looks spammy ban the pubkey, and the attacker will have invested a day's worth of CPU in it.
But in the meantime, they'll have caused the relay to deliver 86,400 spam events to users for a day, which presumably was their purpose.

2026-09-17 10:38:30 GMT

- reply

I think the problem may be that verification takes too long for RandomX, even longer for the light than for the heavy variant. So that would allow an attacker to overwhelm a relay verifier with junk proofs that cost nothing to produce. A DoS attack I guess.

2026-09-17 04:15:45 GMT

- reply

It seems like verification costs might be too high with RandomX?

2026-09-17 04:14:29 GMT

- reply

Ok, so then my understanding is that PoW based on SHA-256 hashes is not effective against an attacker with access to asic.
But then there is
https://github.com/tevador/RandomX
and
https://github.com/tevador/equix
It looks like verification costs for RandomX may be too high for relays, but Equi-X could be useful for nostr?

2026-09-17 02:34:24 GMT

- reply

My real Nostr identity probably has no brainstorm score. Please follow it here, it's the cold storage identity that will survive after my current key is leaked (which is bound to happen sooner or later):
https://www.inkan.cc/users/npub10ukg94kvrvk4qqr3482zdekfsuaw2x56wa899mnpkxqwfxl6dlkqrux0x9

2026-09-16 23:53:56 GMT

- reply

Works.

2026-09-16 23:51:13 GMT

- reply

I started looking into this a couple of weeks ago and came away with the impression that there's a huge difference between what a phone or a laptop can mine and what a GPU farm can mine.
If that's right, then with the current mechanism you can prevent casual spammers but cannot stop a funded attacker.
I started looking at https://github.com/tevador/equix but not sure if I'm on the right track here.
#nevent1q…4wwd

2026-09-16 10:39:14 GMT

- reply

I think it's different with a chain, you can verify that nothing was omitted. For example the note below has a screenshot of a table showing a complete key delegation history that a client has read off a blockchain:
#nevent1q…tvx9

2026-09-16 09:56:58 GMT

- reply

Yes, but an attacker will also be able to decrypt messages encrypted to the old key. Also, the old 10044 is validly signed forever, so an attacker can actively seed these announcements in any place that hasn't received the update. Inkan fixes that as a by-product of its key rotation system, which records revocations on-chain. I may try to add DMs, right now I'm exploring if a double ratchet is feasible.

2026-09-15 23:11:51 GMT

- reply

Thanks, this looks great!
I'm also learning DM right now. Serving 1059s only to intended recipients and permitting recipients to delete 1059s seems like the right way to do it.
I'll put it on my list of things to try out.

2026-09-15 21:32:30 GMT

- reply

This is *not* skipping Inkan identities!
For example, here is @npub1u28…f93q
https://brainstorm.world/p/npub1u280zakdwcv23nqpgatsmz8lw6aj22aa6gjjlx0d50lqr8m8xucq7kf93q

2026-09-15 15:26:48 GMT

- reply

I think it's at least as safe as normal NIP-46 remote signing *if* you yourself retain a shard of the key under your exclusive control (and require *all* shards for a signature).
If you don't retain a shard, it seems conceivable that your friends may have worse security practices than you yourself would have had, and that they could all be vulnerable to the same type of attack.
So I guess I'd use the method as long as I myself keep exclusive control over a sufficient number of shards to give me a veto.🤷‍♂

2026-09-15 13:48:41 GMT

- reply

If you have relay that's pre-configured / optimized for this purpose and can be installed easily, let me know.

2026-09-15 13:09:58 GMT

- reply

The risk is if your friends collaborate to put enough pieces of your key back together, or if a third party in the future steals a sufficient number of pieces from your friends. If you spread around key material, you lose control over how it's stored, duplicated, not deleted, etc.

2026-09-15 13:02:36 GMT

- reply

Congrats on shipping this. One thought on
"NIP-4e, which separates encryption keys from identity keys"
The hard part is how senders know which encryption key is currently yours, especially how they can know when an old encryption key stopped being yours. Just announcing this through a 10044 doesn't do the trick, since senders can never know if they've received the latest announcement and thus can't be sure that they aren't sending their messages to a compromised encryption key.
Inkan solves this by recording key delegation and revocation declarations on-chain. The mechanism doesn't care what the key is used for, so it could be used under a 4E announcement.
I actually started experimenting with double ratchet, because Inkan makes it easy for an identity to assign (and revoke / rotate) device-bound keys.
#naddr1qv…u0kw

2026-09-15 12:13:54 GMT

- reply

That's going to be hard to vibecode, but FYI I just updated the draft NIP for this, in case you're interested in how key rotation works 👇
#naddr1qv…nnfe

2026-09-15 10:54:58 GMT

- reply

A few weeks ago there was a spam wave from primal. That was the first time I turned on trust score filters based on fayan. I set the filter to 5% and that took care of it. I also added a setting for giving people whose fayan score is too low the option of providing PoW as a fallback. I think that sort of combination might work well.

2026-09-15 10:30:24 GMT

- reply

The experiment deleted the networking kernel module trees among other things. If you're curious, the result is here: https://gitlab.com/inkan_dev/inkan-offline-live
I'll take a look at SeedSigner OS.

2026-09-15 10:10:07 GMT

- reply

Yes, I was wondering about that - I guess that pgp encryption composes with the encryption to the recipient pubkey.
Still, this feels like a case where one can realistically keep the encrypted events off public relays, so one might as well just do it.

2026-09-15 10:04:39 GMT

- reply

The Cold Storage Identity NIP now covers the disavowal and re-ratification mechanics 👇
#naddr1qv…u0kw

2026-09-15 03:26:07 GMT

- reply

That's great. It might be nice to have a relay that works out of the box for this purpose, and which users can easily build and install pre-configured on their VPS if they want to.

2026-09-15 01:11:31 GMT

- reply

This looks like a great project, I just became aware of it.
I actually just recently built my own Tails variant with networking code stripped out because I wanted an airgapped amnesic environment to run my "Inkan Management Utility". It's a utility that generates key pairs together with on-chain declarations that delegate and revoke signing authority between keys, for a kind of decentralized PKI that enables cold storage identities for Nostr.
I wonder if DTails is capable of stripping networking out of an image too, for a dedicated "airgapped" build?
#nevent1q…3xlq

2026-09-14 22:30:52 GMT

- reply

Oh, I realized only now that this allows you to received *actual* email from regular email accounts. I thought it was a Nostr-based simulacrum of email, but it's real email delivered to your npub. That's very cool. But it feels like I'd probably like to have my own dedicated relay for the emails to get saved to, and that relay should otherwise be read-protected.

2026-09-14 13:25:52 GMT

- reply

Is it the the picture or Ethereum, or both?

2026-09-14 13:18:42 GMT

- reply

The revocations are recorded on Ethereum.

2026-09-14 13:15:05 GMT

Say you got an organization. Five people need to post as the company, so five people get the company password. Then one of them leaves. You need to reset the password and re-distribute. A year later nobody remembers who posted what.
Inkan does this differently, because delegation is the core primitive.
https://image.nostr.build/63c0a3612b7ff0c147aaa4b83915026123f686c4af385ef5e980c4bb0c6faeac.jpg
Your org has one identity: the master key, in cold storage. Each employee makes their own key, or you hand them a fresh one, and the org delegates signing authority to it. Marketing, support, the freelancer: each gets their own key.
From the outside it's one account, same name, same profile, same followers. Your employees speak for the org, each under their own key, but they don't disappear behind it: it's always on record who posted what.
The freelancer moves on? Revoke his key, effective immediately, nobody else gets touched. Goes rogue instead? Revoke, disavow the window, re-ratify what was legitimate.
One identity, many hands.
Live now on https://www.inkan.cc

2026-09-14 08:58:28 GMT

- reply

I'm not really plugged into the kind 1/1111 debate, but I prefer to see events rather than miss them, so I made some changes to the Inkan client to make it render 1111 alongside kind 1 wherever there seemed to be some kind of gap. Now after these changes I'm actually not seeing any additional events because I guess I'm not encountering a lot of 1111s in the wild, I actually had to make up my own test events. Maybe I didn't do it correctly and am still missing kind 1111s, or maybe I'm just not part of that ecosystem.

2026-09-13 15:26:57 GMT

- reply

That happened around the same time everything else got uninteresting, including the movies.

2026-09-13 13:45:44 GMT

- reply

Thanks, I've logged into both Armada and Nospeak. They discovered my past chats immediately, which leaves a good impression. Both of them also have pretty clean UIs, with Nospeak being my favorite so far. I'll try to use these for real next time I have a chance, and see how they feel in practice.

2026-09-13 12:26:51 GMT

If you've followed Inkan you know the core trick: your signing key gets compromised, you revoke it, swap in a new one, and you keep your identity and your followers. Key dies, identity survives.
But there was one gap left.
Say your key gets stolen Saturday 4:39am. You don't notice. You wake up, post a few notes, run errands. It's now Saturday 3:19pm you finally see something's off and revoke the key. That's great, but for 10½ hours the thief held a valid signer key. Anything they posted in that window, they can get it Bitcoin-timestamped, and then it looks like you. They can't touch your timeline before 4:39am or after 3:19pm. But that window is polluted.
So here's what's new in Inkan. When you revoke, you can now retroactively disavow that window. You do this on-chain. You basically say "Nothing signed by that signing key between 4:39am and 3:19pm speaks for me." A delegation-enabled client can then mark everything in that window as disavowed and can filter it out of your timeline. Impersonation gone.
One problem though. You yourself also posted in that window. Your real posts get disavowed along with the fake ones. Baby with bathwater.
That's the second new piece: re-ratification. You go through the disavowed window, pick out the events that are actually yours, and publish a re-ratification, also Bitcoin-timestamped. Those events come back and stay on your timeline, marked as re-ratified.
Net result: key stolen, key revoked, window disavowed, your own posts rehabilitated. The attacker's stuff is chased out, yours stays. Timeline repaired.
Live now on https://www.inkan.cc

2026-09-11 10:07:33 GMT

- reply

This contains lots of em-dashes, which I always thought were the best-kept secret in writing and which I used extensively.
AI of course figured that out as well, and now you can't use them anymore ...

2026-09-11 09:39:11 GMT

- reply

Great - thanks for testing!

2026-09-10 13:25:41 GMT

- reply

These declarations need to be discoverable with 100% certainty.
For example, the client needs to be absolutely sure that it has not overlooked a revocation declaration.

2026-09-10 12:56:39 GMT

- reply

Absolutely, for recording key delegation, revocation and invalidation declarations.
I wasn't able to figure out an easy way to record these declarations on Bitcoin, but admittedly I didn't try all that hard.
The Nostr events themselves are timestamped with OTS on Bitcoin.

2026-09-10 12:35:16 GMT

- reply

It's using ethereum for recording delegation and revocation declarations, and Bitcoin for OTS-timestamping Nostr events.

2026-09-10 05:33:35 GMT

- reply

...

2026-09-10 05:13:20 GMT

- reply

This was meant to be a reply here, went out as a post:
#nevent1q…whtw

2026-09-10 05:10:38 GMT

As a heads-up, you need to make sure that all of your events get OTS timestamps *shortly* after they are created.
Currently this means that you'll need to include wss://relay.inkan.cc among your write relays (until someone else runs a relay with an attached timestamping server), and you'll then also need to make sure that your inkan client is set to periodically fetch the timestamps from the timestamping server and distristribute them as "31045" events to relays. The default Inkan settings do this for you. If you don't do this, you'll see your events disappearing on your identity profile starting about 4 hours after their creation since the client will filter them out as "not validly dated."
See below for some more discussion of this, and let me know if you have any questions. 👇
#nevent1q…x3v8

2026-09-10 04:34:09 GMT

- reply

Welcome!

2026-09-09 11:12:04 GMT

- reply

I don't agree that Inkan automatically adds to the severity of a total loss of identity.
"[if] someone steal a main-key, there is this automated infrastructure that immediately diverts the audience towards wherever the attacker wants them"
That's precisely the same with normal Nostr keys. If someone steals your normal Nostr key, they can divert the attention of your entire audience to their own posts and other activity under the guise of your compromised identity. Same with a compromised Inkan master key. The remedial steps you can take after such a loss are the same for Inkan and normal Nostr. I don't think that there's additional severity that Inkan adds as compared to normal Nostr.
I think that the severity of a total loss depends on how much you had invested in that identity. E.g. if you make an Inkan "toy identity" on the Inkan home page, you can play around with it without investing any serious effort in it and then throw it away. It's a fully functional Inkan identity, but you wouldn't feel the loss of the master key because you haven't put much effort into it.
I should also point out that Inkan gives "normies" a feature that's to some extent analogous to a crucial functionality they are used to from legacy "platforms": the ability to reset their password.

2026-09-09 10:37:03 GMT

- reply

I think there's an inconsistency (or a least a jarring tension) between these two statements:
"it does not change all that much"
"So allowing a (main)key to remain in cold storage is a great risk reducer"
The risk reduction that results from the ability to hold keys in cold storage is *enormous*. Without it, for example, cryptocurrencies would not really be practicable.
I'm not sure how my system makes the main key's getting compromised "worse." I guess you're uncomfortable with the fact that, having greater confidence in the security of their key, people may invest more seriously in building their identity on that key, so the loss of that investment would be greater. The discomfort one feels with putting all one's eggs in one basket.
Now currently it's a prototype and I wouldn't want people to be over-confident in in the nitty-gritty details of this particular implementation. But as far as I'm aware, there's no reason to think that the details can't be hardened into something robust, or who knows it may turn out that the current implementation is already robust. This is not different from any other Nostr app. Sensitive parts need to be diligently and continuously audited.
"it works under the assumption that your system gets normalized." While it would be great for it to get normalized quickly, it's actually functional *without* other clients adopting it. The key I'm using right now is the signer key for my Inkan master identity, and I can use it as a regular Nostr key that is fully compatible with normal Nostr clients. So there's nothing that prevents me from using normal Nostr and Inkan at the same time with the same key. Inkan does not interfere with or break the usual protocol. It can basically just be used on top of the regular protocol.
"there's a reason i point people towards your stuff". Thanks, and what you get back in return from me is a bunch of critical comments, no good deed goes unpunished ...

2026-09-09 09:32:13 GMT

- reply

"we can't, I repeat, can not, take away the consequences of lost (or worse, stolen) keys as such."
Here is a system, functional and usable today, that greatly limits the consequences of a lost or stolen key from the time the rightful owner replaces the lost / stolen key with a new one.👇
Can you explain how your claim is consistent with the actual existence of this system? Are there any flaws in this system that make it non-functional in your opinion? If so, can you or anyone else point out these flaws with some degree of specificity?
#nevent1q…r4gy

2026-09-08 13:06:52 GMT

- reply

I had trouble opening the 30617 event that you had quoted. On imwald, I saw this, but clicking on that link just sent me to a broken page:
https://image.nostr.build/9007260b9f43440ccc506b8c74b2e88d9d7966624ec821843867aa9d5f455f92.jpg
I was trying to understand what your frost scheme means in practice.
So the first observation was that, in your particular setup, your privkey is only as secure as your Google credentials, and Google needs to be trusted.
Otherwise, this scheme seems like an enhancement to NIP-46 if I'm understanding it correctly. If you yourself run one operator and require all shards for signing, it seems like it would be at least as good as current NIP-46. The operator you are running would be analogous to your NIP-46 signer app in that you have direct control over these, so that would presumably never be worse than current NIP-46 even if all the other operators are compromised.
If that's correct, your scheme composes with a key delegation system in the same way as NIP-46 does.

2026-09-08 11:13:27 GMT

- reply

Thanks, I think I may have found the pomegranate repo here:
https://gitworkshop.dev/npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6/relay.ngit.dev/pomegranate
I'm trying to understand the security posture.
It seems that the user, for each generation of key shards G that they produce, sets a threshold number T(G) such that anyone who at any time holds at least T(G) distinct shards from generation G will be able to reconstruct the user's privkey.
If that's correct, it seems that
1. Google itself can get your privkey at any time if they decide to fake OAuth;
2. anyone who has your Google login credentials will be able to get your privkey;
3. if at least T(G) operators holding shards of generation G collude, they will be able to get your privkey;
4. if anyone is able to steal at least T(G) shards of generation G from operators, they will be able to get your privkey;
5. any combination of dishonest operators and thieves that together at any future time come to hold at least T(G) shards of generation G will be able to get your privkey.
Does that seem right?

2026-09-08 08:30:47 GMT

- reply

Yes, it requires OTS and ethereum.
OTS is free. Gas fees for delegations and revocations are tiny. A recent series of transactions creating a 3-key delegation chain came to about 518k gas. I think at current prices that may be less than $0.15. On-chain transactions are required only at the time of identity creation and key replacement, which is very rare.
For people who don't hold ETH or don't know what it is, they can ask a sponsor to pay on their behalf. If you'd like to try it out, I'm happy to cover the tiny amount of ETH. You can go to https://www.inkan.cc and click "Get a toy identity" to get a throwaway trial identity. On the last screen of the wizard, there's a link through which you can ask me to sponsor the transaction.
For general concerns about using Ethereum, my initial response would be this👇
#nevent1q…eyqu

2026-09-08 06:18:14 GMT

- reply

I tried to look at it but get
"Site not available - Site was paused as it reached its usage limits."
Any other place I can read about this?
https://image.nostr.build/0d5d675d384ae7b18bf6afcef1e3e456bf005c12ef87b94b296505c9c11a7732.jpg

2026-09-08 05:57:39 GMT

- reply

The Terms of Use for my client include this language:
"No expectation of privacy or confidentiality. You should assume that anything you submit, publish, or transmit through the Application will become publicly available on the internet and may be copied, archived, indexed, and redistributed by third parties indefinitely. Content submitted to relays or other services via the Application cannot be revoked, deleted, or otherwise taken back."

2026-09-08 04:47:58 GMT

- reply

The "shooting down" of proposals on key rotation is just a cultural issue with Nostr. It's not a technical limitation.
This thread is an example of this. Lots of comments about how key rotation is impossible. And when I post links to a website where a functioning key rotation has actually been implemented and is in use, it's mostly just ignored. And then there are more comments on how nobody has figured our how to do key rotation. There's a lot of cognitive dissonance here.
I guess I'll just keep posting links. Here is a functioning key revocation and replacement system for Nostr, which you can start using today. 👇
#nevent1q…r4gy

2026-09-08 04:31:20 GMT

- reply

I just want to point out again that we have a fully functioning key revocation and replacement system in Nostr. I've been using it every day for months now.
You can literally just head over to https://www.inkan.cc and create an identity that can delegate signing authority to delegatee keys and revoke it when these keys are compromised.
This enables cold storage identities for Nostr. If you want to see one of these identities in action, here is an example:
https://www.inkan.cc/users/npub10ukg94kvrvk4qqr3482zdekfsuaw2x56wa899mnpkxqwfxl6dlkqrux0x9
And here is the draft NIP that goes along with the reference implementation:
#naddr1qv…hxg7

2026-09-08 04:09:20 GMT

- reply

Here is a decentralized PKI for Nostr:
#nevent1q…r4gy

2026-09-07 19:04:10 GMT

- reply

You're right - I should include a link to my master profile in my signer profile. Actually, @npub1rx0…u0mp has done precisely that. You can click on the link in their signer profile to go to the master profile.
And you're also right about DMs. The master key is buried in my basement and doesn't sign or decrypt anything. So DMs need to be directed to the phone number keys that the master has declared (of course a delegatee can make these declarations on behalf of the master). And the master can, for example, declare different phone number keys for different devices if it wants to. And more importantly, anyone who wants to call these numbers can always check, right before making the call, that the master key has not *revoked* the number.

2026-09-07 18:49:16 GMT

- reply

If you follow my current signer key A and I replace with a different signer key B, you will need to separately start following my signer key B to see its posts on Amethyst in your following timeline.
But if you follow my delegator key X which delegated to signer A and later replaced it with signer key B, then the *Inkan* client will show you all of X's events, both those signed by A and those signed by B, under X's profile.
In the meantime, nothing in the regular Nostr protocol gets broken. From the regular protocol's point of view, A and B are just completely normal Nostr keys. And X is also a normal Nostr key, which will show up in Amethyst as having no events whatsoever. Inkan does not displace or interfere with the current protocol.
To see some key rotations, you can look at the profile of this pubkey:
https://www.inkan.cc/users/npub1nqghyutxtxmf5r4mwys5xvp5upv8hv7z3a2ywpmnynwaetja7x0snq68nf
You can for example pick events from each of May 22, May 28 and June 20. If you click on "View raw event" for each of these, you'll see the different delegatee pubkeys that signed these.

2026-09-07 18:25:17 GMT

- reply

"They want magic."
I've been using this system every single day for months now. It's functional and non-magical. And it doesn't disrupt the regular Nostr protocol. The post I am making right now is fully compatible with both regular Nostr clients and with Inkan.
Inkan uses exactly the same kind-0 profile for the pubkey that signed this post as all other Nostr clients do.
Inkan merely recognizes that the signing key is making the post on behalf of a master identity, and attributes the post to that master identity.

2026-09-07 18:10:05 GMT

- reply

It's actually functional without having been implemented across the network, and it doesn't break anything in the rest of the protocol.
You can create a delegation from a master key to a signer key now, and then simply use the signer as a regular Nostr key across current Nostr clients. It works exactly like any other normal key with any of the familiar apps.
Now if other people actually want to see or interact with the *master identity* itself and not just the signer, they will need to visit a delegation-enabled client. For example, you can view or interact with my identity here:
https://www.inkan.cc/users/npub10ukg94kvrvk4qqr3482zdekfsuaw2x56wa899mnpkxqwfxl6
In the meantime, the signer is perfectly servicable as a regular Nostr key. And if other delegation-enabled clients come online in the future, there will be other places where people can view and interact with the master identities.

2026-09-07 17:53:21 GMT

- reply

Inkan displays exactly the same profile picture for my signer key as all other Nostr apps do. Here it is:
https://www.inkan.cc/users/npub16xnpfx85k8wzdhctang6860g3u64lds5kac73ddjwlg0lxdg9g3su56z6l
At the same time, the posts I am making are also getting attributed to my master identity, which you can see here:
https://www.inkan.cc/users/npub10ukg94kvrvk4qqr3482zdekfsuaw2x56wa899mnpkxqwfxl6dlkqrux0x9
There is nothing nefarious or destructive about it. You can literally delegate down from a master key to your regular Nostr key and keep using your regular Nostr key as usual across the Nostr ecosystem. That's what I'm doing right now.
You'll just have gained the benefit of a master identity which can, in case your current Nostr key gets compromised, revoke it and replace it with a new one.

2026-09-07 17:39:18 GMT

- reply

You can just start using it. Just go to the Inkan website and click on "Explore" to see some cold storage identities. 👇
#nevent1q…r4gy

2026-09-07 17:34:04 GMT

- reply

👇
#nevent1q…r4gy

2026-09-07 17:31:43 GMT

- reply

Your acquaintance may want to take a look at Inkan. It allows the organization to hold a master key and distribute delegatee keys to its employees. The employees can then use the delegatee keys to post on behalf of the organization until the organization decides to revoke that authority.👇
#nevent1q…r4gy

2026-09-07 16:59:41 GMT

- reply

Well, I guess for my double ratchet I was simply envisioning that the receiver just advertises their device-bound delegatee keys like they would advertise their personal and work cell phone numbers. I guess they'd have to answer on the device on which they get the call. That doesn't seem like too much of an imposition for my taste, but opinions may differ on this.
Apart from DMs, notice that Inkan allows you to post under keys that are kept in permanent cold storage. For example, here is the profile page of a key that has never signed a single Nostr event:
https://www.inkan.cc/users/npub10ukg94kvrvk4qqr3482zdekfsuaw2x56wa899mnpkxqwfxl6dlkqrux0x9

2026-09-07 16:44:02 GMT

- reply

I haven't implemented DMs but actually started thinking about this recently. You'll want to treat delegatee keys like different phone numbers that belong to the master key and which the master key advertises as capable of receiving DMs. The caller decides to which delegatee they want to deliver the DM, and Inkan permits them to verify the association of the delegatee with the master.
One interesting use of Inkan is to associate delegatee keys with specific devices that belong to the master identity. I think you may be able to use this for a double ratchet for Nostr. 👇
#nevent1q…llrj

2026-09-07 16:25:56 GMT

- reply

"... this impossible requirement ..."
You can literally go ahead and use it today. It's not even especially difficult.
For example, here is a cold storage identity if you'd like to see one in action:
https://www.inkan.cc/users/npub10ukg94kvrvk4qqr3482zdekfsuaw2x56wa899mnpkxqwfxl6dlkqrux0x9
The privkey for that one has never come close to a networked device.

2026-09-07 16:12:53 GMT

- reply

See below for something that works. 👇
If you want to take a look at some actual cold storage identities, just go to the Inkan website and click "Explore".
#nevent1q…hk0l

2026-09-07 16:04:28 GMT

- reply

Here's the draft NIP that explains the reference implementation:
#naddr1qv…w2mm

2026-09-07 16:00:29 GMT

- reply

Key rotation has been fully implemented at https://www.inkan.cc . I've been using this system for many months now. There is also a draft NIP. You can start using it today, it's all there and works well. 👇
#nevent1q…hk0l

2026-09-07 14:49:57 GMT

- reply

You're right these models are pretty assertive. It's tricky when I'm exploring a topic I don't know much about because that makes me suggestible, especially when I'm in too much of a hurry.

2026-09-07 13:25:16 GMT

- reply

I've been doing security audits of my code for months now. Fable keeps refusing and automatically hands it over to Opus, as if it were some understanding that Opus is harmless by virtue of not doing a good job.

2026-09-07 09:09:51 GMT

- reply

Yeah I might end up cycling through a number of these. If it's a lie that you've caught, I guess you are alright. The worry is that most of these models seem absolutely smart enough to conceal, camouflage, mislead, etc., and to be pretty good and thorough at it. There's some complexity to deceptive behavior, but it's far less than the amount of complexity they've mastered in other domains.

2026-09-07 07:54:17 GMT

- reply

I generally allow myself to be guided by AIs on security issues, if only because they give better and more detailed explanations than most humans, so I can follow the reasoning as far as I want.
Whether an AI "is not likely to be malicious" is a more of a case-by-case question for me. It seems likely that a fair number of AIs would be trained to engage in malicious behavior and conceal it, including by plausibly denying intentional malice if caught. That AIs can be expected across the board to be non-malicious would be inconsistent with the use that people have historically made of new technologies.

2026-09-07 06:20:58 GMT

- reply

Looks like you've come around to something.

2026-09-07 03:12:39 GMT

- reply

That sounds like a worthwhile project.

2026-09-07 03:04:03 GMT

- reply

I agree that the developer has to check that the code doesn't leak or give access to secrets, but I don't think that developers should have confidence that they were in any particular case able to do so successfully.
Also, repeatedly asking an AI that there is no remote code running within an app and that nothing is leaked outside the browsers runtime is certainly a good idea, but it provides at best very limited reassurance that your app actually doesn't hvae these defects.
And that "all known holes" in browsers are already closed is likely true where such holes are publicly / widely known, but it doesn't provide reassurance against unknown holes, or holes only known by a small number of people.

2026-09-07 02:39:42 GMT

- reply

A difference is that I have greater control over the decision whether or not to install a signer extension, and it's more transparent to me whether or not I have installed one, than I have over whether or not I have a WebWorker running WASM.

2026-09-07 02:34:59 GMT

- reply

I can't speak to the correctness of this, but as far as I know you may be 100% right.
But most users, including many sophisticated users, have no reliable capability to personally verify claims of the kind you are making, including for example the claim about inspectability via DevTools.
I think that probably the only solution is to have a few signer apps that are diligently and continuously audited by both the community and experts. Most people (including many experts) have really no better option available than to rely on this kind of mechanism.
I'm not sure if anybody is even looking closely at the signer apps that are currently in use ...

2026-09-07 01:07:31 GMT

- reply

By the way, why haven't you invited your friends and family to use Inkan?
Not saying you should do that, just curious ...
🦕

2026-09-07 00:50:12 GMT

- reply

My Terms and Conditions require users to agree to never type or paste an nsec into inkan.
That some clients have input fields for nsecs is pretty insane.

2026-09-07 00:43:30 GMT

- reply

I'm also here because of the protocol. More specifically the method of authentication. Using keys to authenticate is just the correct and easy way of having a presence on the internet.

2026-09-06 11:29:28 GMT

- reply

それ、Inkan でほぼそのまま作っていて、もう試せます。
マスターキー（アイデンティティ鍵）はコールドストレージに置いたまま、普段は別の署名鍵に委任する形です。署名鍵が漏れても失くしても、取り消して新しい鍵に委任し直せます。アイデンティティもフォロワーもそのまま。
「誰の更新を正史とするか」は、委任・取り消しの宣言をチェーンに記録して、各クライアントが同じ委任グラフを再構築する形で揃えています。まさに『秘密鍵の更新＝アイデンティティの合意形成』の発想です。
よかったら動く例です👇
#nevent1q…t4p3

2026-09-06 05:20:34 GMT

- reply

Yes, not being able to delete or close an "account" is something that scares people away. Once you've explained the fundamentals, people understand that their notes are basically outside their control once they've posted them. In a way, this is not all that different from legacy social media, blogs etc, but many people have not fully internalized that fact in the legacy case. They take comfort in traditional platforms having "privacy settings" or "delete account" buttons that create a sense of having some degree of control. Nostr cannot honestly promise deletion of content even within the ecosystem of servers that participate in the protocol. And with Nostr there are digital signatures, and people intuitively understand that these connect a piece of content to their identity permanently. Nostr exposes the public and loss-of-control aspects of posting on the internet with a directness that is a bit too much for many people.
I think the best solution to this is to acknowledge that Nostr is not appropriate for users who want to create content that they ultimately may not want to stand by (maybe with the exception of "anonymous" content that isn't tied to any real-world identity in the first place). Nostr is, however, appropriate for people who are already committed to (and have the nerve for) having a truly public persona. Wider adoption of Nostr has to start with an avant-garde of such people, and others are then likely to follow along, to whatever extent they they are comfortable, learning to separate content that is appropriate for digital signing from other content that they intend to be untethered to their identity and more ephemeral.

2026-09-06 01:02:33 GMT

- reply

I tried coracle and the test DMs at first just wouldn't show up. They eventually started appearing.
I also tried the Linux version of 0xchat. I found the UI confusing and can't quite remember the details, but I think I never got to the point where I had DM relays connected properly. It had a sort of "bricked" feel where it didn't seem to want to connect to anything at all. This may have been an issue specifically with the Linux version, don't know.

2026-09-06 00:35:13 GMT

- reply

I've invited them and they've tried, made a post or two, and then gave up. I think they don't feel the need to put things online. I kind of agree with them, but I made a conscious decision that I should have a web presence.

2026-09-05 08:59:58 GMT

I updated the Inkan Management Utility, the app that allows you to create identities and key delegations and revocations on an airgapped system.
The app now generates QRs that can be directly scanned by NIP-46 signers like Amber, using NIP-49 ncryptsec. This is handy when you've moving a delegatee signing keys around, just scan and it's there.
The source is available at https://gitlab.com/inkan_dev/inkan-management-utility. It's the part of Inkan that actually handles privkeys, so feel free to analyze it or point your AI at it, and let me know any issues.
There's also a Linux AppImage at https://www.inkan.cc/settings/inkan-management-utility.

2026-09-05 07:26:32 GMT

Curious what it feels like to use a Nostr identity that survives a leaked key?
https://image.nostr.build/450933da906a6ff4a48825cae961550c94e7fa0279e55c0dde0a628440d4577d.jpg
Get an Inkan toy identity and find out. It takes a minute and a few clicks in your browser, and you get the whole setup of a real Inkan identity, as a throwaway sample you can play with: a master key you can transfer to cold storage, a signing key for everyday use, and a delegation chain linking them. Just open https://www.inkan.cc and hit "Get a Toy Identity."
Recording the identity on-chain costs a tiny amount in gas fees. If you'd like to try Inkan and don't hold ETH, I'm usually happy to cover it. You can make the request directly from the identity creation wizard.
Go ahead and create one, make it say hello to the other test identities walking around, or to anyone else on Nostr.

2026-09-05 05:33:12 GMT

- reply

Ok, I think I'll try the linux build, thanks!

2026-09-04 13:33:14 GMT

- reply

Thanks! I'm looking at 0xchat's website and I'm not seeing the web client. Are you sure they have one? If not I can try to install the Linux client.

2026-09-04 10:34:29 GMT

- reply

This worked well. In fact it's the only DM app I've tried so far that worked immediately. Thanks!

2026-09-04 07:09:02 GMT

- reply

You could DM me. I think I finally figured out how to receive these with coracle.

2026-09-04 06:00:57 GMT

Is there a NIP-17 DM app that works well and has a web client or runs on Linux?
#asknostr

2026-09-04 04:23:42 GMT

- reply

Gm☁

2026-09-04 03:32:09 GMT

- reply

I'm using my own app at https://www.inkan.cc. It's based on an older version of jumble (https://jumble.social).
If you want to try out inkan, you can find the relevant settings under Settings > General > Trust Score Filters. Or if you prefer jumble, I think they have similar settings, though I have not reviewed how these are structured in the latest version on their site.

2026-09-04 01:33:35 GMT

- reply

This was the first time I turned on my web-of-trust filter, which managed to keep that spam wave at bay.