Super cool. For binaries, I thought about aligning with the work that nostr:nprofile1qqs8y6s7ycwvv36xwn5zsh3e2xemkyumaxnh85dv7jwus6xmscdpcygpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz8thwden5te0dehhxarj9ekh2arfdeuhwctvd3jhgtnrdakj7qghwaehxw309aex2mrp0yhxummnw3ezucnpdejz7qxvpy4 has been doing with nostr:nprofile1qqs83nn04fezvsu89p8xg7axjwye2u67errat3dx2um725fs7qnrqlgpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtcsrhspy. One or more 'App Profile' events could reference the repo announcement and share WoT heuristics.
A binary 'release' event linked to one or more 'App Profile' event then is a list of nip94 events referring to the each file in the release.
Trust attestations could be made against the repository, app profile, release, or authors of these events. You could have services like nostr:nprofile1qqsw3znfr6vdnxrujezjrhlkqqjlvpcqx79ys7gcph9mkjjsy7zsgygwr32sk's binary watch signing trust attestations for releases that support reproducable builds.
It makes a lot of sense to me to use 'App Profile' and not only because it aligns were the zap.store. A repository may contain one or more 'app profiles'. Maybe its a mono repo or has different releases for say desktop and andriod.
I've thought for a long time that DVM would be great to do CI/CD instead or relying on git hooks.
I'm keen to hear your ideas. What thoughts are bubbling away?
This is great, would love to see us collaborating here.
Here's a basic class diagram of what's being used in zap.store in production:
Applications ("App profiles") are the proposed NIP-82 (kind 32267), see here: https://github.com/nostr-protocol/nips/pull/1336
Releases are already in NIP-51 (kind 30063) and point to one or more NIP-94 (kind 1063) file metadata events.
Nice. I'd love that too. I've comment on the nip PR you just directed me to but I'll include my comments here for anyone who is interested
Love to see this and look forward to adding releases to nip34 clients.
Instead of referencing a nip34 announcement event in `repository` tag it should be referenced with an `a` tag so it will be indexed by relays. clients should look for an a tag with `30617` kind if repository is omitted.
The release event:
1. should be moved into this nip from the example section of nip51.
2. should be immutable and not a replaceable event. then trust attestations could be placed on the event eg. validation that the checksums of a reproducible build match.
3. should include an optional `["commit-id","
From a style point of view: I see most nips describe events using jsonc rather than a table of tags, which is easier to read. Is this now the standard?
lastly, the app event could support the maintainers tag like nip34 announcements This means clients could optionally interpret app events by the pubkeys listed with identical `d` tags as referring to the same app. `["maintainers", "
Great additions. I personally would love to see some way to verify a package. Source commit hash is a also a great addition.
I think a list of artifact hashes is important for authentication of binaries, we can, so we should.
Also I kind of like the idea of legacy PGP as an option as well. I suppose pgp files could be added as artifacts to the event to support this.
I don't think there's a way to verify a package other than trusting the builder/signer. That's what reproducible builds are for.
Artifact hashes: yes, NIP-94
PGP: we're adding it to kind 0s! Currently building a tool developers will use with the ability to attach their PGP keys or certs. See
Artifacts should be signed by the developer IMO and attached to a source hash if the project is open source. Upstream depend on being able to verify binaries, when source isn't available, or the build process is too complex or undocumented, such is the case for polyglot systems or container based deployments.
I agree but it is also sometimes useful to have a application signing key.
The common way of signing a release is to sign a checksum file which lists all of the related binaries hashes. That is essentially what the the nip51 event does although it doesn't include the actual hash, but rather the id of each event that contains the hash. This makes it harder to find release events that include a specific binary because there may be many nip94 events referencing the same file. We need to query for nip94 events for the hash first and then find releases that reference those. I suppose isn't too bad.
It makes more sense to me that trust attestations are made against a release event and not just each individual binary. What if the author accidentally included a binary from the previous release? the hashed file would still have trust attestations attached.
How would you highlight that a previously issued release package shouldn't be trusted as it contains incorrect version? With a replaceable event the author could quietly update it and the user wouldn't know that they didn't use the correct binary.
Definitely agree that attestations can't be placed on mutable events.
> What if the author accidentally included a binary from the previous release? the hashed file would still have trust attestations attached.
Doesn't this go against your point? If the author accidentally points to a wrong binary in a mutable release set event, they can update it.
A user cares about finding an attestation for the actual thing they're installing.
If it were mutable, the author would need to revoked and reissue which would notify the users who installed the incorrect version.
I'm coming around to mutable. You wouldn't want to have to revoke a release to fix a typo in the change log. Clients could also keep track of the version they installed from and notify the user if a new version comes in with worrying changes in it.
Right, I'm thinking clients could detect an update in the mutable release set, and then trigger double-checking the references file metadatas? As you say maybe it's just a typo and user needn't be prompted about it
Agree on release signing keys, I was lumping that into the dev's key, because presumably the developer (or their infra) holds that key. AKA developer's keys.
I suppose my concern is that there is enough information attached with my binary when I download it that I can trace it's hash to the source code (if open source) or that they developer told me this is the latest version, and here is it's signature. And you must trust that developer. With closed source this trust would be required. Just like in PGP, I don't know that we need/want a trust-less system here, if that is your suggestion?
Sorry if I am missing the point.
I was trying to make the case for trust attestations made against releases rather than binaries like what happens with gpg signatures today. I'm coming around to them just being made against pubkeys, app profiles and binaries.
Given that nostr:nprofile1qqs8y6s7ycwvv36xwn5zsh3e2xemkyumaxnh85dv7jwus6xmscdpcygpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz8thwden5te0dehhxarj9ekh2arfdeuhwctvd3jhgtnrdakj7qghwaehxw309aex2mrp0yhxummnw3ezucnpdejz7qxvpy4 has already been building with mutable releases, I don't think there is a strong enough argument here to warrant a change.
Thanks for considering that too, nostr:npub15qydau2hjma6ngxkl2cyar74wzyjshvl65za5k5rl69264ar2exs5cyejr .
nostr:npub1qdjn8j4gwgmkj3k5un775nq6q3q7mguv5tvajstmkdsqdja2havq03fqm7 we can totally add a git commit to the 1063
And btw you can recreate a checksum file by querying kinds 1063 with a #e of the 30063 - basically one query
Yeah fair enough. This is what I did on my website: I always have source tarballs associated with commits along with binary tarballs. The tarball hashes are individually signed.
I'm thinking for a mode where we have sdks and libraries that are being pulling into other projects during build time, where everything runs automatically and we want a secure way to verify artifacts during the upstream CI pipeline.
Awesome. I'll answer on github
Thanks for your considered reply. I'm interested exploring how this should shake down in practice.
Scenario: a project has 3 maintainers and 10 regular contributors and one of the contributors has a big positive reputation.
how should they go about issuing releases? assume we had trust attestations we could make against people, apps, releases (nip51 list) and release binaries.
Gotcha, I was thinking along the same lines and we discussed this in one of our design calls. I heard an argument against listing maintainers/contributors and that's leveraging natural abstractions: Fabricating a pencil involves a huge amount of people and they're not all listed in a single place, that's what the price system is for. You pay a certain amount for the pencil and the company internally distributes payments.
If a project requires this level of detail they probably should be using something like nostrocket. Thoughts on this nostr:npub1mygerccwqpzyh9pvp6pv44rskv40zutkfs38t0hqhkvnwlhagp6s3psn5p ?
And again, I don't think kind 30063 releases should be immutable (file metadata definitely should). In all honesty, who do you think will be issuing trust attestations to an event pointing to binaries in 7 different architectures/platforms/OSs? Who would be vouching for all of those binaries at the same time?
And by the way: we already have a way of including attribution. When I first floated this idea a few months ago I believe it was Pablo's recommendation to use the combination of `p` and `zap` tags to achieve it. NIP-57 appendix G goes over this mechanism.
Nice. This seems ideal for recognising snd rewarding contributors
I see the maintainer role as quite different to the contributor role. Maintainers decide which changes get applied to an application and make it into each release whereas contributors propose and / or code the changes. Often maintainers also review for quality but this is also sometimes left to contributors theough peer review.
The fabrication argument applies to the contributiom rather than maintainership.
In my above example the 3 maintainers could decide to create a key pair specifically for releases and share it amoung one another. It could issue the app profile event and each release. This seems to make the most sense if users are going to subscribe to a single app profile per application for releases.
What happens if one of the maintainers moves on? may be there is a falling out or they start working on the closed-source competitor. They will still know the signing key.
If however, app profiles supported maintainers each of them could create their own app profile from their existing pubkey, leveraging their own reputation, and include the others as maintainers. excluding the maintainers field, the app profile for this group would be the most recent one submitted by any of them. Any releases issued would be on behalf of the group. The membership of this group can evolve.
This is the best case I can make for adding a maintainers field.
I would prefer to follow an app profile published by a group of specific pubkeys with their own reputation who claim to maintain an app than a single pubkey who's ownership is opaque.
Another point is that in many instances I may trust an app profile issued by a zap.store or f-driod.more than one from the developers as I may trust there processes to review apps for malicious activity and tracking more than a set of maintainers that aren't in my web of trust.
Different app profiles for the same application can be a good thing.
Should zap.store be listed as maintainer of a project? Probably not. We're solving that in a different way: curators. Curators leverage their reputation and create lists and other nostr primitives to recommend apps. I would choose to install an app signed by a random developer but curated by two of my friends
zap.store shouldn't be listed as a maintainer of a project because it doesn't make decisions about what code is or isn't included in a release. However, if it decided to take on a role like f-driod, it could issue a app profile for some apps, review releases produced by the project to check for undeclared trackers and malicious code, build from source and issue their own releases for an app.
Curator sounds great! In reality, most applications aren't reproducible and we are trusting the issuer that they built from source and didn't introduce any vunerabilities in the process. In fact, most applications aren't opensources so we are trusting the issuer even more.
Having trust atestations against app profiles and pubkeys that issue them are the most important and useful sort. Curator is a really good choice of word to describe this.
Totally. I am not persuaded about zap.store issuing app profiles. Let's say I want to recommend Mutiny Wallet and you follow Mutiny and zap.store... which one are you going to install? What happens when you have multiple curators vouching for Mutiny? To me, the signer is always the dev and then we can overlay trust attestations, badges, external service providers attestations – a DVM market/reputation will emerge for these kind of things
I'm not suggesting you should as it would shift your focus from building zap.store into QAing apps. Using a f-driod type issuer of releases would prevent the developers from issuing malicious binaries for non-reproducible builds but enable the issuer to do so. I don't think the incentives are there for anyone to take on that role.
The nature of the trust attestations and how they are interperted is the tricky bit. Probably much easier to critise than design.
We're definitely interested in being a curator and in fact we already are one (plan is with time to allow other relays and curators). We'll see how everything plays out, for sure there will be tons of developers that will not sign their apps and curators will have to in their place. I don't really like F-Droid's model for non-reproducible builds, I'd rather pull the dev build with their own certificate and stamp a nostr signature on it. Step by step 😄
For me it depends on the app. I don't love the centralisation and their sometimes obnoxious behaviour; but I prefer my chances of being rugged by f-driod's build process than any one of 6 app developers build process.
sure, depends, for critical apps (ie money) I would only use apps sourced from devs (better if it has reproducible attestation)
It will be interesting to see how it all plays out.
I'd definitely value a dev attesting that they reviewed all the code added to Sparrow Wallet in a release and Craig Raw isn't obviously rugging everyone. I'd want to zap that.
Sure. But besides reproducible builds it's impossible to know if the build is not manipulating the source code. So you got to trust the dev and the build environment
To complement your example, I have been enjoying obtainium. Code directly from the developer. If I could I would want an app store that I can manually enter developer's keys into or do an openssh style "do you want to save this key" on first download, then subsequent updates will validate signatures as they are released. If the developer changes their keys, it should be a manual process or lots of blinking read lights. I don't want to trust an app store, like the case for F-Droid. I understand why they do it, but I like the model of, hey get this package from it's owner.
Its not obvious but this happens by default with APK installed on android. The app must be signed with the a key and the key must match the already installed version.
Choosing the correct app when you first install it is the key.
you just described zap.store 😄
And yeah TOFU is the way. Android does it and we'll be bringing that to other OSes
Yes I fully agree, this can definitely become a problem. I think though we're stepping on premature optimization territory. We can always add/migrate to the maintainers tag later if it ever becomes necessary, right?
I thought about this one as it becomes very difficult to add later as we are building a bazzar rather than a cathedral. The incentives won't be there to add it later.
Without this feature most app teams will create a keypair for the app and share the key between maintainers. This will build up trust and an install base. They won't be incentivised to abandon threre existing pubkey which has built up trust and an install base. They won't have a mechanism to make it easy for users to switch to the new model. And unless 90% of the client support it they will degrade the upgrade experience for a proportiom of their users.
Clients won't be incentivised to add support because 1) there client is working 2) they are busy with other things 3) existing app teams aren't asking for it becuae of the above incentives 4) they are waiting for other clients to add support first
Sure, it's all about striking the cathedral/bazaar sweet spot. Can't something like FROST solve this or do we need to bake it in now? A few weeks ago nostr:npub18z6qteykzjp4czp6uypnnrz3qv2u8gpkdnazwy2ejhneayj9zpvqzvn6df posted videos showing nostr multisig
As I understsnd it, in an n/m you can only remove n-1 participants which wouldnt meet our needs.
