Content pfp
Content
@
0 reply
20 recasts
20 reactions
vrypan |--o--| pfp
vrypan |--o--|
@vrypan.eth
Is there an app to manage signers? Like "these keys have permission to add/remove casts on your behalf"? It would be nice to have an independent way to manage/check/revoke signers.
1 reply
0 recast
1 reaction
Dan Romero pfp
Dan Romero
@dwr.eth
It’s built in to Warpcast mobile but easy enough to build outside of Warpcast since all the data is onchain.
1 reply
0 recast
0 reaction
vrypan |--o--| pfp
vrypan |--o--|
@vrypan.eth
I did not know it. Nice!
1 reply
0 recast
0 reaction
vrypan |--o--| pfp
vrypan |--o--|
@vrypan.eth
But, what does this mean? Are they actually invalidated at the protocol level? Does this mean that if an app gets compromised, and users have to disconnect, all activity created through the app will be gone?
3 replies
0 recast
0 reaction
Varun Srinivasan pfp
Varun Srinivasan
@v
yes, if you hit the button today it does the things it says above. if you want to preserve messages you can resign them with a key that you're keeping around. will build this functionality into warpcast in the future, but right now not many people are disconnecting apps.
1 reply
0 recast
2 reactions
vrypan |--o--| pfp
vrypan |--o--|
@vrypan.eth
I'm OK with this not being part of Warpcast. I'm more interested on how it can be done at the protocol level. Does it need a new FIP, or is the functionality already there?
1 reply
0 recast
0 reaction
Varun Srinivasan pfp
Varun Srinivasan
@v
it should already work at the protocol level.
1 reply
0 recast
0 reaction
vrypan |--o--| pfp
vrypan |--o--|
@vrypan.eth
That's nice. What about messages that cancel one an other? Like a cast_add/remove pair, when they are signed by different signers and one of them is revoked? This case: https://warpcast.com/vrypan.eth/0x1bc2dd
1 reply
0 recast
0 reaction
Varun Srinivasan pfp
Varun Srinivasan
@v
It should work, if you're curious the specific rules are here: https://github.com/farcasterxyz/protocol/blob/main/docs/SPECIFICATION.md#2-message-graph-specifications
1 reply
0 recast
0 reaction
vrypan |--o--| pfp
vrypan |--o--|
@vrypan.eth
"Casts are added with a CastAdd message and removed with a tombstone CastRemove message, which ensures the message cannot be re-added while obscuring the original message's contents." My interpretation: CastRemove does not trigger the corresponding CastAdd to be deleted from CRDT, just concealed.
1 reply
0 recast
0 reaction
Varun Srinivasan pfp
Varun Srinivasan
@v
I would recommend reading the specific sections i posted above about CRDTs and the Cast CRDT in particular.
1 reply
0 recast
0 reaction
vrypan |--o--| pfp
vrypan |--o--|
@vrypan.eth
It's not laziness, I've been digging in the protocol doc for days. But sometimes, it's' not easy to interpret everything the right way. Sorry for being a pain :-). Thanks for the patience! I also did some tests, and now it's clear to me that CastRemove will remove the original message from the Cast CRDT.
0 reply
0 recast
1 reaction