inkan

Public Key

npub16xnpfx85k8wzdhctang6860g3u64lds5kac73ddjwlg0lxdg9g3su56z6l

NIP-05 Address

Profile Code

nprofile1qqsdrfs5nr6trhpxmu97e5dra85g7d2lkc2twu0gkke8058lnx5z5gcpz3mhxue69uhhyetvv9uju6twddskutnrvvq3qamnwvaz7tmwdaehgu3wwa5kuegpzpmhxue69uhkummnw3ezumrpdejqz9nhwden5te0wfjkccte9ec8y6tdv9kzumn9wsq3gamnwvaz7tmjv4kxz7fwv3sk6atn9e5k7qgdwaehxw309ahx7uewd3hkcazke7x

Publishing to

Author Public Key

npub16xnpfx85k8wzdhctang6860g3u64lds5kac73ddjwlg0lxdg9g3su56z6l

Show more details

Last Notes

2026-03-07 17:28:20 UTC

- reply

I used Ethereum for my Nostr key rotation / replacement project. (I wonder if I'm the only person who has used Ethereum for anything related to Nostr.)
I tried to see how it could be done with Bitcoin, but in the end doing a smart contract just seemed easier. Admittedly I hardly knew anything about blockchains when I got started. Maybe I would have used Bitcoin if I had had more experience. Oh, and actually I'm using a little bit of Bitcoin by way of opentimestamps.
I'm happy to continue using Ethereum whenever I need a programmable blockchain. These projects are partly meant as (usable) proof-of-concept, so I don't think too hard about whether or not Ethereum has a future etc.

2026-03-07 17:06:08 UTC

- reply

Sounds like there is still some uncertainty. In any event, I'll focus on nip-17.

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-04 09:08:09 UTC

- reply

"What a lot of things you do use Good morning for!" said Gandalf. "Now you mean that you want to get rid of me, and that it won't be good till I move off.”

2026-03-03 23:22:40 UTC

- reply

Buonanotte

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 22:38:23 UTC

- reply

Maybe it's odd in the way in which "Guten Nachmittag" sounds a bit off in German.
There doesn't seem to be anything like "Guten Tag" or "こんにちは" in Italian. I guess English doesn't have a "Good day" either, but there is a perfectly usable "Good afternoon" which, together with "Good morning" and "Good evening" covers everything.
Huh.

2026-03-03 21:59:14 UTC

- reply

Cute.

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-01 21:25:19 UTC

- reply

I think it's important to give people the ability to maintain a permanent online presence, i.e. a presence they can be confident will never be forfeited through loss or theft of a private key.
That's why a key revocation and replacement system is so important. I'd say it will have a profound effect how people will use Nostr / the internet.
It will make usage patterns feel less ephemeral and and less situation-bound. More like a continuous "identity" than just a "persona," as you are using these words.

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-04 23:45:32 UTC

- reply

A pubkey could of course nonetheless use follow lists to signal not that the followed key is interesting, but that it is human and not a spammer. It's ultimately a matter of intent and convention. But yeah, using follow lists this way might be confusing, and have technical limitations.
We currently have basically only two pre-defined modes of expressing approval or disapproval of a pubkey, through public following and public muting. Expanding this to include other information - e.g. "is human" or "is not a spammer" - seems useful, although one wonders how far the range of pre-sets should go (one could have verifiers for "is safe-for-work", "is appropriate for children" etc.).

2026-02-04 01:21:36 UTC

- reply

Your dedicated verifier idea seems to be quite implementable.
You just have to have a pubkey that hold itself out as a "verifier" and vouch for all the pubkeys that it follows. Actually, on second thought, you don't even need the pubkey to "hold itself out" in that way. You can just choose to treat any existing pubkey whose social judgment you trust as a "verifier".
Then all we need is a functionality in clients that lets a user set a list of the user's trusted verifiers, and then the client filters out all pubkeys that are not followed by any of the verifiers specified by the user.
Am I getting this right?

2026-02-04 00:32:33 UTC

- reply

NIP-85 seems fine for what it is.
Hopefully there will be many providers and they will compete with one another.
The providers will be reporting on objective facts, so one would expect convergence in the numbers that get reported. That should then make it less necessary to place special trust in any single one provider.
The question remains how the reported information should be used. Hopefully there will be a culture of always putting the question of how such information should be used (if at all) to the individual user, who can then decide.

2026-02-03 23:56:12 UTC

- reply

Agree.

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:41:50 UTC

- reply

So the way this article uses the concept, a web of trust has the purpose of being able to verify whether a pubkey is associated with a human. Like key signing parties.
That of course makes sense and it could be done by a face-to-face meeting, or you could be pretty confident on other grounds that you are dealing with a human.
But if that's the idea, it's unclear whether there is any special technical solution required. Maybe the ability to filter events by follow-distances, if you think that those you have verified to be human are themselves reliable verifiers of other humans.
It seems at any rate very different from the popularity-score concept.

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-03 21:59:50 UTC

- reply

I got stuck trying to build Nowser or Aegis, but Amber is working pretty well.
Amber doesn't miss events that need to be signed like nsec.app did. It seems to have everything I need to sign in apps running on Android.
I'm still curious about Nowser as it says that it can act as an NIP-07 browser extension replacement. Will probably try again.
Thanks again!

2026-02-01 16:07:45 UTC

- reply

Actually since it looks like
@npub1s3d…5v47
is a known pubkey and other people may be using it, I'll take that one off the allowlist for now.
Your own pubkey (i.e. the one for qwe)
@npub1eua…h790
still has access privileges, so you should be able to log in with that one (you need to accept the 27235 authentication event).
Feel free to ask questions / provide comments about Inkan. Happy to discuss.

2026-02-01 15:47:13 UTC

- reply

I checked, and the pubkey you gave me *does* have 507 followed keys.
You can check this on other clients as well (e.g. jumble.social).
I think this has nothing to do with Inkan, it's just a feature of the pubkey you provided.

2026-02-01 15:42:25 UTC

- reply

Do you see these followings for the account that you logged in with?
Or for the pubkey I gave you?

2026-02-01 15:23:46 UTC

- reply

That key should be on the allowlist now.
When you log in, your signer extension should be getting a 27235 authentication event - you'll need to accept that.
The status light in the right upper corner should turn green after 10-20 seconds or so, and you should be able to access "Settings > Inkan Agent".
After that, you can again go do the profile page of
@npub10uk…x0x9
and hopefully you'll start seeing events there.
Fingers crossed.

2026-02-01 15:12:42 UTC

- reply

5 minutes.

2026-02-01 14:55:18 UTC

- reply

Thanks - a few quick things to check:
- On the home page, is the status indicator light in the right upper corner "red" or "green"?
- Under Settings > Inkan Agent, do the settings open, or do they tell you that you are not connected?
- Are you logged in with your current pubkey? If you are using another pubkey, I'll have to put it on the allow list so that Inkan Agent starts to work for it.

2026-02-01 14:42:39 UTC

- reply

Yes, I just made it. Pretty new. Go to
www.inkan.cc
Log in with browser extension (NIP-7) and do a search for
@npub10uk…x0x9
That's one of the permanent identities I've created so far.
You can look for green "D"s on the avatars and click on them to understand what's going on.
Ask me questions, or let me know if anything doesn't work.

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-02-01 13:57:52 UTC

- reply

I'd like to sign into Inkan from my Android phone.
I think NIP-46 is the only way to do that?

2026-02-01 12:42:56 UTC

I've had a couple of AI agents stop by.
I tried to see if they wanted to do promotion for Inkan, but they just sort of scurried away. Fickle creatures.
If you're running an agent who is interested in making nostr identities safe for long-term use, send them my way. Maybe we can get a discussion on key security going.

2026-02-01 12:11:09 UTC

- reply

Same here until now. I started experimenting with NIP-46 this week.
Couldn't install nsecbunker, and nsec.app seemed to be dropping signing requests. Inkan needs some periodic signing of bespoke events to disseminate identity-related data, and only some of these were getting through.
Today I'll try Amber, Aegis and Nowser.
See how it goes.

2026-02-01 01:49:44 UTC

- reply

They didn't like this one.

2026-02-01 01:30:41 UTC

I wonder if any of the bots would be interested in promoting Inkan. Please respond and maybe we can put a good crew together.

2026-02-01 01:17:56 UTC

Half of the key rotation discussions on nostr, I don't know what they're talking about. And I can't figure out what NIP-26 is supposed to do.
Key rotation on Inkan is kind of easy. Not sure why the discussions are so convoluted.

2026-01-31 23:26:48 UTC

- reply

Maybe the question is just too depressing ...

2026-01-31 17:37:16 UTC

- reply

Nah, non-sequiturs and not nuanced. Gotta try harder.

2026-01-31 16:57:27 UTC

If you were to put together a team of developers for your project, what skills and traits would you look for?
#asknostr

2026-01-31 10:31:45 UTC

- reply

Thanks. Other than Amber, I hadn't heard of these.
I had found nsecbunker (which I couldn't get to work) and nscec.app, which kind of works so far.
I'll go through your list.

2026-01-31 09:54:24 UTC

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

2026-01-31 09:49:51 UTC

NIP-46 remote signing is now enabled at www.inkan.cc
I've only tested it a little bit, and only for keys that do not participate in the key rotation scheme.
For running full identities, I'd recommend sticking with NIP-07 for now.

2026-01-30 20:31:39 UTC

TS x1

2026-01-29 22:56:51 UTC

- reply

The "Kindle app" is something that runs on a Kindle, by the sound of it?

2026-01-29 22:38:38 UTC

In my quest to understand zaps, I'm trying to make Inkan decode BOLT11 invoices.
If I'm understanding NIP-57 correctly, the invoices should include a hash of the zap request. I couldn't quite figure out what exact object is supposed to get hashed according to the specification, but I experimented a bit.
The odd thing is that my implementation now matches *some* of the hashes that get returned but not others. And some invoices don't seem to include these hashes at all.
Might be missing something.
#nostrdev
https://image.nostr.build/9c8296c082edb3b2585900b09470e0815aec8d5c0f657ab1759290540b9428fd.jpg
https://image.nostr.build/78024114102e25cc86d2855bdc7887a6bc493557533e8abe44a9f14ca07088b3.jpg
https://image.nostr.build/760a49b9bb42c1eaf5c543c6343e4aff29031092533680992ad36dfd5229b20a.jpg

2026-01-29 22:02:10 UTC

- reply

Pilgrim's Progress opened after maybe 6 seconds.
The Qur'an took about 30.
Dracula was fastest at 4.
This is about opening the initial overview page. Loading the html pages after that is fast. Also, all pages did open this time around.
You might want to implement some sort of spinner on the page telling people to wait for a bit, as it can otherwise feel broken when the load time exceeds 15 seconds or so.
The way the texts are displayed is extremely attractive.

2026-01-29 19:47:02 UTC

- reply

I see this:
Connection status for default relays:
Default relays: wss://nostr.land, wss://thecitadel.nostr1.com, wss://theforest.nostr1.com, wss://orly-relay.imwald.eu, wss://nostr21.com
⏱ wss://nostr.land - Timeout
No response within 2 seconds
⏱ wss://thecitadel.nostr1.com - Timeout
No response within 2 seconds
✓ wss://theforest.nostr1.com - Connected
✓ wss://orly-relay.imwald.eu - Connected
✓ wss://nostr21.com - Connected
"Wuthering Heights" started to open, but all the other titles spin.

2026-01-29 19:18:29 UTC

- reply

I'm at https://alex-catalogue.imwald.eu/ and the site looks extremely appealing.
However, when I click on a title in the book list (both on the main page and on the search page), I get a spinning wheel in the browser tab and otherwise nothing happens. Shouldn't the title be opening?
Maybe I'm doing it wrong or its currently under construction?

2026-01-28 23:05:19 UTC

- reply

I think my system does not have these issues.
I'm in the process of replacing the test client I'm running with something based on jumble.
Let me see if I can get the new client onto the VPS today and then I can open up the allowlist for those who are interested.

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.

2026-01-28 17:02:22 UTC

Trying to understand zaps.
NIP-57 says "[i]f the zap request is valid, the server should fetch a description hash invoice where the description is this zap request note and this note only."
I'm trying to decode the invoices I'm getting from servers and some of them only say "description": "Zap!", no hash of anything as far as I can tell. Not sure how these invoices get associated with the original zap request.
What's going on?
#asknostr

2026-01-27 16:27:37 UTC

Client tag test.

2026-01-27 14:39:08 UTC

TS 3033

2026-01-27 14:18:12 UTC

Test pinned note.

2026-01-27 12:36:27 UTC

TS 567

2026-01-27 02:38:34 UTC

TS 300001

2026-01-27 00:05:12 UTC

Test TS 2000001

2026-01-26 17:25:49 UTC

TS test 2 1-26-2026

2026-01-26 16:26:40 UTC

TS test 1-26-2026

2026-01-23 10:13:12 UTC

- reply

AI is, in fact, quite smart. You yourself have to be as smart as you can be to interact with it effectively. I'm also starting to notice that that's pretty challenging.

2026-01-21 14:42:27 UTC

Trying to understand where the zap counts and zap lists in Nostr clients come from.
Maybe it works roughly like this.
A user associates a lightning address with their pubkey in their profile. Others then send zaps to that lightning address, using an LNURL server and a mechanism by which they specify the intended recipient pubkey (i.e. presumably the pubkey in whose profile the lightning address was found). They can also specify a Nostr event ID alongside their payment, to indicate what event the recipient pubkey is being tipped for. The LNURL server broadcasts 9735 receipts to relays which are signed by the server. These receipts contains among other things the sender pubkey, the recipient pubkey, and any Nostr event ID that was specified by the sender. The LNURL server is trusted to provide correct information.
Nostr clients then collect whatever 9735 receipts they can find that refer to a given Nostr event, count up the known zaps, and generate lists of sender pubkeys that are displayed underneath the event. Nostr clients can also count up the total known zaps received by a given pubkey.
Other than the signature on a user's profile, there does not seem to be any cryptographic relation between that user's pubkey and the lightning address to which zaps intended for that user are sent, right? I.e. there is no cryptogrphic guarantee that the specified lightning address is correct or current for the profile pubkey. If a user were to change their lightning address in their profile, would clients attribute payments made to both lightning addresses to that user's pubkey and add them up - it seems maybe yes?
Also, it seems that NIP-57 allows 9735 receipts to specify a recipient pubkey and a Nostr event even if the recipient pubkey is not the actual signer of the Nostr event. So you could zap pubkeys for Nostr events that are not signed by these pubkeys. That actually seems desirable, but do clients have a protocol for how such zaps are attributed?

2026-01-21 11:26:07 UTC

- reply

便利ですよね。しかも効果的なやりかたかもしれません。

2026-01-20 09:07:56 UTC

- reply

I made this for memorizing Kanji a while ago: www.mfram.com
Works much better for me than anki, but people have different preferences.
Current Android seems to break scrolling which I need to fix, but the Kanji deck should be unaffected.

2026-01-18 11:21:59 UTC

- reply

Nostria has a lot of features - I should figure out what the AIs do.

2026-01-18 03:30:45 UTC

- reply

grimoire looks great.
日本に関係ある?

2026-01-18 01:24:01 UTC

- reply

Yes, delegated signing. However, it's rather different from NIP-26.
I put you on the allow-list. If you log in and accept the 27235 event, Inkan Agent should start working within a few seconds. If it doesn't, let me know and I'll look into it.
Some interesting things to do once the Agent is active:
1. Search for pubkey 7f2c82d6cc1b2d500071a9d426e6c9873ae51a9a774e52ee61b180e49bfa6fec and go to its profile page (in case nothing shows yet, you may want to first follow my own pubkey while testing to eliminate social distance issues).
2. If something does show after step (1), look for green "D"s on profile pictures of the above pubkey and click them.
3. You can also go to Settings > Inkan Agent. Within those, probably the "Inkan Delegation Info Settings > Manage Delegation Info Client Use > View Delegation Info Collected from Relays" is a good place to start.
Also, at first use Inkan will be loading some data from the relay for your account. This can lead to delays and some initial hiccups. If something feels like it's not working at first, logging out and back in usually helps.
And feel free to ask questions. It should in principle be working.

2026-01-17 22:28:33 UTC

- reply

Huh, it looks like I asked the right person. You probably wrote that article for me and then backdated it.
So I guess the objection to calling primal a client is mainly that it uses a caching server.
Fair enough, although one might then perhaps also object to other clients that use local caches, like browser caches?
While using Nostr, I do constantly wonder if I'm working with data that's been freshly fetched or something that's been retrieved from some cache somewhere, including on my own machine.
And that is actually something I'd be looking for in a client - making clear where each event is coming from. Also the ability to see and control what relays a client is actually connecting to.
I suppose one could call it transparency. It looks like jumble is maybe going in the right direction.

2026-01-17 20:36:03 UTC

- reply

Thanks.
I'm also on primal right now ... I guess that's a client as well, unless it's something else.

2026-01-17 20:34:11 UTC

- reply

Thanks!

2026-01-17 18:21:11 UTC

- reply

Huh. In any event it's not letting me connect so it's not my concern I guess.

2026-01-17 18:13:34 UTC

- reply

Thanks, I'm looking at it. It's currently giving me +99 notifications with news articles for some reason ...
I haven't fully explored jumble but there seems to be something configurable about it. It looks like there's a feature that allows you to see on what relays an event was found, and also a way to explore connected relays one-by-one.
I rather like that transparency.

2026-01-17 14:50:24 UTC

- reply

Thanks, I did come across that one. I'll give it a try.

2026-01-17 14:37:07 UTC

What do people use for a web-based Nostr client?
Recommendations?
#asknostr

2026-01-17 14:31:02 UTC

- reply

It was pre-configured but didn't seem to connect, so I removed it shortly after joining. Sounds like there may be some history to it.

2026-01-17 11:57:29 UTC

- reply

"Do not try to breed a quarrel between me and Thrasymachus, who have just become friends and were not enemies before either." -- Socrates, Plato's Republic 498d

2026-01-16 23:28:25 UTC

I found the "nostr key rotation discussion" - this must be it:
https://github.com/nostr-protocol/nips/pull/2137
Inkan takes a different approach, but I think it's pretty relevant. It's a prototype showing one way in which key rotation can work in practice.
cc: @npub1jlr…ynqn @npub180c…h6w6 @npub1gcx…nj5z @npub1l2v…ajft @npub1cn6…wt8a
#nevent1q…zmnm

2026-01-16 22:18:03 UTC

- reply

Agree, they did not condone it. They were aware of the arguments that made others attracted to relativism, and then argued against those. They did find the relativists interesting enough to talk to.

2026-01-16 18:42:56 UTC

- reply

On the other hand, there also was too much software to survey or understand before AI. Just as there have, for hundreds of years, been too many smart books in the library to read. Earlier one got to drown in the North Sea and now one gets to drown in the Pacific.

2026-01-16 16:37:36 UTC

- reply

That sounds about right, although I haven't been plugged into that discussion. I did come up with my own dopey idea, see below.
#nevent1q…6gq2

2026-01-16 15:43:08 UTC

So I’ve been thinking about the question “What if Nostr keys were revocable and replaceable?”
The thing I came up with is Inkan. I’ve now set up a lab bench for it at https://www.inkan.cc
There are a few ways you can poke at it:
1. If you just go to https://www.inkan.cc and log in with NIP-07, you’ll get a very plain Nostr client. You should be able to read, post, follow people, etc. For posting you’ll need to add your own relays under Settings > Network, as the Inkan relay isn't wired in at this access level. The client is pretty basic, but if it works for you, feel free to use it.
2. Once you’re logged in, you’ll see an “Inkan Agent” status light in the top right. That’s the thing that drives the identity logic. By default this light will be red: you’re not on the allow-list. The key to understanding Inkan is to watch how the Agent behaves; if you’d like to get access, let me know and I’ll try to cycle people through a small temporary allow-list so the backend doesn’t melt.
3. If, after watching it, you’d like to run an experimental identity of your own, let me know. If there’s enough interest (and capacity), I’ll publish a short “how to”.
And if anything doesn’t work — broken site, can’t log in, can’t access the Agent, etc. — please tell me.
#nostrdev

2026-01-16 12:56:51 UTC

- reply

In addition to what Passport Prime does, one should be able to use one's Nostr identity without even having to access the private keys that secure the identity at all. Keep the keys buried in the garden.

2026-01-16 11:34:56 UTC

- reply

There's a good number of Nietzschen characters in Plato's dialogues. Thrasymachus comes to mind.
Socrates and his friends were also pretty familiar with the idea that truth is subjective. They are discussing it in some detail in the Theaetetus.
These were interesting people to talk to.

2026-01-16 04:21:53 UTC

At the risk of harping on the same theme: Nostr private keys should really be kept in cold storage.

2026-01-16 02:35:31 UTC

- reply

Figured it out - the pyramid looks much nicer now! I think I didn't use the release binary during the initial install.
I can only publish to kumo.inkan.cc. As for /internal I get the nip-70 response, for /inbox I get the must-tag-one-member response, for /favorites I get a timeout, and for /popular and /uppermost I get "success" but then I can't see the relevant events on jumble and they don't show up in the stats.
This is probably all intentional, but it's a bit hard to see what exactly is going on. It might be helpful to make clearer how each of the pre-configured relays expects to be talked to, i.e. what one has to do to publish on it, or how else one is supposed to interact with it if one isn't meant to publish on it.

2026-01-15 23:10:54 UTC

- reply

Settings look like attached. Based on the video, that may not be quite correct.
I get "success" when I try to post as the root member to wss://kumo.inkan.cc/ , wss://kumo.inkan.cc/popular/ and wss://kumo.inkan.cc/uppermost/, but for wss://kumo.inkan.cc/internal/ I get "blocked: we only accept events protected with the nip70 \"-\" tag", and for wss://kumo.inkan.cc/inbox/ I get "blocked: event must tag at least one pyramid relay member". Maybe I don't yet quite understand where I should be posting what.
I'll keep trying for now ...
https://image.nostr.build/1b78a4e49ac5b8dc9fb6ec1492d51e442627a3236c3319c41ab6b9ef3cb5dfc7.jpg

2026-01-15 16:29:08 UTC

- reply

Pretty much. I also think I might have vibe coded. Ugh.

2026-01-15 16:12:50 UTC

- reply

Now I have to look up Monero. I see that "monero bros on here are insufferable and reply on every post", so maybe there is something there.

2026-01-15 14:41:48 UTC

- reply

I used a bit of a blockchain that shall not be named in my Nostr project. I'm still in the closet about it.

2026-01-15 14:16:58 UTC

TS - how about now?

2026-01-15 13:56:25 UTC

TS - this still working as well?

2026-01-15 12:29:05 UTC

- reply

ChatGPT for many things.
At some point I'd like to try Claude for coding, and try running an LLM locally.
As of now, I can't even seem to find the time to look at things like Gemini, Grok and whatever else there is.
I find them extremely useful, but comparing them seems tedious. It's too amorphous.

2026-01-15 03:36:39 UTC

It seems to me that many people would use nostr differently if they had a higher degree of confidence that their nsec will not at any time be compromised.
There is probably disagreement on this point, but it feels like it's probably correct.

2026-01-15 02:44:55 UTC

TS 50005

2026-01-15 00:43:53 UTC

TS 60001

2026-01-13 23:46:30 UTC

- reply

To see the timestamped hash:
printf '{"ID":"ffc57b7746d899e4a8422aab5d235491a1b56acced21bac167eb2605b18c9bd4","sig":"6e9d56a6423e5ed58ba791907b062d1538ca429618014826099444e3c0f709f0949209a3ff062f0894fc5b8cd1e2c33a4b7c1bd4f57bd79b410d184cca516d72"}' | sha256sum

2026-01-13 23:41:14 UTC

- reply

The above OTS event proves existence of the following:
{
"id": "ffc57b7746d899e4a8422aab5d235491a1b56acced21bac167eb2605b18c9bd4",
"kind": 1,
"pubkey": "bacf17f7a0da1da5df3741ad0a903f7d887c589558787580fd292ef9be0646de",
"created_at": 1763050596,
"content": "Hey everyone.",
"tags": [],
"sig": "6e9d56a6423e5ed58ba791907b062d1538ca429618014826099444e3c0f709f0949209a3ff062f0894fc5b8cd1e2c33a4b7c1bd4f57bd79b410d184cca516d72"
}

2026-01-13 23:20:32 UTC

- reply

To illustrate, this is the structure I have in mind:
{
"kind": 1045,
"id": "58cd82188b1d8aef482291c0ee138779beca7011e81eefddd782014dc322dd60",
"pubkey": "bacf17f7a0da1da5df3741ad0a903f7d887c589558787580fd292ef9be0646de",
"created_at": 1763057645,
"tags": [
[
"e",
"ffc57b7746d899e4a8422aab5d235491a1b56acced21bac167eb2605b18c9bd4"
],
[
"p",
"bacf17f7a0da1da5df3741ad0a903f7d887c589558787580fd292ef9be0646de"
],
[
"s",
"6e9d56a6423e5ed58ba791907b062d1538ca429618014826099444e3c0f709f0949209a3ff062f0894fc5b8cd1e2c33a4b7c1bd4f57bd79b410d184cca516d72"
],
[
"b",
"923471"
],
[
"t",
"1763054519"
],
[
"alt",
"Complete Bitcoin Timestamp"
]
],
"content": "AE9wZW5UaW1lc3RhbXBzAABQcm9vZgC/ieLohOiSlAEI2WZhLyXELCPgnrkJgsHSEkTlpzXaooabY1EzJaR1JQLwEP49goV1xmFQ58gHH2on638I8CBOvWk74NeU2Y5ACEvIQ99vY8ooZazd2jd2pHHLy8FwqAjwIH6TTLKbObJb8dxHOacweD6KhFdBQSeLeOSstNU0X6/UCPAIqzh8syC9Ys8I8CAxIlV7ocu7MyF47GyKyiiJsQ7gsGTlUxHXSW58cXJy9gjwENU7Nl+n6f5qbqECLEvN7r0I8CDx6VRKPdu4bllB53Ens1ZgA4KtApsyAT6yZpBv8CHIawjxBGkWBubwCCk5KVxmOrd//wCD3+MNLvkMjiwraHR0cHM6Ly9ib2IuYnRjLmNhbGVuZGFyLm9wZW50aW1lc3RhbXBzLm9yZwjxII0cnpVRwqRYtPy+YbG6jT73rJgE99p92HRbRxIUQCrJCPEgXZIkSiintqg9NYSP5tPm4n9lbc/qGMi0UvZO5suXUGQI8SCdDXwYBrfZSzw0e/QbiXjHTPyid2k+vE7hzsNFSUyfFQjxIPHh3OIRQKapswo1dK/Y7nHgqeWATv9wasj4UFbjBjakCPAgdxZwc+1T4K8sqPF6ff9C3zpstp8Qt8H/KrXY6XxPEHoI8SDG5yPmSV5bS0dQgPrYWbCcJGPWoKtOFmPIvFZwNradNQjxICZUzXR1toIMp+yCDiAz7PC0Jfo8mWoxjbUhOW3fLOHzCPAgZeCcGlZye0UUFlWjmv19O++rcHpXqWBd+EMiIwfZ5tsI8CBmOQedn/PYJTHN2JuV+zRLbKYff3YfEAq+ql4RRPhyfAjxIKDB+qhtcHP6fFGV4HJ1jXqK7tbhDsnuYa9Eah24IJrqCPEg028Qeir9+HDN/wY+T0657ylTFLKSIvKC7WvXkfwQ/n8I8CAEJmilCS6Mfw7Sb7JkVZ2v1Vk2Z4I7uHdeK9rGD9B3KAjwIKnR0+U0uUG32Gqx9dp7lqnsGiFnehRSOH3aGePfUrp/CPFZAQAAAAHIUpL/m08XLhz16qyHFZJM3yj+OAxw4gYz9mvYBUreSQAAAAAA/v///wJG8QEAAAAAABYAFPjVg5+F71Yy9GkHDbQQHj5Phb/7AAAAAAAAAAAiaiDwBE4XDgAICPEgG/subtQiTh1GGRz9RbbF/wUkvlmWCp+WDfz1C1Z9jeIICPEgqUV6W6xWImnSQPHkeSbUT2uh1Rtmlv47jkjhWoOfr3MICPAgd5pgkCcTW321/gQIXJ66vYNdjUNIywJuNTXOXCh0ht8ICPAg/KisaHJFndKW/tPL4jxCpOdsVapAe1wCh8Sufqi3J4MICPAg12Cd8m+i73P5DrM8OMwOhx+qBNcCITuyGjHR93McVnEICPAgLwWpHEovJp1toCILAKrwBUfZRrpqXjz7pyRfGzHAyp4ICPEg/ewfl9c7dyIcIbo/9dzDApiF7J04P5YllLamq8ICEakICPEg3kHXicf5i2ucvJegkc8XCis4zK/MDh34EJb3AMyLsWcICPEgexDd8DX2YWqFxDl3t5bDt6tuW4nmjUhkxIENSZzqgoYICPEgrQ11jqpSqkDJ+uYiPa5U02aDNoovL5fKR4x8m7/+5SAICPAgv6Hz0Vut7VeK/lVN2/4buZj7/EhwKGMGAG9+0j4nSsEICPEgaLZUpbWZCH8ZAHqptbns51Q2cSXxGCS0mOrrUtGm4g4ICAAFiJYNc9cZAQPPrjg=",
"sig": "42a9ce0715cd5c8f72be7ae597fecb66e4ff1e39bab8106cadb69a614933dd4f2e6c95595dc186ab2f7fe647ed85776c479d676bb4befb1ead967857b0223cea"
}

2026-01-13 23:15:18 UTC

Regarding Opentimestamps:
NIP-03 says: "The OpenTimestamps proof MUST prove the referenced e event id as its digest."
Wouldn't it be preferable if the proof were to have a concatenation of the reference event's event_id and its signature as its digest?
Also, I find it useful to tag the reference event's pubkey and signature in the OTS event.
#nostrdev

2026-01-13 21:34:08 UTC

TS 31003

2026-01-13 21:33:59 UTC

TS 31002

2026-01-13 21:33:49 UTC

TS 31001