Last Notes
Great to hear it works better. FYI, you can always check if you've got the latest version of the app by going to Settings > General > Check for updates.
I always forget what this discussion is about, and then I worry whether I need to change anything in my client, I think probably not though, oh dear oh dear.
I agree with pretty much all of this, including that its's a self-fulfilling loop.
#nevent1q…eyzk
Thanks, good to know that part is working ...
AI Search for Nostr has been live for a day now. 🧞♀
Here's the kind of thing it comes back with, more details below the screenshots 👇
https://image.nostr.build/c18f60cd4ba23a65401920bb361b784f38c41165f42503397d8403da29f88308.jpg
https://image.nostr.build/588d6eef47ac04ac01b93b8c2b6c2cb2602f77363250867b99550f49931d2198.jpg
https://image.nostr.build/9267f4938a9564508422b9d1867420cb8fae7af4e692fcc1257dbe77de990971.jpg
https://image.nostr.build/43455af0c02589ed30db66718ac178bec9b2b8e22eb270f171cb91232efc1cc5.jpg
#nevent1q…rlrz
Yes, a pop-up appeared just now and I updated.
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.
Yes, it seems to be working better, I'm not sure if I updated it correctly.
It's good that there's no chat history.
Thanks, that's a great catch! I tried to fix it, when that happens now, the model is now made aware that the value was probably the wrong kind, so it should correct course. You can go to Settings > General > Check for updates to get the new version of the app, or just do [ctrl/cmd] + shift + R.
Please feel free to keep using it, and let me know any comments or questions anytime.
It worked well; I noticed from the log that sometimes it swaps the ID for the pubkey (or vice versa), and then the message tells you that the relay didn't work. Apart from that, everything is fine.
Thanks, you should have access now.
Click on "Assay" in the nav bar and enter a search.
If you get stuck anywhere, let me know.
Please do - I'll switch it on when I get the Terms. Let me know anytime if you have any questions about anything.
There's no cost, it's free during testing (I'm covering the model fees). There's usage caps per key, with current usage indicated to each user when they are logged in. Auth is NIP-98, and you sign a kind-27235 challenge to log in. The terms acceptance itself is a kind-1 that you sign whose content is the full Terms text, which gets sent to me for my records. The signature is necessary partly because your input is forwarded to the model provider and I have to consider their own terms. If you'd like to try it, you can sign the Terms under Settings > Inkan Settings > Service Access and let me know, and I'll switch your key on.
Thanks very much for flagging this. I checked just now and the cert is valid covering both inkan.cc and www.inkan.cc, and I haven't had this report from anyone else. It's likely something between your phone and the site. You may want to try in your regular browser and see if that fixes it. If it doesn't, please let me know.
"the initial step is really hard"
That's why I created the "Toy Identity" option on the Inkan home page. People can create a throwaway identity in a few minutes and play around with it. If they get used to it and like it, they may at some point get around to creating a real airgapped identity.
I'll take a closer look at the Foundation devices, they look very attractive.
Quick announcement:
AI Search is now live on Inkan. The Assay page lets you search and discuss Nostr content with an AI model. 🧞♀
If you'd like to try it, you'll first need to review and sign the most recent Terms of Use, which you can do under Settings > Inkan Settings > Service Access.
If you're a current inkan user, I'll switch on your access to AI Search after I receive the updated Terms of Use.
FYI, this allows you to say "these 10 keys are all me." 👇
#nevent1q…x0vp
Are you maybe looking for this? 👇
#nevent1q…x0vp
me i built one >) https://gitworkshop.dev/
[email protected]/relay.ngit.dev/nostr-notify
testing new page and logo
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 *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.
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?
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?
something is messing with the ui @npub16xn…6z6l https://image.nostr.build/d0456970154c567f4782b5d42ca91ea624d8b09498ab59389f4583eaef633b6c.jpg
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 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 "Ai Engineers" :copy_812bf741_ab2f_40ad_abf9_188:
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 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 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
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 at hand that jev doesn't require?
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 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.)
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?
I think it's difficult to do without a blockchain.
With a retrospective disavowal, you have to trust that what they are telling you is true, i.e. that their key was really compromised.
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.
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.
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:
"it's cryptographically identifiable"
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 *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.
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.