TL;DR:

Static website without nip-07 support: publish just a bundle event
Static website with nip-07 support: bundle event + app listing event (for showing up on "app stores")

Both cases: Files uploaded to user's Blossom servers

Looks great! I had the same thought process as you, being napps are an implementation of static websites (we have been colloquially calling them nsites) where there is an additional NIP-07 compatibility and discoverability event added. I didn't really ever explore versioning like you, but I took it a step further with resolution. I really believe that local resolution is the end game, not remote resolution via gateways.

I actually started a thorium fork that aimed to natively resolve napps with a similiar thought process as 44b, preceded by a proof of concept (which was going to be napp.run) that almost panned out. Look up the whois on nsite.run and napp.run, compare the dates (lol).

Is there any way that the 1.5 year old "Static Websites" NIP and ecosystem could adopt your encoding solution for subdomains (the missing piece in nsite), and then NIP-C4 defines the app marketplace discoverability event and other criterion for napps?

The differences between event 37448 defined by NIP-C4 and 15128 and 35128 in NIP-XX (static websites) would be a trivial change for your singular implementation to make, less trivial for the existing ecosystem (20+ implementations and thousands of nsites). It's likely a more clean separation of concerns as well, because there are many cases where someone wants to just deploy a basic static website and not necessarily a napp. It is also possible that there are other extensions of Static Websites not yet conceived that would be inhibited by conflating the two use cases.

Out of curiosity, why did you find it necessary to define mime-types?

Interoperability here is implicit and basically guaranteed if the right compromises are made in the right places.

I didn't read the actual NIP yet, but the idea is very good.

@dskvr Although the initial intent was to interop, after reading your reply I thought that maybe nsite and napps should keep using different kinds if we start thinking at nsites as solely focused on classic websites with no NIP-07 support, like if nsites are a way to store people's blogs instead of people's kind 30023 clients?

NIP-07 support or lack of it could dictate what spec to use. It could avoid upload tools wrongly publishing app listing events for classic websites. Not sure though.

Out of curiosity, why did you find it necessary to define mime-types?

Mime-types can help in some situations, e.g a png file saved as favicon.ico is auto supported by browsers while favicon.png isn't. Knowing the mime-type we can send the right content-type header.

I would also like to see interoperability between this and nsites. it seems that a napp event could define the nostr app metadata and then point to a site manifest from nsite for the actual map of files

also I like the use of base32 for the pubkey encoding, I think I might steal it for the nsite nip to make named sites work with wildcard certs :)

@franzaps

@arthurfranca It would be quite awkward we didn't try, the static website events proposed last night are functionally the same as the nsite specification that been in development since September of 2024, or am I missing something?

With some interop, you could kind of get the best of both worlds and there would be an easy path to napps.

There are and will probably always be NIP-07 enabled nsites, the distinguishing factor for users is likely if they need release channels and app store listings. Maybe they deploy prototypes to nsites and promote them to napps. Or maybe they are minimalists.

It seems clear to me that the core proposition of napps is to define an implementation of static websites resolved over nostr, not really the static websites themselves.

@dskvr @hzrd149 regarding #1538 I suppose I could update my code to use kind:35128. However, I thought that people were mostly using the nsite old spec that uses other event kinds and so it wouldn't hurt that much for you to change the #1538 to the structure and kind from the bundle event? Or else I would have to change a lot of places, a big pain. I rushed to write this NIP exactly to not have to change the bundle event kind and structure as I though there was still time before people started using the new nsite spec xD

Like, it would be great if you could use the bundle event for#1538 PR and then on this napps PR I could simplify it to point to your PR and then define just app specific extensions like the listing events etc. What do you think?

Also, I have some questions regarding #1538:

1. you just added base32 for the subdomain instead of base36, why? we could represent a pubkey with 50 chars if following the reference implementation I mentioned here instead of 52.
2. you didn't follow instructions from this napps NIP to reserve 5 chars on the subdomain for my use case. i absolutelly need that for 44billion.net to work, which would limit the "d" tag to 7 base36 chars instead of 11. If you use 11 chars we can't interop, it's just technically impossible.

@arthurfranca I think the difference is that we have been working in the open for 1.5 years, and you have presented something great, but at the same time are suggesting for us to completely pivot everything over to your spec. That's not really interoperability, that's hostile takeover.

1. I agree that base36 is a better fit here.
2. Why are the 5 chars required?

Some comments on the static website section of the NIP; Everything else looks great.

1. The mime-types for every file may be superfluous and increases event size, which presents a lower ceiling for the NIP-44/NIP-46 case. I understand the edge case you've presented and it makes sense.
2. nsite includes blossom server hints instead of solely relying on 10063
3. nsite uses path instead of file because the event is contextual to routing

The only really breaking difference is the d tag right now it seems, maybe you and @hzrd149 could come to an agreement on that.

Entirely possible that I am missing something.