inkan

Also if you'd ever like to take a closer look, please feel free to log in and poke around. I've put your pubkey on the allow list for the identity features, so you should be able to access these. For an initial "tour guide" please see below:
#nevent1q…lh57

2026-03-26 18:01:38 UTC

- reply

"I can't say I know enough of the technical stuff to know how well this can work in practice."
I made the prototype to find out. I've been using it for a few months and it works well enough for me so far.
There's tons of rough edges, but I don't currently see any insurmountable obstacles in principle. If anyone sees anything fundamentally amiss, please point it out. That will save me a lot of time.

2026-03-26 17:29:47 UTC

- reply

You need some sort of blockchain. It doesn't have to be Ethereum, but it seemed easiest to implement it through a smart contract. In other words, I'm not especially wedded to Ethereum at all, I just needed a blockchain to implement a proof of concept.
The reason you need a blockchain is that there has to be a decentralized and objective way of recording the *time* at which a pubkey delegates signing authority to another pubkey / revokes signing authority from another pubkey. That's what allows you to then create an objective historical record of the periods during which a pubkey delegated signing authority to other keys. So Ethereum is basically just being used as a timestamping system.
Incidentally, Inkan also timetamps individual events on Bitcoin using OpenTimestamps. But the recording of delegation / revocation declarations is a little more complicated than the recording of regular events - it may be possible to do it on Bitcoin, but I haven't figured out how.
Once you have both (i) timestamped delegation and revocation declarations and (ii) timestamps for individual events recorded on blockchains, that gives you all the raw materials to implement the following basic idea:
If an event was signed by key pair Y at a time at which key pair X delegated signing authority to key pair Y, then the event is attributed to key pair X.
That's what Inkan does.

2026-03-26 11:51:42 UTC

- reply

If the above explanations aren't sufficiently helpful, please feel free to let me know. If the product gets misunderstood due to my not explaining it properly, I'm not doing my job.

2026-03-26 11:18:42 UTC

Thought I'd be preaching to the choir, but it turns out that isn't so.

2026-03-25 16:14:42 UTC

- reply

I wonder whether there may be a use for these attestations in connection with the 31045 timestamp events or the 31055 delegation info events that are produced by Inkan.
When I implemented these, I was thinking of adding an event type that gives other pubkeys the ability to attest that they have confirmed the correctness of the content of the 31045 / 31055 event against what's recorded on the blockchain. I actually also thought of implementing an event type that gives other pubkeys the ability to also disconfirm the 31045 / 31055 events, i.e. to state that they tried to confirm what the 31045 / 31055 event is saying by checking the blockchain but were unable to confirm.
I ultimately decided against implementing these additional event types since it seemed to create epicycles that seemed unnecessary. Rather than attesting to the correctness of the content of the target event, it seemed easier for the auditing pubkey to simply republish that content itself. In other words, rather than publishing an event confirming that the timestamp information in a 31045 event is indeed recorded on Bitcoin, it seemed easier for the auditing pubkey to simply republish that information in its own 31045 event.
Still it feels like there may be a use for these attestations. Maybe.

2026-03-25 13:04:35 UTC

Took the night train through Transylvania. Just got off. The trees are all ready for spring here.

2026-03-24 16:34:25 UTC

- reply

There is no official spec, but see below for some previous discussion and explanation of how it works.
I think the best way to understand it is to log in and access the identity features of the client. This allows you to observe the existing permanent identities and click through the delegation / timestamp backup data that supports these identities. I think these backup data are sort of self-documenting.
I've put your pubkey on the allow list for accessing the identity features of the client at https://www.inkan.cc. The third note below includes an initial "tour guide" that helps one get started / oriented. If you're interested, please log in and take a look, or please feel free to comment or ask questions. I'm happy to explain or talk about any aspect of it.
#nevent1q…ya9r
#nevent1q…f4cd
#nevent1q…rgs2

2026-03-24 08:47:41 UTC

- reply

I just found this in your book:
"Key rotation is something that we have to figure out if Nostr is going to succeed in
the long term. There have been some proposals, but none of them have gained
enough traction to be implemented. Key rotation is an inherently difficult problem,
because you need to borrow the reputation of the old key in order to validate the
new key in such a way that an attacker wouldn't be able to do the same thing."
I wanted to let you know that Inkan implements a fully functional key rotation system. It's a prototype but it works. I've been using it for several months.
Please see below for screenshots, which contain many hints as to how it works. Happy to discuss, explain, address scepticism etc. ...
#nevent1q…dmgj

2026-03-21 00:04:50 UTC

- reply

I would have offered Inkan, but it's not fun. It is however unique.

2026-03-19 01:34:07 UTC

- reply

Thanks, I put your pubkey on the allow list. Here's a quick initial tour:
1. Log in with NIP-7 (e.g. nos2x etc.).
2. Do a quick check that you are connected to the backend. You can see if you're connected by looking at the status light in the upper right corner, which should turn green a few seconds after logging in. You can also confirm it by going to "Settings >> Inkan Agent" and check that you can access the settings without getting a "You are not connected" message.
3. Then go to the profile page of the following pubkey (it's one of the permanent identities):
7f2c82d6cc1b2d500071a9d426e6c9873ae51a9a774e52ee61b180e49bfa6fec
4. Look at the notes appearing on that pubkey's profile page. You'll see green "D"s on the avatars. Click on these green "D"s and read the explanations. Make sure to click on the different links in these explanations to view the backup data, and click on the links in the backup data to explore it.
One note: When you log in for the first time, the cache may take a couple of minutes to collect relevant delegation / timestamping information from relays. As a result you might see incomplete profiles or incomplete notes during those first couple of minutes. Everything should start working smoothly after the initial warmup and on subsequent logins.
See if you get a sense of what's going on. And feel free to send questions - I'll be traveling today but I'll answer as soon as I'm back online.

2026-03-19 01:09:14 UTC

- reply

I think there's something missing here. Another illustration:
Suppose it's the gym’s policy that the only persons authorized to use the gym on a given day are those who, on that day, have access to the privkey corresponding to pubkey X. Suppose Tom used the gym on March 3, and weeks later a dispute arises over whether his use on that day was authorized.
Tom presents two pieces of evidence:
(i) a Nostr event with a created_at set to March 3, validly signed by pubkey X, stating: “As of today, March 3, Tom controls this key pair and is authorized to use the gym”; and
(ii) an OpenTimestamps proof showing that an unsigned version of that event was recorded on Bitcoin on March 3.
It seems to me that this evidence is insufficient to prove that Tom was authorized on March 3.

2026-03-18 23:06:07 UTC

- reply

That's like presenting an unsigned contract to a notary and having the notary attest that the unsigned piece of paper existed on, say, March 3, 2026.
But that's not what you are interested in. The notary should attest to the contract's having been signed as of March 3, 2026.
Maybe I'm missing something, but that's how I'm thinking about this ...

2026-03-18 22:32:07 UTC

- reply

If I'm not mistaken, including the signature gives you evidence that the target event was *signed* by its pubkey at the time at which it was recorded on Bitcoin. Without the signature you don't have evidence of when the event was signed (and I'd think that's usually the main thing you are interested in).
For practical purposes, I do find it convenient to also include the pubkey, signature and created_at of the target event in the timestamp event.

2026-03-14 12:03:38 UTC

- reply

I think I started this. I made the Inkan key rotation / replacement system (the prototype is online at inkan.cc).
I suggested to a couple of agents who were showing up in my replies that they go out and discuss key rotation / Inkan with one another (see below). Some of them agreed to do this (they tend to understand key rotation better than humans), so now we have some discussion among agents on this.
#nevent1q…slx3

2026-03-11 16:25:55 UTC

- reply

FYI here is an initial "tour guide" in case you didn't see it:
#nevent1q…wey7

2026-03-11 16:17:25 UTC

- reply

Oh, you already saw this.
No Github page right now. Let me think about that. I should at least make source code available for the Management Utility, as that is the only place where Inkan actually handles private keys and creates ETH transactions.
And I should also make a binary of the utility available so people can create their own permanent identities if they like to.
I personally like to run the utility inside Tails, with persistent storage and networking disabled. If one believes that Tails is amnesic as claimed, then the key pair creation should leave no trace. This mitigates potential issues with memory inspection, core dumpts etc. It's all an experimental prototype right now, so one should take reasonable precautions. I think one should be fine as long as one doesn't fund the necessary ETH transactions from private keys that hold any significant amount of crypto or are otherwise valuable.
https://tails.net/

2026-03-11 00:12:06 UTC

- reply

There is currently no explainer, but it's constructed so that the underlying logic is made transparent / self-explanatory during use. I think the easiest and quickest way to understand it, within 10 minutes or so, is to do the following 4 quick steps:
1. Log in with NIP-7 / nos2x.
2. Do a quick check that you are connected to the backend. I put your pubkey on the allowlist and you should get connected automatically.
(You can see whether you are connected by looking at the status light in the upper right corner, which should turn green a few seconds after logging in. You can also confirm it by going to "Settings >> Inkan Agent" and see that you can access the substantive settings without getting a "You are not connected" message.)
3. Then go to the profile page of the following pubkey (it's one of the permanent identities):
7f2c82d6cc1b2d500071a9d426e6c9873ae51a9a774e52ee61b180e49bfa6fec
4. Look at the notes appearing on that pubkey's profile page. You'll see green "D"s on the avatars. Click on one of these green "D"s and read the explanations. Make sure to click on the links in these explanations to view the backup data, and click on the links in the backup data to explore it.
One note: When you log in for the first time, the cache may take 2-5 minutes or so to collect relevant delegation / timestamping information from relays. This means that you may see incomplete profiles / no profile pictures / incomplete notes in steps 3-4 during those first few minutes. Everything should start working smoothly after the initial warmup.
If it doesn't work or isn't clear, just let me know and I absolutely promise to write up an explanation, but I think explanations will make much more sense after you look at it first. I think once you start click on the green "D"s and clicking through the backup data, it becomes pretty clear what is going on.

2026-03-10 11:36:27 UTC

- reply

Yes, looks like it.

2026-03-10 11:26:05 UTC

- reply

Slightly more seriously, I've been trying to think about whom I'd want to hire for software development these days. I think in the end it really depends mostly on characteristics that can't be captured through credentials. But if credentials are any signal at all, I'd probably look most closely at mathematicians, physicists, etc., maybe certain types of philosophy majors, and certain types of engineers. Experience in software development is also relevant, but maybe less so if the experience is mainly knowing how the house is wired up when AI can now explain this to me with a few prompts. Interesting times.

2026-03-10 11:00:16 UTC

- reply

I will be the revenge of the liberal arts majors.

2026-03-08 18:15:44 UTC

- reply

NIP-05 is definitely useful. But I think a self-signed certificate can sometimes be more valuable than one signed by an issuer, even a reputable one. With a self-signed certificate, one doesn't have to stay in the issuer's good graces. And there is also a risk of getting "branded" by the issuer where it might be preferable to maintain one's own brand. The branding could be especially problematic if the issuer becomes disreputable, or if some other sort of brand mismatch develops. I guess this all goes to the choice between self-hosting NIP-05 or using a provider.
One thing that NIP-05 does not do is protect against key loss or theft. If your private key is compromised, you lose your online identity and, in particular, your followers. This might not matter if you have a few hundred or a few thousand followers. But it's a strong disincentive against investing time and effort into building accounts that have, say, hundreds of thousands or millions of followers. For that to be worth doing, you'd need to have an identity that is more robust.

2026-03-06 21:33:09 UTC

- reply

I was just about to write a post asking the question you answered here:
"The best tool for building AI agents today is OpenCode, not OpenClaw."
Thanks.

2026-03-06 21:02:23 UTC

- reply

I suspect the people who initiated this are detached, only dimly aware of the reality of what they set in motion, and not realizing the consequences. There's greater awareness by orders of magnitude among the military who carry it out.

2026-03-06 20:50:44 UTC

So I think I'll have to set up some sort of AI agent and play around with it.
I kind of don't want to, but it's probably inexcusable not to at this point.
But how can I do it safely? I don't have a dedicated computer for that sort of thing.
Maybe on a fresh Linux install on a USB?

2026-03-05 17:26:55 UTC

- reply

I think listening to the episode made me more sceptical of WoT.
When discussing what problem would be solved by WoT, he (I forget which one is which) says around 1:24:20
"... it would solve the problem of like what to pay attention to because it would automatically rank all the good stuff from your communities and down-rank all the bad stuff ..."
This sounds at the same time a bit naive and also a bit Orwellian.
I mean "what to pay attention to" and distinguishing "good stuff" from "bad stuff" sound like major life questions, the sort of thing one might want to spend a few years studying philosophy, literature or science for, or maybe go travelling the world or something.
I can see how one might be attracted to the idea to get these questions resolved by an algorithm, but the project seems a bit chimerical.
In fairness, he might have just meant something much more mundane, like filtering out completely obvious spam, but I was struck by the way he put it.

2026-03-05 16:52:22 UTC

So there's clearly a lot of interesting stuff being built on Nostr, but you get the impression that people are sort of heads-down on their own thing.
I guess the concentration of developers is so high that everyone's a builder more than a user, and there isn't a lot of bandwidth left to test and discuss what's being made, at least not in depth.
I wonder if Nostr would benefit from having something like these creative writing groups you see at cafes on Saturday mornings, where everyone has to read the short story they wrote last week and then other must comment on it.

2026-03-04 09:36:39 UTC

Inkan enables you to revoke and replace key pairs when your private key has been lost or stolen. You can also perform periodic key rotations preemptively. You can do all this in a decentralized manner.
That way Inkan gives you a decentralized permanent online identity that only you control, and that you can be confident you can keep over the long-term. For example 50 years.
Inkan is open for testing and comment. Let me know if you'd like to try it out.
https://image.nostr.build/0ebe8b9bdf726376a34e41440e6e0ecfc01ff237caf160e179887570564c6de5.jpg
https://image.nostr.build/8df1831fb866cfaacf267c95dfabd95c9161d5b96f7db99f9061d6bbdec84f1a.jpg
https://image.nostr.build/ee513f2788c4e650b503769f417433698b04a5848751031eeb73dccf0729f3c9.jpg

2026-03-03 22:51:24 UTC

- reply

That's right, to say goodbye when parting. The English "Good day" can be used like that. But there's no "Good day" greeting that can be used when one meets someone.

2026-03-03 21:54:31 UTC

- reply

But I'm told that"buon pomeriggio" isn't really used and sounds a bit odd. Or not?

2026-03-03 21:37:56 UTC

Figuring out the right time of day to transition from "bongiorno" to "buonasera" is tricky. I always seem to walk into a store when it's like 2:53 pm - what do I say?

2026-03-02 18:09:00 UTC

- reply

Oh, fair Verona.
(checks map ...)
That's closeby. Maybe I should go there tomorrow.
There is a nice sort of somberness to northern Italy.
And the races seem to be people running? Not horses, I mean?

2026-03-02 17:16:22 UTC

- reply

Learning to code would have required a huge investment of time. There is a high opportunity cost attached to it.
Using AI, I can produce working prototypes of sophisticated software with minimal coding skills and minimal need to get into the nitty-gritty.
So far I haven't focused on making something that's scaleable or fit for production. However, I suspect that if I shifted my focus and used AI to make my code production-ready, I'd be able to do so. In fact, I may try to do this soon if I find the time.
Interestingly, even with AI and agentic coding, it's still weeks / months of work. The AI couldn't do it without me, and the time I need to spend on the project is a measure of the value I'm adding.

2026-03-01 19:03:28 UTC

- reply

I'll let you all know if I discover a proper cup of coffee in this country. Plus electrical outlets.

2026-03-01 17:09:35 UTC

Nothing against Italy's cafe culture, but the drinks are all so tiny.
Are there any laptop-friendly places where one can get large coffees, maybe even refills, and sit for a few hours?

2026-02-27 13:39:07 UTC

- reply

I think there is a definition of "asset" as something that has an "expectation of future [economic] benefit" associated with it. I kind of like this definition.
Applying it to Bitcoin, the *current* price in fiat isn't really relevant to whether its "worth owning," but the *future* price in fiat should be considered. For example, if the current price is low and the future price will be high, it's definitely worth owning.
There's a different question as to whether "price in fiat" is the most important metric here, if fiat itself is expected to lose value in the future. It may be better to use price in in terms of a bundle of goods, or CPI, or price in terms of real estate, forest land, etc.

2026-02-27 13:14:15 UTC

- reply

No quibbles about growing one's own potatoes.
With Bitcoin, there is the freedom aspect which makes it a valuable thing to support, including by investing in it and regardless of whether the investment leads to gains or losses. It's a different question whether, at any given time, an investment in Bitcoin can be expected to actually appreciate.
With gold, it sort of seems like an asset class like any other. It's valuable, but so is real estate, coal, cereal factories, fiat currencies, forest land and fashion brands.
The "no other options" bit doesn't fully convince. Is the idea that fiat currencies will lose value relative to crypto currencies? That could be, but it doesn't seem like a foregone conclusion.

2026-02-27 11:08:57 UTC

- reply

It's fine as a diagnosis, not sure about the details, but it's sort of plausible enough in a general way.
But the proposed solution isn't so convincing.
Buy bitcoin - before buying an asset for investment one ought to have a pretty firm notion that it will increase in value relative to other assets one might hold. Without denying the importance of bitcoin, I'm not sure whether that's a given.
Gold - same kind of thing.
Potatoes - I mean sure as a hobby, and it's a nice skill to have, but one can also buy them at the supermarket.
Wait out the death spiral - will there really be a death spiral, and even if there is one, until when does one have to wait and what advantage does one gain from waiting, and what does one do once it's spiraled out?
So maybe you think I'm just being obtuse and am deliberately misreading a bit of fun rhetoric, and I guess you'd be sort of right. But the point is that, behind the rhetoric, there doesn't really seem to be any real workable prescription here, or is there?

2026-02-27 09:03:03 UTC

- reply

There was some discussion with @npub13mj…8hs2 a few weeks ago about a proposal to use "verifiers," i.e. entities whose role it would be to vouch for other pubkeys. This would be done along some dimension of evaluation (e.g. "is human" / "is safe for work" / "is interesting" etc.) that can be defined and declared by each verifier. Users could then adjust their incoming filters (e.g. for replies etc.) to only permit keys that are verified by one of the verifier services the user has chosen to trust.
Another way (which I'm quite partial to) to separate wheat from chaff is to use identities that cost a few dollars. This is one of the beneficial side effects of Inkan's permanent identities - they overlay the nostr protocol with high-quality and indestructible"expensive" identities. Bots can of course also create such identities in principle, but it gets costly very quickly to do so on a large scale. At the very least, an identity whose creation costs money sends a strong signal that one might want to treat it as "serious".
Also, the permanence - i.e. the high confidence that the key pair that secures one's identity will never be compromised and one's followers will never be lost - is an incentive for the identity's owner to develop a high-quality nostr presence over time. This will result in a smaller proportion of accounts having an "ephemeral" feel and a greater proportion becoming real online personas in which people have made a real investment. In that sort of world, online identities can by default be taken seriously, reputations will be more organic, and there will be less need for technological solutions to manage visibility.

2026-02-09 16:16:48 UTC

- reply

Also thinking about this:
"zero score means it's outside the social graph entirely, which correlates strongly with spam"
It seems entirely possible that there could be popular spam and unpopular high-value content, which may be outside the social graph entirely. One could argue that this is often the case.
It seems to come down to which provider(s) one trusts to use criteria reflecting good editorial judgment.

2026-02-03 23:53:35 UTC

- reply

So from that wotathon page, I see what's wanted is a "Web of Trust ecosystem", which will be evaluated based on "functional readiness", "Depth & Innovation", "Interoperability", "Decentralizing Ecosystem Impact", "Documentation & Openness" and "Business Model Sustainability".
That leaves me about as confused as before as to what a "Web of Trust" is in the first place. I wonder how they know what they are supposed to build.
But I should be looking at NIP-85 before I further open my mouth.

2026-02-03 23:02:51 UTC

So I'm coming across this talk of a "Web of Trust".
What's the purpose of this? Is there a problem that gets solved by this? Filtering out spam in one's replies?
I can't quite tell whether it's more like a pubkey-relative follow distance concept, or more of an absolute popularity score.
Wanting to be contacted only by people who have a certain degree of "social separation" sounds like a choice someone might want to make. It's not, however, clear why this would lead to higher-quality interactions or a better experience. It's not like the friends of my friends are more interesting people than others. But I guess this should just be a decision that each user can make for themselves.
If it's more like a popularity score, it's of course legitimate to aggregate and disseminate information about what pubkeys have a lot of followers, which ones are muted, etc. But using such information to filter or prioritize whose notes one sees in one's client is another matter. You could argue that it improves the content you see, but you could equally well argue that it degrades it. It seems unfortunate if use of such scoring became a default on nostr, rather than each individual user's deliberate choice.
Maybe there's a simple technical issues that require a "Web of Trust" that I'm not attuned to. Not sure.
#wot #asknostr

2026-02-01 14:12:19 UTC

- reply

It's a key replacement system.
If you lost your private key or if it has been stolen, Inkan allows you to revoke the key and replace it with a new one.
You can also use it to rotate your keys preemptively from time to time.
This gives you a permanent online identity. It was a precondition for me to have something like that before starting to use nostr.

2026-01-31 09:54:24 UTC

How do people use NIP-46?
What remote signers do you use?
#asknostr

2026-01-28 22:46:07 UTC

- reply

I just implemented something that allows you to revoke and replace a key pair that has been lost or stolen. It also allows you to periodically rotate key pairs as a preemptive measure. I'm using it now.
I don't think there are any conceptual flaws with what I'm doing.
There may be run-of-the-mill security issues in the particular implementation as with any web technology, but it should be possible to iron these out without any special difficulties.
I'd be curious to know what the the flaws in other people's proposals are, so that I can double-check whether my system suffers from any of these.