1. Instead of replaceable event's couldn't timestamps or invalidation work? A pointer to the event that's being replaced also be signed? It could make it easier for stolen keys to replace old versions with malware. I understand the asset won't be replaced, but the public pointer with version to the asset will be.
2. Optionally displaying souce only supports http git remotes. You should at least consider a variable format for source code. Signed tarballs or zips are also totally acceptable from FTP sites for example. It might also be worth while to allow sums of source and/or a commit that the package was built from.
3. Are there ways to handle variants of x86 and others for example? I ship packages that require x86-64 v2 and sometimes v3 extensions. You mention it's "loosely based", so I assume it's not a strict set?
ChipTuner
npub1qd…3fqm7
2026-01-29 19:36:23 UTC
in reply to nevent1q…h7zy
Author Public Key
npub1qdjn8j4gwgmkj3k5un775nq6q3q7mguv5tvajstmkdsqdja2havq03fqm7Published at
2026-01-29 19:36:23 UTCEvent JSON
{
"id": "18fc817aa606b5a3ccc739ebb1f340052ee9d3c97921255019ae26a725236ff4",
"pubkey": "036533caa872376946d4e4fdea4c1a0441eda38ca2d9d9417bb36006cbaabf58",
"created_at": 1769715383,
"kind": 1,
"tags": [
[
"e",
"638a3651256f17b3f9138771de66b8d193b2c5a5658ae2ec4b93b3586dbdc32f",
"nostr-idb://cache-relay",
"root",
"726a1e261cc6474674e8285e3951b3bb139be9a773d1acf49dc868db861a1c11"
],
[
"e",
"638a3651256f17b3f9138771de66b8d193b2c5a5658ae2ec4b93b3586dbdc32f",
"nostr-idb://cache-relay",
"reply",
"726a1e261cc6474674e8285e3951b3bb139be9a773d1acf49dc868db861a1c11"
],
[
"p",
"78ce6faa72264387284e647ba6938995735ec8c7d5c5a65737e55130f026307d"
],
[
"p",
"726a1e261cc6474674e8285e3951b3bb139be9a773d1acf49dc868db861a1c11"
]
],
"content": "1. Instead of replaceable event's couldn't timestamps or invalidation work? A pointer to the event that's being replaced also be signed? It could make it easier for stolen keys to replace old versions with malware. I understand the asset won't be replaced, but the public pointer with version to the asset will be. \n\n2. Optionally displaying souce only supports http git remotes. You should at least consider a variable format for source code. Signed tarballs or zips are also totally acceptable from FTP sites for example. It might also be worth while to allow sums of source and/or a commit that the package was built from.\n\n3. Are there ways to handle variants of x86 and others for example? I ship packages that require x86-64 v2 and sometimes v3 extensions. You mention it's \"loosely based\", so I assume it's not a strict set?\n\n\n",
"sig": "429571e998891c86fa6540c8781a5cde45ce107c6206a7fc0edebbfc6e972d372687453c4a3e354d592f8825a0690358fd2c9493525320749986939d389506d5"
}