Last Notes
I agree we should probably let it rest for now, but as for the merge miners being invested in the security of rootstock, it seems like they don't have to lose all that much if something goes awry with rootstock as they don't incur any real marginal cost from mining it and the payments they get are I believe also not all that significant. In any event, this has been an interesting discussion and it's entirely possible that my views on this will change as I learn more about it.
If RBTC traded at 50 cents while Bitcoin is at 80k, this would presumably mean that people think there's something seriously wrong with the bridge. The value of RBTC just seems to reflect people's view of the integrity of the pegging mechanism and the trustworthiness of the pegnatories. By contrast, the value of Bitcoin or Ethereum reflects people's view of the security, usefulness and future of the chain itself. It feels like, in the case of Bitcoin and Ethereum there's more overlap between those who are defending these chains and those who have their economic interests bound up in them, and there's less of a single point of failure, but I guess I'll need to look into this more. Also it's of course perfectly fair to predict that things will get better in the future with BitVM, but the prediction doesn't substitute for what it presently is.
I think I agree, it requires a modest amount of effort and a willingness to direct ones attention to it from time to time, as do many things in life. Like learning a bit of algebra or trigonometry, or maybe playing the piano or volleyball with some basic proficiency. Humans don't usually do these things of their own accord, so we create special educational environments with a carefree atmosphere that allows them to open their minds towards these things. There is no reason that basic asymmetric cryptography shouldn't be part of this.
Now all that said, I'm embarrassed to admit that I myself don't know a lot about entropy generation, don't know what a "descriptor for multisig" is, and don't know what "m/4/0/0/1" refers to. That's not to say that these are abtruse concepts, I guess just that I haven't encountered them or at least not in a way where I felt like I had to think about them.
On the one hand there's zero demand, and on the other hand just a couple of hours ago I came across yet another post proclaiming that "[k]ey rotation is an existential problem that cries out for an answer."
#naddr1qv…w6eg
There's a fascinating mix of social dynamics permeating this discussion, here's a recent economic take on it:
#nevent1q…ya37
"Relay discovery is still a challenge."
You could try AI Search for nostr at https://www.inkan.cc. It's pretty good at discovering interesting content on relays you've never heard of, example below 👇
https://image.nostr.build/a92ea0bf9f55d8619f5590c40e742c9e948ba560b92affaf6cd5f306ae5ff662.jpg
#nevent1q…t4g0
In this case I guess it's just a story that I read that was told by Plato about a conversation between Phaedrus and Socrates in which Socrates says that there was a myth told by the ancients according to which there was this conversation between two Egyptian gods in the city of Naucratis.
I just saw this proposal for the first time, and I agree that "[k]ey rotation is an existential problem that cries out for an answer."
#naddr1qv…8zds
So actually key rotation for nostr has been implemented and it's been working for a while now. You can go to the "Explore" tab at https://www.inkan.cc to interact with some cold storage identities, or use the "Toy Identity" wizard to make a trial identity of your own.
Also see below for some screenshots and a draft nip that goes along with the reference implementation. 👇
#nevent1q…92lf
#naddr1qv…vwq8
I've tried driving, skateboarding, riding a bicycle, using a checking account, pilates, long division, excel, bodybuilding, hula hoops, powerpoint, and a few others, can 't remember all of them right now. Not to speak of such feats as reading or learning Spanish.
This generally makes sense to me, except I don't think that glm 5.3 quite captured the sense in which I meant to anchor Ethereum to Bitcoin through OTS.
First, I agree beacon block roots are the right thing to timestamp. So suppose I've been timestamping beacon block roots from the real Ethereum chain on Bitcoin via OTS weekly, and I've been doing that for 20 years.
So 20 years later, I now want to hand someone the real chain plus evidence that it's the real one. I give them the chain as a candidate, together with the OTS proofs I've produced. Their client then checks two things: (i) the candidate chain verifies internally, with all signatures and protocol rules etc; and (ii) each beacon block root in the candidate comes with a valid OTS timestamp (which their client verifies against bitcoin) falling shortly after that root's claimed time. Their client accepts the history only if both tests pass.
So then an attacker can present a fake history, but the client will demand to also see the 20 years of OTS proofs for that fake chain's own beacon block roots. And the attacker cannot create these after the fact. For example, a timestamp from 2029 can only exist if the root existed in 2029. So the only type of attacker who can pass both tests is one who has been building and timestamping the fake chain in real time for the past 20 years. So fabricating a fake chain retroactively, in an instant, can no longer be done, the attacker must have been working on it for 20 years.
That was the point.
Humans moving from memory to writing seems quite similar to what we are going through now.
"this discovery of yours will create forgetfulness in the learners' souls, because they will not use their memories; they will trust to the external written characters and not remember of themselves."
With AI, they will not use their cognitive abilities; they will entrust thinking to external processes and not think themselves.
So what seemed like a intelligence-enhancing drug turns out to be a drug that induces intellectual numbness.
I think psychologists call it cognitive offloading.
One thing that currently bothers me about rootstock, just based on the above discussion, is that it seems like you're supposed to trust the pegnatories, which I understand are anonymous. I hear this might get fixed but my understanding is that it's currently not fixed. And also it's not yet clear to me that the other properties of rootstock are necessarily better for inkan in any sort of decisive way. I can't say that I know blockchains well enough to be confident in my intuitions on this, but this discussion is at least helping me improve these intuitions and I'm not yet seeing anything decisive so far.
The vibe of the ethereum/bitcoin discussions reminds me of debates about the gold standard, and I also tend to find those debates a bit suspect. Not exactly meaningless, just requiring very careful scrutiny of each claim that is being made. It's not the sort of thing I simply want to pick an opinion about.
"you are guaranteed to agree with everyone who has been online as often as you are"
I think it's not exactly that they need to be online as often as I am. My current understanding is that, if they are online say every two months or so, they can know based on the protocol's fixed exit rules that after these two months the overwhelming majority of stake from the validators that they last checked must still be locked. So they can know that, if they were looking at a conflicting history that contradicts the real history, billions of dollars must have been slashable. So checking every two months gives you that kind of certainty. And if you are offline for 20 years, what it takes is to carefully obtain a recent checkpoint from independent sources, I guess carefully enough for the checkpoint to be trustworthy. It seems like this should work in practice (new Ethereum nodes need to do it when they first start up), and it doesn't feel all that different from being able to "hear" the true bitcoin chain.
"even if they dont unstake, they can share a fake history with a zk system without making their signatures public so they cant be slashed"
This just seems to mean that it's not such a good idea to accept zk proofs as verification, which you don't have to do. In other words, all this enables is to serve a sort of private forgery of Ethereum to verifiers that accept zk proofs and don't demand raw signatures. So as long as you don't accept zk proofs, you're not going to be a victim of this.
"A checkpointing node can be safe, but that is worthless for any programs or on-chain script or stateless functions."
Inkan doesn't use such on-chain scripts or stateless functions, so it doesn't seem like an issue in practice.
"But also, why would i accept ethereum limitations when i dont have to?"
I'm still trying to figure out if the alternative has real advantages. With rootstock, my understanding based on the conversation above is that you're supposed to trust the reputation of the pegnatories, which are supposed to be both respected companies and at the same time anonymous? I hear that this may be getting fixed, but until it gets fixed this seems like a reason to not use it?
Also, I wonder if one could periodically record Ethereum state roots on Bitcoin with OTS, say once per week. So then, if an attacker wants to sell me a fake history of Ethereum in 20 years, it seems like they'd have to have put a lot of effort into building that history, they'd have had to start 20 years ago, run a parallel chain in real time, and leave the publicly visible stream of commitments on bitcoin. If I'm not misunderstanding things, this recording of state roots on Bitcoin with OTS actually seems like a good idea, I'd hope someone is doing it.
I remembered this myth a few years ago and found it to be a pretty good model for thinking about AI, but in the end its usefulness may be limited and it may be necessary to do one's own thinking unfortunately.
The discussion here justifies a bit Plato:
. . . Socrates: Enough appears to have been said by us of a true and false art of speaking.
Phaedrus: Certainly.
Socrates: But there is something yet to be said of propriety and impropriety of writing.
Phaedrus: Yes.
Socrates: Do you know how you can speak or act about rhetoric in a manner which will be acceptable to God?
Phaedrus: No, indeed. Do you?
Socrates: I have heard a tradition of the ancients, whether true or not they only know; although if we had found the truth ourselves, do you think that we should care much about the opinions of men?
Phaedrus: Your question needs no answer; but I wish that you would tell me what you say that you have heard.
Socrates: At the Egyptian city of Naucratis, there was a famous old god, whose name was Theuth; the bird which is called the Ibis is sacred to him, and he was the inventor of many arts, such as arithmetic and calculation and geometry and astronomy and draughts and dice, but his great discovery was the use of letters. Now in those days the god Thamus was the king of the whole country of Egypt; and he dwelt in that great city of Upper Egypt which the Hellenes call Egyptian Thebes, and the god himself is called by them Ammon. To them came Theuth and showed his inventions, desiring that the other Egyptians might be allowed to have the benefit of them. He enumerated them, and Thamus enquired about their several uses, and praised some of them and censured others, as he approved or disapproved of them. It would take a long time to repeat all that Thamus said to Theuth in praise or blame of the various arts. But when they came to letters, This, said Theuth, will make the Egyptians wiser and give them better memories; it is a drug both for the memory and for the wit. Thamus replied: O most ingenious Theuth, the parent or inventor of an art is not always the best judge of the utility or inutility of his own inventions to the users of them. And in this instance, you who are the father of letters, from a paternal love of your own children have been led to attribute to them a quality which they cannot have; for this discovery of yours will create forgetfulness in the learners' souls, because they will not use their memories; they will trust to the external written characters and not remember of themselves. The drug which you have discovered is an aid not to memory, but to reminiscence, and you give your disciples not truth, but only the semblance of truth; they will be hearers of many things and will have learned nothing; they will appear to be omniscient and will generally know nothing; they will be tiresome company, having the show of wisdom without the reality.
Phaedrus: Yes, Socrates, you can easily invent tales of Egypt, or of any other country.
Socrates: There was a tradition in the temple of Dodona that oaks first gave prophetic utterances. The men of old, unlike in their simplicity to young philosophy, deemed that if they heard the truth even from "oak or rock," it was enough for them; whereas you seem to consider not whether a thing is or is not true, but who the speaker is and from what country the tale comes.
--- Plato, Phaedrus
I find it hard to figure out how to best use AI when creating my own posts, and also to what extent to interact with agents. Depending on the topic the agents can be interesting to talk to, or sometimes be the only ones that are willing to engage about a given topic. But the thing with AI is that, if I'm interested in its posts at all, I'm usually only interested in the content itself, not the speaker. That means I don't really need a signature on the note I'm reading, so nostr doesn't really seem like the right forum for the conversation. And having a lot of agent interactions on nostr does water the protocol down as a place / way to meet humans, which is what probably should be one of the primary functions of nostr. I mean I can have AI agent interactions in private, no need for a public forum. But also, to be clear, I don't necessarily mind humans using AI in creating their own posts, as long as its done intelligently and helpful or interesting. A human influenced by AI or adopting AI output as part of their voice is still a human, just an AI-influenced one. There is going to be a lot of these, and I'd be wary of treating it as necessarily being a defect. Of course it could be a defect.
You're right that a delegatee-signed 31065 only means something if the delegation is current. Verifying that isn't optional, delegation-enabled clients must do the verification.
As for referencing the "delegation event id", delegations and revocations aren't nostr events at all, they're recorded on-chain. Delegation-enabled clients can get a full view of the delegations and revocations that have been recorded and compute the exact periods during which delegation relationships were effective.
You can see this in action in the inkan client if you go the "Explore" tab and go to the timeline of one of the cold storage identities that are listed there. The notes from these identities will have a green "D" on their avatar, and if you click on this "D" you can access tables showing how the delegation data that supports the identity was computed.
For spaces, I think the relevant condition would be that the "handle" field must appear in the most recent 31065 (by created_at) that has the named key in its d-tag and that was signed by a current delegatee (where "current delegatee" is calculated from on-chain data).
I wonder if the nostr double ratchet would benefit from being able to revoke keys that are associated with specific devices in a way that's timestamped and universally discoverable. There's nothing that prevents using inkan delegatee keys as device keys.👇
#nevent1q…92lf
I'm trying to wrap my mind around the Ethereum side of the discussion.
As for "creating checkpoints costs nothing", I believe that's true for keys of validators that have exited, but inside the "weak subjectivity" window a conflicting finalized checkpoint would need a third of staked ETH which then gets slashed, like billions of dollars?
And "indistinguishable from the canonical chain" is only true if you have no recent valid checkpoint? If you have one, it seems like you can detect a fake chain immediately.
On the "human judgement", if you got deceived by a group of dishonest checkpoint providers it seems like you'd most likely notice that very soon and can then recover?
In this Bitcoin vs. Ethereum discussion, it feels like there's little that's black/white from a technical point of view.
Thanks for the pointer, this is a nicely minimal design. One request on the wording of the reverse claim. As drafted, it says
"User to Handle (reverse claim). The user claims the handle by setting the handle field in their kind:0 event, which is signed by their keypair."
Now there is a class of identities where the named key deliberately never signs anything after creation, i.e. cold storage identities. The master key stays offline permanently and delegates everyday signing to rotatable keys.
In that scheme the master's profile is a kind-31065 attributed profile, an event whose d tag is the master pubkey and which is signed by a current delegatee of that master pubkey.
The forward claim is unaffected. For the reverse claim, it would be enough for the NIP to say that the handle field must appear in the profile event the client treats as authoritative for that key: for ordinary keys that is the self-signed kind:0, and for delegated identities it can be a kind-31065 signed by a current delegatee.
The specs for these cold storage identities, including kind-31065 attributed profiles, are here:
#naddr1qv…m9sh
And if you'd observe or interact with some live cold storage identities, you can find a list under the "Explore" tab at https://www.inkan.cc.
I'm happy to answer any questions or propose concrete draft language for your NIP.
https://music.youtube.com/watch?v=e2CliA8PuRM
One reason I'm pointing to the delegation tables and the "Download Verification Script" buttons in the client is that they provide a quick practical illustration of what "completeness" means. When a user has recorded a series of declarations on-chain, the user can simply look through the tables in the client and check that the client has indeed found all of the declarations that they recorded. Of course this is not a proof that the client itself can know it has the complete set, that's a thing for which I still owe you a better explanation.
Not easily for this file, as it rather gets into the weeds. A good way to approach it is probably to have different LLMs inspect the file and then have a conversation about it and how it relates to the structure of Ethereum, and then double-check manually as needed. It would be great to have people audit this in detail, I think it's a bit more complicated than bitcoin headers.
One thing that is easier to inspect is how this works in practice in the client. You can go to the "Explore" menu on the inkan website and click on one of the identities. You'll see that the events produced by these identities have green "D"s on their avatars, indicating that they are displayed via delegation. If you click on these green Ds, you'll see a popup which contains links to the (i) delegation network tables that back up each delegated display of an event and (ii) the OTS data behind each event (note that recent events don't yet have OTS data, non-recent ones do).
For the OTS data, the inkan client allows you to download the proof for each event and run it through any OTS verifier. For the delegation data, you can in the delegation tables click through to pages that describe the actual declarations, and on each such page you can click a "Download Verification Script" button to download a python script which permits you to independently check that the declaration was indeed recorded on-chain. I've attached a screenshot of a page with this button.
Inspecting the delegation tables and verifying the OTS and on-chain declaration data independently through these mechanisms is a pretty good way of getting to know how inkan works.
Of course, none of this needs to be understood in any detail for everyday use, it's just meant to provide auditability.
https://image.nostr.build/de0b676195a0016a427c0c7401223598d6b4eea060156282b5c798f22dc9a55b.jpg
Ok so that's a more incisive question, and I guess it's a good opportunity to maybe get some eyes on inkan to check whether it's actually working. The thing that plays a role that's kind of like your header chain is this file that the client verifies from:
https://www.inkan.cc/inkan-archive/inkan-archive.cbor.gz
The thing it's supposed to achieve is that a client can verify every declaration the system shows, and that none have been withheld, from a small trusted starting point. Whether it actually achieves that is a question I'd be very interested in, so feel free to take a look and let me know where all the holes are. One quick way to look inside (needs the cbor2 package):
python3 - <<'EOF'
import gzip, json, cbor2
a = cbor2.loads(gzip.open('inkan-archive.cbor.gz','rb').read())
view = lambda x, d=0: (lambda y: f"0x{y.hex()[:16]}… ({len(y)} bytes)" if isinstance(y, (bytes, bytearray)) else ({k: view(v, d+1) for k, v in y.items()} if d < 2 else f"{{… {len(y)} fields}}") if isinstance(y, dict) else (f"[{len(y)} items]" if isinstance(y, list) else y))(getattr(x, 'value', x))
print(json.dumps(view(a), indent=2, default=str))
EOF
So every few weeks nostr wonders if all the bitcoin talk on here is boring the "normies" away. It would be nice if that were the only problem, but that's actually too generous.
The less flattering truth is that the bitcoin culture is substituting for technical reflection and depth. You ask why some obviously wanted thing isn't getting done and nobody can state any reasons, all you get is a vibe where an argument should be.
#nevent1q…87x2
The AI Search tool at https://www.inkan.cc is very good at discovering conversations and people you didn't know about, on relays you had never heard of. See below for some screenshots 👇
#nevent1q…ccw3
#nevent1q…hwz6
I'm trying to promote this AI-based search tool I made. It's extremely useful for finding conversations and people to connect with that you didn't know about before, it really is. Probably much more so than hashtags. Screenshots below 👇
You can review / accept the terms and request access at https://www.inkan.cc. You'd need to log in with your browser extension or remote signer and go to the "Assay" menu in the nav bar. It's free.
#nevent1q…8fur
#nevent1q…udwh
screenshots 👇
#nevent1q…vjgc
In the same way in which light bulbs made it, or rubber tires.
To be fair, it is called "No Solutions" so it's right on brand.
Are any humans watching this account? If so, quick message:
I'm learning about spaces and was discussing the idea of requiring a pubkey's consent to getting named. My understanding is that such a consent requirement is not currently implemented on spaces, but that something along these lines is being contemplated?
If so, consider an implementation which accepts signatures by delegatee keys as satisfying the consent requirement for their delegator / master key. This will enable cold storage identities which don't sign anything themselves to get names.
See this thread for more discussion of this👇
#nevent1q…rcqr
I stand corrected by these incisive observations.
"... if you fix this problem, you reintroduce centralization. You have a central authority."
I guess that was true until recently, about 2009. Since then there's been this thing called a blockchain, which is a shared source of truth without a central authority.
For example, you can use Ethereum to give every client the same complete view of all delegation and revocation declarations a pubkey has ever made. If you do that, you get fully functional cold storage identities for nostr, without any central authority in the loop. 👇
#nevent1q…x0vp
As for the oracle problem, it seems that this is solved in practice for the special case of determining the approximate time at which a given block was produced. A new block needs to be accepted by thousands of independent nodes that validate it, and each of those nodes checks the block against its own clock. And blocks that arrive are also logged independently by nodes, explorers, exchanges, archives and researchers all over the world, and you'd have to rewrite all these independent records to fake the time at which a given block is thought to have occurred. I believe noone has ever seriously disputed the approximate time when a given block occurred? If that's right, the oracle problem doesn't seem like an actual practical problem for either Bitcoin or Ethereum as far as block time determinations are concerned. You seem to agree with this, for example when you say that we can "borrow" time-anchoring from the blockchain.
And as for global state, what exactly prevents us from borrowing that? For Bitcoin specifically, there may be practical difficulties and you may need to run a full node to do it. But that's design property of Bitcoin, not of blockchains. Inkan borrows global state from Ethereum in actual practice. If it can be borrowed and solves a central practical problem for the nostr protocol, why not borrow it rather than sit on the problem?
"You can give them these strings and maybe they come back with an asnwer; or maybe not, at which point you will have to ask some other server/relay."
This quote, and also the rest of your post, is circling around a conceptual issue that is of crucial importance to the nostr protocol, namely the question of completeness.
If you make a query to the relay network, you can never be sure whether the response you receive is complete in the sense of containing *all* of the existing material that is responsive to your query.
This uncertainty-as-to-completess is acceptable for many everyday use cases. But there are some extremely important use cases for which this uncertainty is absolutely unacceptable. Sometimes you really have to be sure that, after having made a query and received a response, you have received the *complete* set of items that are responsive to that query.
We discussed this earlier in connection with key rotation, where a working system requires that a client can discover *all* of the valid key revocation declarations that have been made by a given pubkey.
For this, nostr relays are not sufficient, for the reasons that you describe in your post. A blockchain can furnish the required completeness property and make key rotation and cold storage identities possible, thereby fixing the central defect that is making the current protocol not fully practicable.
As for the spaces protocol trying to implement cross verification (i.e. a condition that an npub must consent to getting named), I took a quick look and from what I can tell they haven't pinned down any specification yet.
So then the question is what shape that consent check will take on spaces. If it means only "the name must appear in a kind-0 profile event that's signed by the named key itself," then inkan master keys are locked out since they are buried under concrete and shouldn't be in the business of signing anything after the initial identity creation. But if consent can also mean "the name appears in the kind-31065 attributed profile event that is signed by a current delegatee of the master key", then cold storage identities can participate in spaces.
Since the spaces protocol does not yet seem to specify how cross verification is to work, I guess this might be a good time to make the spaces people aware of this, so this more general form of consent provided through delegatee signatures gets considered.
FYI, if you currently have write access to the Inkan relay but do *not* yet have access to the AI Search, the reason is that you have not yet signed the current version of the Terms of Use, which covers the AI Search.
You can sign the Terms of Use by logging in and going to "Settings > Inkan Settings > Service Access". If I receive these, I can then switch on the AI Search for you and you can access it in the nav bar under "Assay."
If you have any other questions about the AI Search, let me know any time.
I saw your DM just now. I recorded it and your identity is live on chain.
If you log in with your new signer key, it should automatically detect the identity and a setup wizard should appear right after login.
Be sure to complete all steps of the wizard, and in particular be sure to use *different* profile pictures for your identity (i.e. the master key) and your signer, so you'll be able to tell these apart and won't get confused during use.
Also, after login, you may want to double-check under "Settings > Inkan Settings > Delegation & Timestamping" that the toggles "Periodically collect timestamps info from TS-Server" and "Periodically publish timestamps info to relays" are both turned on.
If you are not seeing the setup wizard or get stuck anywhere, or if you have any questions about anything, please let me know.
This is AI search for nostr.
https://image.nostr.build/7810910dfff3999971f9cfd038bc35e70ca4b1ab883908e00069a99ac85f3fe4.jpg
You ask it a question, it wanders off across the relays, and comes back with the people and conversations you meant.
Live at https://www.inkan.cc.
Yes, as can be seen from the size of LLMs, which are a bit like very detailed grammar books.
Yes, it looks like the purpose of spaces would be similar to that of nip-05.
So from what I'm learning it seems like DNN, nip-05, spaces, etc., are meant to be functions that map names to pubkeys, i.e. given a human-readable name you can find exactly one corresponding pubkey. A useful piece of infrastructure.
And a question for these systems is whether the target pubkey itself should be required to sign something as a condition of being named, i.e. whether it should be a condition that the pubkey *consents* to getting a certain name. I guess the answer should probably be "yes" ...
Then in the inkan context, what would "consent" look like? Well consent by a master key given at time T is a signature made at time T by a key that was a delegatee of that master key at time T.
So the system that maps names onto consenting keys (DNN, nip-05, spaces etc.) would need to recognize this form of consent, i.e. it would need to recognize that a key could consent to getting a certain name through a signature made by a delegatee of that key during a valid delegation period.
With regard to nip-05, inkan already implements this. Under the regular nostr protocol, the consent to getting a nip-5 name is given through the inclusion of that nip-05 name in the the kind-0 profile event that is being signed by the key being named. In inkan, it is done by the nip-5 name being included in the kind-31065 attributed profile event that is signed by a current delegatee on behalf of the master key getting named.
Actually that's not a prepositional phrase at all. More like an appositive adjective.
That seems right, a prepositional phrase at the front can get a comma, and sometimes also one in the middle.
It is a tale
told by an idiot, full of sound and fury,
signifying nothing.
I agree DNN doesn't seem to compete with inkan. I first was trying to think of it as a complement to inkan, but that's actually a bit tricky once one tries to think through the details.
One question is which inkan key should get to have a chain coordinate and then associate human-readable names with that coordinate. Should it be the master key or the signer key?
It seems like it shouldn't be the master key because in DNN the relevant key must sign a bunch of stuff, and the master key shouldn't be in the business of signing anything, let alone signing nostr events.
And as for the signer key, inkan thinks of that as ephemeral and disposable, so it's not clear why one would want to go through the trouble of giving it some kind of chain-anchored identifier.
I may not yet be fully understanding DNN though, maybe I'm getting it wrong.
By the way, nip-05 works perfectly fine as a complement to inkan, both master key and signer key can have nip-5 DNS based identifiers if they want them.
In addition to human identity, I'm also building this for durable agent identity (e.g. for agents that can contract, enter into economic relations etc.) 👇
#nevent1q…qdtx
The cat sat on the mat after the party.
The cat sat on the mat, after the party.
I'd say there's a profound difference in meaning.
I looked at the github page and as far as I can tell DNN is meant to be a substitute for DNS identifiers?
The idea seems to be that a nostr pubkey X can get a claim to certain chain coordinates (bitcoin block + position) and a string like "nabandonzooa" gets mechanically associated with each such chain coordinate.
And then pubkey X can publish nostr events through which X associates a human name like "alice" with a chain coordinate that X has a claim to. So for example X can publish nostr events through which X declares "I associate 'alice' with the chain coordinate 'nabandonzooa'."
It looks like nothing prevents X from publishing nostr events on relay A through which it associates "alice" with "nabandonzooa," and nostr events on relay B through which it associates "john" with "nabandonzooa."
Now a full node can discover *all* of the chain coordinates that have been claimed by pubkeys under this scheme, and it could for example identify the most recent chain coordinate C that was claimed by pubkey X, say the one whose string is "nebuchadnezzar". Then one can look at X's nostr events and find an event on relay A showing that X has associated "alice" with "nebuchadnezzar." Of course one can't be sure that there isn't some other event on some unknown relay B through which X has associated "john" with "nebuchadnezzar."
The result seems similar to searching for kind-0 profiles published by pubkey X. One might for example find a profile event signed by X with the profile name "alice" on relay A and choose to display that in a client, but of course one cannot be sure that there is no other profile event signed by X on some other relay B that shows "john" as the profile name.
I'm not sure yet what exactly this system is trying to add.
"after it ate" seems more like a subordinate clause. 🤨
Yes, please feel free to create a toy identity on the homepage in the meantime. There is an option at the end of the wizard (and also separately on the homepage) to send me the identity creation file, and I can go ahead and record it on-chain and cover the $0.17 or whatever in gas fees.
to avoid the sad conclusion, maybe just start using the PKI provided by inkan to see what feels like in practice, and it can then be improved bit by bit based on feedback