This introduces interesting attack vectors that will need to be mitigated.
E.g. When a person gets hacked, then that could introduce many "scam" apps to people that followed the person.
You can mitigate this with external code verifiers:
- that get payed to do that π Verifiers DVM's
- that pay to do that π early beta access
(and then of course we need key rotation asap for way more reasons than just this)
βtrustβ is delegated from the AppStore bureaucrats who let scam bitcoin wallets in anyway, to your WOT.
Would you expect all of your WOT to get hacked at the same time @nout ?
I'm assuming that not all people in your web of trust need to verify the app. So there will be some threshold. E.g. "at least 3 people in your WOT with score over 5 verified app ABC". And then yeah, 2 people could be hacked, especially over longer term. There are definitely ways to mitigate these issues...
The framework that I like to think in is "desirables vs undesirables":
- If the user action is desirable, the user should be rewarded sats.
- If the users gets value from the content, they should be nudged to voluntarily pay sats for it.
- If the action is undesirable it should cost sats.
Maybe? Are you thinking that when a new person verifies the app, the verification has to get interactively signed (with multisig) by other people? Or are you thinking co-signing with the store or some verification system paid for co-verifying?
With the likelihood of multiple secret key being compromised, a release has to get X number of signatures before considered verified by clients and thus downloadable.
Whether the signatures are independent or m-of-n multi-sig is something to explore.
In the case of paying for co-verifying I think it will have the wrong incentives if an invalid verification isnβt penalized somehow and the affected users reimbursed?
Could you please explain this to me like I'm completely stupid? π
Let's say there are 5 users that already have solid WOT score. Now 2 of them get hacked and hacker installs and "verifies" an AppX.
Unless the other users get somehow notified of the hack, they will see the AppX as "verified" and may potentially install the app too, no? What would prevent it? Some lower bound limits on how many people are needed to "verify"?
Pretty wild to look back at the first version ever of zap.store, 8 months ago.
We had no Android, no APKs, no custom relay, no Dart library, no indexer, no CLI... what a ride!
PABLOF7z
solving fake apps in app stores
automatic signature and provenance verification over nostr
cc @DETERMINISTIC OPTIMISM π@ODELL
#SOVENG