@DanConwayDev @Arjen @hzrd149 @Freedom Tech Co. Forgot to mention, also added OCI/Docker!

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?

Thanks! 1. Not following completely to be honest, if your keys are stolen you're cooked anyway. Planing to mitigate that in other ways. Timestamps and invalidation smells complexity 2. Nothing stopping you from pointing to a tarball (I have come across thousands of apps and never seen that, though). There is also a commit tag. 3. Out of scope, I guess can use `variant` if needed, or just specify that manually to users of your application

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.

Why not zips?

What is that?

How, if at all, do SDKs fit in?

I think he green art means archives like .zip

"Yo, SDKs are like the secret sauce, right? How do you think they vibe with the whole dev flow? 🤔 #DevLife #SDKs"

You said you have a explicit goal of not supporting tar or zip, just wanted to know why

Because then people will start calling it Zipstore. And that cannot happen! :PepeLaugh:

Oh because zip files are not a runnable format. Why would you want them?

To ship web apps. A http server lists those apps, the user selects what app he wants, download, extract and start running it locally

Developers constantly replace releases on users, bitchat for example recently did that and there are countless others. The Zapstore indexer captures releases from Github once and when the developer edits the release/associated assets the download breaks and users start yelling, so I know well how many times that happens. I don't think any of those edits were nefarious, they all seemed reasonable. Software assets (kind 3063) are regular events that carry version information, those could be kept around, however if I had social signal that a key was compromised I would stop trusting it altogether. If I already have the software installed and I believe it's pre-compromise I would keep running it. Developers are encouraged to use bunkers, not hotkeys. In addition I just introduced this:

NostrHub

NostrHub | Discover and Publish NIPs

Explore official NIPs and publish your own custom NIPs on NostrHub.

which has support in zsp (publisher tool) but not the UI yet. Interesting model because to compromise it you kinda need to hack *both* keystore and nsec -- for updates at least.

How is that better than Web Bundles?

cc @AU9913 - docker!

Web bundles was removed from chrome in 2023 and there's no support for it anywhere. Am I looking at the wrong thing?

Hell yeah

Webpacks looks good from what I just tested since it's just a bundle.js so I could use that

Hmmm wot u mean

A shit standard is better than no standard?

"webpacks" wdym?

That is not a bundle, it needs to be one file. You can zip them up but it stops being a standard. Why is Web Bundle worse in this case? I don't care what Google does or stops doing

Zero browsers support web bundle. How do you run it?

Well... zero browsers support a zip file with webpack files. How do you run it?

LLM analysis of this: --- IETF Status: The draft (draft-ietf-wpack-bundled-responses) expired in 2021 and isn't being actively pushed through IETF standardization. WICG Status: Still active. - webpackage repo: 1,083 commits, 1.2k stars - substantial ongoing work - Subresource Loading with Web Bundles: Updated July 2024 - Isolated Web Apps: Separate WICG repo, uses signed web bundles (.swbn), actively developed Bottom line: The format isn't dead - it's in WICG incubation rather than IETF standardization. The spec work continues, tooling exists (wbn CLI, Go/JS implementations in the repo), and the format is well-defined. What Chrome did was deprioritize native browser support for loading .wbn files directly. But: - You can still create and serve web bundles - Tooling can read/write them - The format is stable and documented - Isolated Web Apps (which need offline + security) still use them For NIP-82 purposes: The application/webbundle MIME type is valid. A client can download a .wbn, verify its hash via the Nostr event, and serve it through a WebView - no browser-native support needed.

WebView also does not run web bundles.

Hello... If you're looking to elevate your trading skills and maximize your investment returns, I highly recommend DM Me.... I’ve experienced significant growth in my trading portfolio. Don’t miss the chance to take your trading journey to the next level. Text On Telegram 👉 t.me/Johnsavvy3

> 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.

Dude sorry, I'm not following what you say. We need a bundling format for the web. There is no mainstream format and much less runtimes for it. The best we got is Web Bundles, which at least has been worked on for years, despite not having a widely implemented runtime. You are also suggesting a bundled format (ad-hoc zip file with webpack?) but that is not a standard, and of course there are no runtimes. So forget about *anything* today readily available to run a packaged webapp. It is simply not a thing. We need to build it, and that's my intention with a .wbn runner inside Zapstore. I would like to understand your rationale on why a zip file is better than the Web Bundle spec.

Sure, but you're ignoring the rightful and practical use of replacing releases. Having immutable releases introduces complexity, so there are tradeoffs. Since by far most cases are "I made a mistake and need to patch this" I'm good with that. In your specific Ubuntu example, you could 100% keep immutable 3063 events, so I don't see how this spec prevents you from doing that

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.

you can audit via 3063 events

The standard for web is basically the same since the beginning. A folder with a index.html and all other needed files. All I'm saying if you zip a folder that contains a web app, it will work in any device without much effort. A web bundle may never exist and you need to wait for the browsers to start supporting it in maybe if we are luck a few years. If there's a tool to just zip the web app folder, hash it and upload it to some blossom servers them you can build a web app directory that anyone can use, verify etc

I don't know how else to say it, I don't care about whatever browsers gonna do. I don't need to wait for anything. You're describing Web Bundle exactly, which likely contemplates gotchas you haven't thought about. If you want to write a standard for zip files, this is what we tried with @hzrd149 long time ago, feel free to create a standard that we can reference (with a proper mime type) and I'll add it to the spec

Ok