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

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

[Test]

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.