Can someone help me understand how nostr:nprofile1qqs83nn04fezvsu89p8xg7axjwye2u67errat3dx2um725fs7qnrqlgzqtdq0 works?
First thing I don't understand is where the files live. Do the APKs just live on github and then there is automation to check that the hash of the release matches what the dev publishes to zapstore?
If so, what is actually published to zapstore? Is it just a note from a developer that a release has been made, it's location and hash?
There's two types of packages in Zapstore. The ones we index (Github and other) and self published by developers. Ideal is the latter, but the former is necessary.
So, where the files live depends on the package. I encourage you to query our relay for kind 1063s and check url and x tags.
Indexed locations and hashes are captured at the time we crawled them. Some developers modified releases after the fact and this caused hash mismatch errors - Zapstore working as expected.
OK, so zapstore itself isn't storing packages.
The hash mismatch is expected, but you're computing them when the event comes to your relay? I'm assuming that is just stored in your internal DB, and not on nostr right? Could that be bypassed if the storage was a blossom server?
Sorry, I'm confused. When indexing we produce 1063 events we store as nostr events in our relay. We use a database for the relay
When developers upload their APKs to Zapstore, cdn.zapstore.dev acts as a read only Blossom server.
