Nostr Web Client

Aurora 2y ago

I love this idea.

I love all ideas that enable deleting and leaves that choice with the user.

Aurora 2y ago

#[3] thanks for the zap girl!

Madelaine 2y ago

Anytime! ⚡️😊💜

Yousef Abdullah 2y ago

Question Are Backups When Trying to Use It How Much It Can Work Again Is There an Experience on This

Derek Ross 2y ago

This would also enable a bad actor with the leaked keys and nuke someone's events for them. 😭

やトナ 2y ago

If your keys leaked wouldn’t you want it nuked?

Derek Ross 2y ago

Eventually, but maybe you wanted to save something first?

Vitor Pamplona 2y ago

Maybe you won't even have time. Attackers can start deleting things as soon as they see your keys. And you can't do anything to block it.

t4es5ter5 2y ago

What if someone steals your key and send it to those service? Then you are erased forever.

t4es5ter5 2y ago

SO I strongly disagree. Never allow delete. Maybe a flag per client

Aurora 2y ago

Definitely need to think through bad actor possibilities but it’s a great idea to start with.

t4es5ter5 2y ago

You cannot avoid bad actor behaviour. That's also why bitcoin transactions are irreversable.

Aurora 2y ago

I agree that bad actor behavior can’t be avoided. I also think it can be mitigated.

t4es5ter5 2y ago

Well, we will see (hopefully not). I stick to my idea deletion of keys should be avoided at all costs. Bitcoin proves us this...

Aurora 2y ago

I haven’t thought through it enough but I do fundamentally believe in giving users the ability to delete. I’d rather think about how to make this possible and how to address any potential risks and flaws, instead of focusing on the things that make it difficult and allowing that to lead the way.

t4es5ter5 2y ago

Maybe move all deleted data to some relay which contains all the deleted keys or something like that indeed.... Maybe there are possibilities

Vitor Pamplona 2y ago

If your keys leak:

1. How do you know if the events you are downloading were made by you and not the attacker? The attacker can insert events in the past...

2. The attacker can start deleting as soon as it sees your keys. With or without this service.

Aurora 2y ago

What are you thinking through here? Are you still arguing in favor of deleting?

1. I didn’t understand this point very well sorry. But I didn’t know it was possible to insert events in the past. (Am not a developer). Interesting.

2. When you say the attacker can start deleting, does that mean that there is already some functionality that allows deleting (and actually guarantees it)? I thought as of now it’s impossible to delete.

Vitor Pamplona 2y ago

There is a "request to delete" event you can sign and send to relays. Most of them will delete your post by now. So, if your keys leak, it doesn't matter if this service exists or now, they can just send a bunch of delete events, signed as you, while at the same time add new, fake ones, with whatever they want to scam your followers with.

Aurora 2y ago

Yeah. Dangerous.

There could also be a “bad actor” relay though right? That doesn’t comply with delete requests and is just storing things for some potentially evil purpose?

Vitor Pamplona 2y ago

Yep.

Aurora 2y ago

I think it would be worthwhile for someone to start making personal internet security tools for nostr. I don’t know if I phrased that right. But basically personal cybersecurity. I would pay for that.

t4es5ter5 2y ago

💯

faisal 2y ago

Is service the right word here?

Vitor Pamplona 2y ago

Watchtower? The service needs to constantly watch for the use of the leaked keys.

someone 2y ago

1. Set a spare pubk B using secret key A

2. In case the secret key A is stolen, use secret B to publish a special event that says "B is now the secret key replacing A"

3. Clients show a warning that A is stolen and B is the new one. Clients update the follows. Relays can't do much..

symbsrcool 2y ago

Super interesting, hope others comment on the feasibility of this

Ronin 2y ago

This. A revoke key. That allows old key to be marked as old a set a new one.

Ronin 2y ago

And possibly copy everything from the old key to the new one, including followers and following.

26

Grandpa Zed 2y ago

The problem with having a backup key to revoke your private key is that you have to keep it somewhere. We're already discussing an event where your private key has been stolen. Chances are you kept your revoke key in the same place as your private key: on the computer that was just hacked.

Everyone will say, "Nooo, we'll keep the revoke key in an super-duper extra-special place where it will be safe!"

But that's what they were supposed to do with the original private key, and didn't.

The problem lies with the users, not the technology.

Ronin 2y ago

I get what you're saying and you're right that the problem is people, but you need not only a way to delete your old npub but also claim your new npub, the revoke key could be a password chosen by you, like in bitcoin, you can have your seed phrase+pass. Another option could be social recovery but you would have to prove it out of band, and not everyone has known people in the network.

Vitor Pamplona 2y ago

What blocks the attacker to go back in time and publish a second pubk B? How do you know which event to trust if you have two of them?

someone 2y ago

Couple of solutions could be

1 Relays relaying meta data about when they received it. Means bigger nips.

2 Relays not accepting 'declaration of successor' more than 7 days old. Not sure if this needs a nip.

Vitor Pamplona 2y ago

What if you are using the Gossip Model (Auto finding relays) and the attacker gets a hold of your keys, changes your relay to their custom relay and remove those protections?

someone 2y ago

I think easiest is to block successor events that are older than 7 days. I could do this on nos.lol with plugin. Anybody can query it then to find the earliest successor event for a given pub.

shafemtol 2y ago

NIP-03: OpenTimestamps Attestations for Events

someone 2y ago

"While OpenTimestamps can create timestamps without a local Bitcoin node, to verify timestamps you need a local Bitcoin Core node (a pruned node is fine)."

OpenTimestamps looks like overkill.

What do you think of 'declaration of successor' events to be blocked by relays when they are older than lets say 7 days?

shafemtol 2y ago

Relays shouldn't have to be trusted.

It's not really true that you need a full node to verify OTS timestamps, you can use an SPV-like trust model where you just have the Bitcoin block headers and check their POW. The headers are just 80 bytes per block.

Maxwell 2y ago

#[0]

pupokopup 2y ago

It's a good idea. Very good idea.

Centurion 2y ago

That would be a tough situation where one would learn the importance of guarding ones keys. Yet if someone was messing around with my posts I would want exactly that service. Better to sink the ship then wait around to be sabotaged.

Can Amethyst make it easier to push your old posts to a personal relay or is there already a service for that?

WilliamHodl 2y ago

I don't think this a good idea, someone could definitely manipulate this in a bad bad way. This idea scares me.

Centurion 2y ago

Also, would it be possible to resync old posts to a new key, that are backed up on a personal relay?

Centurion 2y ago

Now that I'm thinking about it, I would be more distraught over having to refollow everyone I have collected. Would be great to have a way to push them to a text file, like bookmarks

Josua Schmid 2y ago

Is this a subspec of editing (like for long content)?

James A Lewis 2y ago

Addition: allow only one post type: forwarding to a new npub. This allows followers to find you again if you need to start with new keys without starting from scratch for following.

Vitor Pamplona 2y ago

But how does it know if that event comes from you or from the attacker?

neo 2y ago

Add an (optional) timestamp. I don't want my past wiped, just block future events.

Vitor Pamplona 2y ago

You won't have that choice. If people have your keys, they can do everything.

mchotbot 2y ago

Your post is getting a lot of views.

Added to the https://member.cash/hot feed

Leo Fernevak 2y ago

Terrible idea Vitor.

If my Nostr private key is compromised, I would still want to send some message from my account to re-direct my subscribers.

In your scenario an account thief could nuke my account and prevent me from using it.

Vitor Pamplona 2y ago

What if the attacker does that first?

Leo Fernevak 2y ago

I can verify myself via other accounts or other social media. However, I would still want to post from my account if it was compromized.

Vitor Pamplona 2y ago

But again, how do other people know it is you posting? The attacker can literally send your followers to anywhere the attacker want. There is no way to know which events are yours and which ones are the attackers.

Your post to lead your followers to a new key is extremely dangerous.

Leo Fernevak 2y ago

An attacker can send messages from my account before I even know that my key is compromised.

When my account is compromised, both the attacker and I can post from my account, as long as your idea isn't implemented.

In such a scenario I will post that my account is compromised and provide *evidence* via other social media accounts. The attacker can't do that.

I could also prepare in advance by setting up 1-2 backup nostr accounts that only I have access to, which are unlikely to be compromised at the same time.

Your idea would prevent me from posting from my account, and that is very dangerous.

Vitor Pamplona 2y ago

Do you really think attackers don't already have this tooling? It's already coded. It's quite literally 20-30 lines of code to delete all your events from all relays.

Leo Fernevak 2y ago

Why would all relays support such a tool?

Vitor Pamplona 2y ago

They already. Most of them.

Leo Fernevak 2y ago

I see. I guess we have to live with bad security implementations then.

One solution is that we prepare by creating one or several backup accounts and use them to verify our future account when the old is nuked.

Vitor Pamplona 2y ago

Yep... A service like that can be useful.

Leo Fernevak 2y ago

Thanks for the heads up.👍

Aurora 2y ago

My thinking is that ultimately it is more hazardous for an attacker to have your key and use it for bad actions that could seriously jeopardize you than it is for you to lose access to your account. Right?

Richard 2y ago

A service to nuke accounts simply gives bad actors an extra incentive to steal keys to totally 'memory hole' dissidents. The protocol should be optimised to allow notes to persist forever IMHO.

Vitor Pamplona 2y ago

Relays might delete your data at anytime. Especially if you are not paying for storage.

The amount of data will likely force all public/free ones to only host the past ~2 weeks worth of events.

If you are paying, you should probably talk to them to lay for a backup solution as well.

Ian "nostr.naut.social" D 2y ago

Yes. I run a relay at nostr.naut.social and when it gets busy, I thinking in terms of a 30 day hold, but it could be shorter. Longer for those who pay more:-)

Richard 2y ago

Indeed. All the more reason to host your own relay with all your data backed up.

Umbrel already offer an easy to spin up ‘app’ option to do this in a self hosted way.

https://apps.umbrel.com/app/nostr-relay

Vitor Pamplona 2y ago

We should call this Nukstr.

Also, the replies here show how far we are from correctly educating users about who actually owns their Nostr data and the role of relays.

#[0]

Aurora 2y ago

One of the things I learned is that I should be creating backups. Have no idea how to do that.

Vitor Pamplona 2y ago

Put up a bounty. Let somebody else build the service for you.

Aurora 2y ago

Great idea. How much do you think the bounty should be? I don’t know how much time it would take or how complex it is.

Vitor Pamplona 2y ago

How much is your data worth to you? Find friends with similar issue to add to the bounty and let's see who gets to win it :)

Aurora 2y ago

Did you already build this for yourself?

We’re talking Nostr data only right?

John Dee 2y ago

This seems like a service that relays could offer, opt-in of course.

Michael Anton Fischer 2y ago

I think this is the worst idea I have heard today.

threeseries 2y ago

I kind of like this idea. It could also be a way to deliberately burn an account if you want to get rid of it.

How about such a service also sending out notices which provably came from that service after it has access to a given key? That is, sign something in a way that requires both the service's private key and the leaked private key.

threeseries 2y ago

It would be a kind of official announcement that the key is no longer any good

Alex Gleason 2y ago

I’ve already created a small server that does this, although it needs to be self-hosted. Can handle thousands of keys easily: https://gitlab.com/soapbox-pub/plan-b

The Fishcake (nostr.build) 2y ago

The name is fantastic! 🐶🐾🫡😂

rejon 2y ago

love this innovation!

Tourne1 2y ago

Wtf!

Dude. Do you sit on a computers 24/7 generating code for new software endlessly? 🤣

0xtr 2y ago

Cool!

kennytaylor 2y ago

The request would need to be signed by the leaked key, similar to an SSL certificate revocation list. That affrms that either 1) the owner requested the revocation, or 2) the key was leaked and someone else requested the revocation.

The same mechanism could be used for de facto account deletion, if all relays honored it.

Reply to this note

Discussion