%pyOW0XV...

@andrestaltz "It's hard to say if or when I'm feeling better, but at least today I had some productive thoughts in the shower. One of them was about how to nuke an SSB feed once you have declared it forever unusable. Like imagine somehow magically someone got hold of the keys for @deprecated_zelf and started acting on her behalf, impersonating etc. There are two ways I imagine such accounts could self-nuke to avoid any future messages: (1) simply publish a new msg type "EOF" (end of feed) which is subjectively used by apps to ignore future messages, (2) some kind of cryptography magic that makes it impossible or invalid to sigchain future messages. Not sure if (2) is possible."

riffing on this - haven't thought it through

with #mmt #dark-crystal #darkcrystal we're getting p2p password recovery by allowing nominated friends to help restore/recover data.

i wonder if there is a similar function where a certain threshold/quorum could help to sociall mark a feed as revoked?

zelf loses her ssb key, but has previously nominated her coven.

she contacts her coven out of band to confirm old feed should be revoked.

the primitive here is that our powers come from our social connections

when we can lean into the support of our social connections it changes the assumptions we can make about trust and what can be acheived at the protocol / computer level...

talking with friends, I started to call this type of message tombstone.

Using the shards from a dark crystal to conjure the EOF on the original feed sounds much more tractable then logging a voting process where you have to witness the hole thing (all the participating feeds) to have the result.

One thing I’m wondering about is: how does it stay gone? I guess the last operation after removing the EOF feed could be some kind of acknowledgement on the witnessing feed? Like a block but a little different because you don’t won’t to hold EOF back from you peers...

My main concern is old pubs replicating the graveyard indefinitely.

some archeology: %t+uW8wp... %LkmZKu0... %G1CN9qg...

Nice links @cryptix, now I know what tombstone referred to. :)

In the above scenario, it kinda logically wouldn't make sense for zelf not to have backed up her ssb key with the cabal... perhaps...

but it does start an interesting thought experiement about what it looks like to assign power to a coven of your choosing...we'll have to start imagining what is possible with such interwoven and collectively assigned subjective contextual social power...

https://wiki.parity.io/Secret-Store

Empowered Covens a.k.a. Safety Teams

n.b. I have borrowed the term Safety Teams from Tiara

forking and copying from another thread:

@jasongreen

Does focusing on the theft scenario narrow to some degree the whole focus of dark-crystal from generalized secret sharing to the more specific function of sharing ssb identity secrets? This whole question of deprecating an identity applies to ssb secrets, but not to other secrets you might use dark-crystal to shard out.

@kieran: "It does to a degree. I think in order to deal with theft properly, we either think about a trust declaration system or we forward all shards (I think @dan this is what you were saying here?).

With a trust declaration approach, Alice says to @bob that @alice is no longer Alice, Alice is in fact @newalice. @bob verifies with Alice out-of-band that Alice and @newalice are actually the same person, then @bob declares to others that @alice is not Alice, Alice is actually @newalice. The other shard custodians do the same, creating a consensus within Alice's trusted circle that @alice is in fact a thief, meaning those custodians will no longer send back shards to @alice (and the UI can disable this completely). This is particularly relevant in the case of say cryptocurrency private keys. For example, @newalice has recovered her SSB identity from @bob + 2 other custodians. But hasn't recovered the shards for other secrets. @newalice might want to reevaluate, get all those shards sent back at once, move funds out of all wallets into new addresses (i.e. generate new keys) and create a new dark crystal for each. Or @newalice can declare to her trusted peers just not to send @alice any shards. Both are an approach. The Forward All is the safer option IMO. Perhaps thats what we should think about now. Perhaps later we can think about a trust declaration system."