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.
DanConwayDev
npub15q…cyejr
2024-07-03 20:39:55
in reply to nevent1q…5c0s
Author Public Key
npub15qydau2hjma6ngxkl2cyar74wzyjshvl65za5k5rl69264ar2exs5cyejrPublished at
2024-07-03 20:39:55Event JSON
{
"id": "4a7ce0c8ce86592f7935dd88c47cae7014fedf8309d61902ac62933d5ea7ea65",
"pubkey": "a008def15796fba9a0d6fab04e8fd57089285d9fd505da5a83fe8aad57a3564d",
"created_at": 1720031995,
"kind": 1,
"tags": [
[
"e",
"7fba60aa1cd8232156992ed5fe69a5c5cdd201b4b8bf2ade5152291036b2f67f",
"",
"root"
],
[
"e",
"50cc4c86cbb30982229ef447cd4facf77c3fdc5c26c49aae3dce88c69a413e57"
],
[
"e",
"858b21bef4ab7d4fe62f34ab26d1f0a9c782e30cbc557544e33caf7472b247ce",
"",
"reply"
],
[
"p",
"a008def15796fba9a0d6fab04e8fd57089285d9fd505da5a83fe8aad57a3564d"
],
[
"p",
"036533caa872376946d4e4fdea4c1a0441eda38ca2d9d9417bb36006cbaabf58"
],
[
"p",
"d91191e30e00444b942c0e82cad470b32af171764c2275bee0bd99377efd4075"
],
[
"p",
"726a1e261cc6474674e8285e3951b3bb139be9a773d1acf49dc868db861a1c11"
]
],
"content": "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.\n\nThe fabrication argument applies to the contributiom rather than maintainership.\n\nIn 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.\n\nWhat 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.\n\nIf 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.\n\nThis is the best case I can make for adding a maintainers field.\n\nI 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.",
"sig": "ddec2109afe701d9258f2c1be4f2c8f7c3b488a420dc6bc2852d95deb880dfc16d2864319eff0a54702044082c566e9974e3357cb77696457f815de06c7f7ac0"
}