Not ignore it, more suggesting a whoopsie can be fixed without hiding the whoopsie. It doesn't need to be displayed, it's just useful to be available. You see whoopsie, I see opportunity for deceit. Beyond that it could allow the community to rely on relays to keep a watch out for this deceit. There is no reason, for example, github releases couldn't have an edit history. You still get the version the dev wants you to get but as the user, I'd get the opportunity to audit why they rug pulled my package.

> Developers constantly replace releases on users, Thats why I said this >> I understand these are problems will face today, but I think we can fix that with some immutability. Just because developers havent messed on the platform yet, they do all the time on github and others it drives me nuts. Ubuntu for example, only offers links publicly to their latest images which will have a different checksum despite the same dl link every weekly. We have hardware/stability issues and ended up keeping our own store of iso images (which is generally recommended) because they change the image url.

I do relate to this. A lot. We're all hypocrites, but sometimes it really feels like so few can really mean their opinions.

Yes, an intermediate to be able to issue edge certs across all balancers.

1. I mixed up some concerns in my head. My concerns are that developers can do sneaky things by replacing events on users. Having a chain of versions I can see/store is what I was considering, that way I, the user, can decide which versions I want to run. And/or sneaky patches that alter the release system. Im concerned knowing that most organizations are going to have their release cycle automated and signing key stored in their devops system, if a safe version was replaced with a malicious version, users platforms might be able to roll back to a previous version, or users as well. What stops the publisher from replacing all versions at some point in the future, disallowing me from running an old version they had? I understand these are problems will face today, but I think we can fix that with some immutability.

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?

I got my answer XD

Should I look at it?

Appreciate it! Agreed. Thankfully I just completed that this week. It's not ideal rolling my own letsencrypt "pki", but it should work okay for what I'm doing. It's just not setup for provisioning new domains automatically.

Yeah, we don't have root CA trust on client devices. Which, as far as trust goes, I like. It's the steps involved and corps that gatekeep it. But to be fair, someone has to manage those certs and distribute them to clients. Nostr doesn't have that chain of trust, it won't, trust is a centralizing force.

Thanks, so money is the solution? I'm not missing anything?

If ya'll had any insight I'd appreciate it.