Avatar
Felix
11674b2d321fc24239b02afdf966c32e36594a6282bd7f3d4bcd12438558ab51
Funny money developer @felix.7252 on Signal

Governments temporarily deactivated the internet in 35 countries in 2022

Ham radios don't fix this but are a great little backup

Replying to Avatar someone

NIP-101

=======

Fix for stolen secret key problem

----------------------------------

This NIP defines a solution that may be implemented by clients and relays for stolen keys problem. Lets say a user owns two accounts, uses A actively but wants to switch to B in case A is stolen.

- Secret key A sets a 'successor' pub B by storing an event with a new kind in a relay. Kind may be 101.

```json

{

"id": "...",

"pubkey": ".......AAAA........",

"created_at": 1669695536,

"kind": 101,

"tags": [

["successor", "...........BBBBBBBBB......."]

],

"content": "",

"sig": "...signature.by.AAAA........"

}

```

- In case secret key A is stolen, the owner of A uses secret B to start simply creating notes of any kind, or create one event with a new kind that says "B is now succeeding A". First option is easier, second is more elegant.

```json

{

"id": "...",

"pubkey": ".......BBBB........",

"created_at": 1769695536,

"kind": 1,

"tags": [],

"content": "Hey I am the owner of AAA and my secret key was stolen. This is my new account",

"sig": "...signature.by.BBBB........"

}

```

OR

```json

{

"id": "...",

"pubkey": ".......BBBB........",

"created_at": 1769695536,

"kind": 102,

"tags": ["p",".........AAAAAAAAAA..............."],

"content": "Hey I am the owner of AAA and my secret key was stolen. This is my new account!",

"sig": "...signature.by.BBBB........"

}

```

- Clients see B is active and show a warning that A is now stolen and B is the new one. Clients update the follows.

- Relays MUST block 101 events that are older than X days for this to work properly. X may be 7. Clients MUST fetch ONLY the first 101 from a relay that supports this.

What will happen if only a few relays implement this NIP?

---------------------------------------------------------

The attacker will use secret A to create a 101 with an older created_at. Clients will think the successor of A is actually was C..

The clients will see both B and C coming from relays. At this moment the client may choose to 'honor' the relays that implemented this NIP and choose B as the successor instead of C.

________

Requesting for comments. What does everyone think?

#[0] #[1] #[2]

#[2] #[3] fyi

Don't understand why you get an error there. Maybe you need an additional argument? I use pubkey_refs for example in a filter like this:

filters_pm = Filter(kinds=[EventKind.CONTACTS], pubkey_refs=['user_pub_key'])

to fetch all users who have a specific pubkey in their contact list (following it)

Thanks for your support🙏

Big thanks to everybody who supported this, would never ever have expected this. 💜💜💜💜💜💜💜💜

Will use this to focus more on development and provide value to Nostr and Lightning users.

#[0]

Replying to Avatar Felix

Here is a link to the repo: https://github.com/f321x/nostr-follower-dm-tool

A demo instance is hosted on lnaddress.com/nostr-tool best to just run it locally tough

Planning to migrate it to client side architecture later

#[2]

Ja und dazu noch Lightning, keine Chance mehr, exponentielle Freiheit :D

Wäre cool wenn du bei meinem verlinkten Hackday Projekt ein like da lassen kannst, da läuft aktuell eine Abstimmung bis heute Nachmittag 💜