Nostr notes by

It's easy to use, the friction is basically the airgapped ...

2026-09-23T06:58:53Z

In reply to nevent1q…e5cw
_________________________

It's easy to use, the friction is basically the airgapped identity creation. Not really difficult, just stepwise, and people have no patience for going through a stepwise process right up until they do, and at that point it basically becomes second nature.

Yes a narrative is needed and it's hard and I don't have one yet. One thing that's working for inkan over the mid-term is that people will get their keys compromised, some of them more than once. The people interested in inkan now are sort of like coldcard users who rolled dice before this summer, not necessarily smarter but maybe a bit more introspective, or maybe just having better habits in the first place. But it's a somewhat different narrative when money is involved more directly, so not fully on point.

I'll taka a look at Seligman and Maier, I agree that's the right kind of lense for this.

Yeah, and it's actually worse than just hate, they are ...

2026-09-22T03:32:49Z

In reply to nevent1q…jhp7
_________________________

Yeah, and it's actually worse than just hate, they are *correct*. I think economists call it "rational ignorance," and it can be the right move with limited cognitive resources. So you don't read the NIP, you instead watch what your peers do, except the problem is your peers are watching you, so there's paralysis. The key rotation discussion on nostr is this bottomless information cascade, and that probably applies to other topics as well. I guess the trick is to make checking cheaper than doubting.

Thank for pointing it out, that looks very wrong! Can you do ...

2026-09-21T11:25:40Z

In reply to nevent1q…0avl
_________________________

Thank for pointing it out, that looks very wrong!

Can you do [ctrl/cmd]+shift+R, or alternatively go to Settings > General > Check for updates?

After the app has updated, can you see if it works better?

If I'm understanding this correctly, it should be at least as ...

2026-09-21T16:00:46Z

In reply to nevent1q…7vuw
_________________________

If I'm understanding this correctly, it should be at least as safe as NIP-46 if you hold your own shard and require all shards to open the vault. (I guess that also assumes that the underlying cryptography is as good as when you just hold the full key.)

If you have your own vault, is the experience of that similar to having a remote signer? Can one have a vault on one's phone, maybe something that can be used like Amber?

Great, thanks for calling my attention to it! The UI changes were ...

2026-09-21T11:41:10Z

In reply to nevent1q…5tpr
_________________________

Great, thanks for calling my attention to it!

The UI changes were due my adding an AI-based nostr search feature. If you're interested, I gave you access to it, just click on "Assay" in the nav bar and take a look if you like.

I'll probably revoke access again soon as it's still a construction site, but if you'd like to try some searches in the meantime for a quick preview, feel free to do so, I think it's kind of fun.

now it's fixed

2026-09-21T11:28:03Z

In reply to nevent1q…w5pu
_________________________

now it's fixed

something is messing with the ui @npub16xn…6z6l ...

2026-09-21T10:06:45Z

something is messing with the ui inkan (npub16xn…6z6l)

So there's this nostr paradox, why would a community obsessed ...

2026-09-21T05:49:20Z

So there's this nostr paradox, why would a community obsessed with crypto and key security refuse to even test working key rotation?

Because you can't tell working from broken without spending your own time on it.

After enough broken NIPs and abandoned apps, you learn to price every new thing as a lemon and assume broken. The good leaves the market with the bad. 👇

https://en.wikipedia.org/wiki/The_Market_for_Lemons

nostr is my only bridge to the worlds of ai engineers, except I ...

2026-09-20T09:46:25Z

In reply to nevent1q…t808
_________________________

nostr is my only bridge to the worlds of ai engineers, except I used to work in the building next to their headquarters I think

it's new and hyped to the tits on linkedin by the typical ...

2026-09-20T09:31:02Z

In reply to nevent1q…gs4d
_________________________

it's new and hyped to the tits on linkedin by the typical "Ai Engineers" :copy_812bf741_ab2f_40ad_abf9_188:

That feels right ... I had never heard of jev, thanks for ...

2026-09-20T09:27:35Z

In reply to nevent1q…ud9k
_________________________

That feels right ... I had never heard of jev, thanks for pointing it out.

the thing is, this simple stuff, which you usually run more than ...

2026-09-20T09:15:20Z

In reply to nevent1q…77n9
_________________________

the thing is, this simple stuff, which you usually run more than 100 times is always worth it. for a single test? prehaps jev has a place, but then again, it's just overhead in your stack

This sounds like when a mechanical solution exists you'll ...

2026-09-20T08:47:00Z

In reply to nevent1q…g9jp
_________________________

This sounds like when a mechanical solution exists you'll want to use that. And when none exists, it may be cheaper to create a mechanical solution and use it. Maybe jev is useful when it's not clear how to create a mechanical solution?

yes, which is also why there are no failures compared to jev ...

2026-09-20T07:35:11Z

In reply to nevent1q…079a
_________________________

yes, which is also why there are no failures compared to jev

https://paragraph.com/@metaend/we-put-the-typed-decision-engine-on-four-of-our-own-jobs-it-lost-three

Do your mechanical solutions require custom-tailoring to the task ...

2026-09-20T07:15:22Z

In reply to nevent1q…fekh
_________________________

Do your mechanical solutions require custom-tailoring to the task at hand that jev doesn't require?

So I had our whole fleet on #jev yesterday, running benchmarks ...

2026-09-20T04:33:30Z

So I had our whole fleet on #jev yesterday, running benchmarks and tests mostly against mechanical solutions we run anyways, and it was around 10% inferior to our solutions on average. Plus our stuff runs offline

If "convergence delay" is meant to refer to a delay that ...

2026-09-19T11:39:12Z

In reply to nevent1q…gkm2
_________________________

If "convergence delay" is meant to refer to a delay that occurs before *relays* agree on the same set of revocations, then that term carries a presupposition that relays *will* at some point converge. As far as I can see, there isn't any particularly strong reason to think that they will ever converge.

(I'm not sure what "DST" is.)

[Test]

2026-09-19T01:20:04Z

In reply to nevent1q…vy9m
_________________________

[Test]

Huh, I had kind of forgotten about these sites. I never really ...

2026-09-18T22:16:03Z

In reply to nevent1q…q8j5
_________________________

Huh, I had kind of forgotten about these sites. I never really used them, let alone considered posting anything on them, and this made me remember why.

It also makes me think that we actually have a pretty nice crowd here on current nostr, at least relatively speaking.

And I'm not so worried about the community here turning nasty, not because I think it couldn't ever happen, but because the consequences would be limited.

On sites like reddit, it feels like you are locked into some narrow space with your peers, and there is no escaping or avoiding them. With nostr, because you have your own keys, you can be more of a nomad. When this particular spot doesn't suit you any longer, because there's no shade or for whatever reason, you just take a minute to pack up and move to another one, taking everything you need with you.

It's a very different feel, and it has to do with the underlying structure of the protocol.

more reliable? unreliable? relia-bro?

2026-09-18T15:35:45Z

In reply to nevent1q…su3r
_________________________

more reliable? unreliable? relia-bro?

I think it's difficult to do without a blockchain.

2026-09-18T15:23:54Z

In reply to nevent1q…6utx
_________________________

I think it's difficult to do without a blockchain.

Nostr event nevent1qqsqku9elrzlq2xasterqma689q8832hsj32lj56wxvgg25anchxhlcprfmhxue69uhhyetvv9uju6twddskutnrvvhkjmnyd9ssygqenufvjnlx52grjzxydm7tjyvsmxvnkuuq3pkfsvsmt8z38h9fwv6p7ers

2026-09-18T14:59:42Z

Jev deez nutz

With a retrospective disavowal, you have to trust that what they ...

2026-09-18T13:46:34Z

In reply to nevent1q…xzen
_________________________

With a retrospective disavowal, you have to trust that what they are telling you is true, i.e. that their key was really compromised.

I agree about signatures. I think your post was maybe referring ...

2026-09-18T11:52:41Z

In reply to nevent1q…g6yy
_________________________

I agree about signatures.

I think your post was maybe referring to my statement "To trust a self-declared disavowal, you have to trust the *person* behind the master key" ?

What I meant is - suppose a person posts a note that's validly signed by their master key which says:

"My signer key was compromised two weeks ago. Don't trust any notes that were signed by the signer key during the last two weeks, especially the notes saying that I was traveling in Denmark, I did not post these, someone impersonated me!"

Then you have to decide whether or not to trust that the person is telling the truth when they say that that their signer key was compromised and that they did not themselves post the notes saying that they were traveling in Denmark and that someone impersonated them.

That's what makes retroactive disavowals of events *very different* from key revocations. Key revocations are acts that occur at objectively verifiable times, i.e. when they are recorded on-chain. Retroactive disavowals of events are subjective statements that other parties may choose to believe, or not.

The logical structure of retroactive disavowals is completely ...

2026-09-18T12:29:23Z

In reply to nevent1q…4ffu
_________________________

The logical structure of retroactive disavowals is completely different from that of delegations and revocations of signing authority.

A delegation declaration is a speech act that has an immediate automatic effect, i.e. to initialize a delegation relationship between two keys. It's like saying "With this ring I thee wed", which has the effect of initializing a marriage. And a revocation declaration is also a speech act with immediate automatic effect. It terminates the delegation relationship, just like putting a signature on the final divorce papers terminates the marriage. These speech acts are historical events with objective temporal placement, marking the exact beginning and the end of the relationship.

A retroactive disavowal of a signer key is a mere claim about the past, specifically about who used the signer key to sign certain events. You are saying that it wasn't *you* but *someone else* who used the key to sign these past events. This claim may be true or false, others have to look at the circumstances, any relevant evidence and your credibility and decide. This claim about the past does not bring into existence any new delegation relationship, and it does not terminate any delegation relationship.

One reason that Inkan works is that it cleanly separates the logic of delegation and revocation declarations from that of retroactive disavowals.

Thanks, I guess "fork" and "join" are concepts ...

2026-09-18T10:49:04Z

In reply to nevent1q…vkhq
_________________________

Thanks, I guess "fork" and "join" are concepts that apply in the cryptocurrency context, so probably not directly applicable to inkan.

I'm not sure what "it" is in this sentence: ...

2026-09-18T10:35:24Z

In reply to nevent1q…g5l3
_________________________

I'm not sure what "it" is in this sentence:

"it's cryptographically identifiable"

Also: If others know and agree on the objective time of the ...

2026-09-18T10:32:53Z

In reply to nevent1q…3drc
_________________________

Also: If others know and agree on the objective time of the revocation, they can *at least* agree that events that are dated subsequent to that revocation time should not be attributed to the revoker.

They can do so regardless of whether or not they agree on how to handle events that are dated between the self-declared start time of the disavowal and the objective time at which the revocation was recorded.

To trust a self-declared disavowal, you have to trust the ...

2026-09-18T10:16:12Z

In reply to nevent1q…d92m
_________________________

To trust a self-declared disavowal, you have to trust the *person* behind the master key.

When somebody retroactively disavows past events that were ostensibly signed on their behalf, then a question arises as to whether that disavowal is honest or not.

This question cannot be decided mechanically or by an algorithm. You have to look at the circumstances of the particular case, and you can only do so to the extent you have access to relevant information.

And an important piece of such information is the *time* at which the person made the disavowal, whether it was made retroactively or not, and, if so, which events fall within that retroactive window.

In many cases, you will simply believe the person who made the disavowal and not attribute the disavowed events to them. You can simply set the inkan client to not show these events, or if you operate a relay you may decide to delete them.

oof

2026-09-18T09:32:16Z

In reply to nevent1q…hpkx
_________________________

oof

My primary use case is actually just regular nostr users whose ...

2026-09-18T09:14:13Z

In reply to nevent1q…z30l
_________________________

My primary use case is actually just regular nostr users whose keys can get leaked or lost, basically the same reason everyone wants to be able to reset their X password when it gets stolen. It's nothing too specialized, although the system *can* be used for contracting if one wants to.

And just to note this, a revocation primarily protects *the impersonated person*, not the reader of the revocation. So "just ignoring revocations" means basically "the thief gets to keep posting as you to every client that ignores the revocation."
And for revocations to protect anyone, clients have to be able to find them, and they must agree *when* the revocation happened since the revocation is what separates your own old posts from those of the thief.

I agree, and inkan gives you exactly that functionality. When you ...

2026-09-18T08:09:01Z

In reply to nevent1q…7svy
_________________________

I agree, and inkan gives you exactly that functionality.

When you revoke, you can optionally declare a past time starting at which you "disavow" events signed by the key you are revoking ("I consider this key to have been compromised since September 14, don't trust anything signed by it after that date!").

But the design point is that inkan won't allow you to silently rewrite history that others relied on. Everyone can see both (i) when the revocation was actually recorded on-chain and (ii) the past time from which you disavow.

So third parties get the full picture, i.e. these events were validly signed during the delegation, and the author now disavows them. Clients can either hide disavowed events or show them with a disavowal badge.

There's also a re-ratification mechanism that allows you to rescue your our own legitimate events inside a disavowed window. 👇

quoting
nevent1q…krrt
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

I'm not sure what exactly you mean by "fork" or ...

2026-09-18T07:00:10Z

In reply to nevent1q…6cvv
_________________________

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.

"Y can never spend anything that X signs" I think ...

2026-09-18T06:08:08Z

In reply to nevent1q…sjxz
_________________________

"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.

"when there is no utxo ... in the data" But the data that ...

2026-09-18T03:48:55Z

In reply to nevent1q…kewk
_________________________

"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.

I'm not really familiar with these, but are these consensus ...

2026-09-18T01:25:57Z

In reply to nevent1q…9kaz
_________________________

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.

[By the way, my comment above should have said "Recording a ...

2026-09-18T00:32:39Z

In reply to nevent1q…rfwv
_________________________

[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.]

I wonder how a non-blockchain consensus mechanism would work. ...

2026-09-18T00:29:24Z

In reply to nevent1q…9vc2
_________________________

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

"store the revocations with a guarantee of availability" ...

2026-09-17T14:36:54Z

In reply to nevent1q…gzzv
_________________________

"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*.

That could be, I just don't have the data to compare the ...

2026-09-17T13:33:21Z

In reply to nevent1q…2euj
_________________________

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.

A funded attacker will not be working with a typical 4 core ...

2026-09-17T12:41:42Z

In reply to nevent1q…nzr4
_________________________

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.

I'm trying to get my mind around this. With VDF you can limit ...

2026-09-17T12:02:02Z

In reply to nevent1q…jgr7
_________________________

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.

I think the problem may be that verification takes too long for ...

2026-09-17T10:38:30Z

In reply to nevent1q…6kun
_________________________

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.

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

2026-09-17T04:15:45Z

In reply to nevent1q…j20p
_________________________

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

Ok, so then my understanding is that PoW based on SHA-256 hashes ...

2026-09-17T04:14:29Z

In reply to nevent1q…lqee
_________________________

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?

My real Nostr identity probably has no brainstorm score. Please ...

2026-09-17T02:34:24Z

In reply to nevent1q…q77q
_________________________

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

Works.

2026-09-16T23:53:56Z

In reply to nevent1q…fm9p
_________________________

Works.

I started looking into this a couple of weeks ago and came away ...

2026-09-16T23:51:13Z

In reply to nevent1q…987s
_________________________

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.

quoting
nevent1q…4wwd
Your earlier post made a lot of sense, so I added this to my client.

Basically the client now lets you hide posts from anyone outside your 2-hop WoT or your fayan reputation percentile (depending on your settings), and it also has the escape hatch you describe, i.e a PoW exception toggle where the user can choose to nonetheless admit posts that fail the above filters if they carry enough PoW (the user can set the difficulty). So a newcomer who isn't in anyone's graph can still get seen by doing some amount of work, which I take it was the point of your suggestion.

I also put in diagnostics so people can look at a pubkey's fayan rank/percentile and check for any two pubkeys whether the first is in the WoT of the second. So a new user can actually assess where their own pubkey stands and decide on that basis whether they need to add PoW to their posts. I've also made the WoT calculation delegation-aware, which matters for inkan since a the followers of a cold-storage identity can live under its delegatee keys.

One thing that bugged me is that there's apparently no standard way to announce what PoW your client will accept. So a newcomer can't discover the number, they have to guess or be told, maybe in the intended receiver's profile bio. It would be helpful to have a field for declaring one's PoW requirements in some event type, maybe in kind-0 profile events or something similar.

Also it seems that the leading-zero method of NIP-13 can only filter out casual spam but not a well-funded attacker. I started looking around and came across Equi-X. I haven't reviewed it in detail, but maybe it can help narrow the gap between what a normal person can mine and what a bunch of GPUs can mine.

Doing some GEO analysis our harness found a big one: ...

2026-09-16T17:45:07Z

Doing some GEO analysis our harness found a big one: misconfigured woo commerce plugin literally made critical and private data un-gated AND INDEXED available to the unauthorized public.

I would say that's bad, but also a nice extra for hiring me to fix your shit

I think it's different with a chain, you can verify that ...

2026-09-16T10:39:14Z

In reply to nevent1q…ld0s
_________________________

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:

quoting
nevent1q…tvx9
The way it usually goes, your online identity is your private key. If the key is compromised, there goes your identity. Inkan fixes that.

You keep a master key in cold storage and a signing key for everyday use. If the signing key ever leaks or gets lost, the master revokes it and delegates to a new one. Same identity, same followers, fresh signing key.

If you'd like to take a look at the prototype: https://www.inkan.cc. Log in with your NIP-07 extension and say hi to the test identities already walking around. Or make one of your own.