Open Architecture for Content Types

[manimejia]

This issue now lives as an article on nostr for additional discussion and refinement. Thank you for participating.

https://yakihonne.com/article/naddr1qq257drt244x6ufkx3xyzs6kdpuh5n3jg459qq3qmanlnflyzyjhgh970t8mmngrdytcp3jrmaa66u846ggg7t20cgqqxpqqqp65w7gtxrh

[vitorpamplona]

So, you are basically replacing an integer kind for a string kind and putting it inside tags. But the kind is still there regardless. It doesn't seem to add any new functionality.

[manimejia]

AKA refactoring. Not sexy, but often required for scalability.

Thank you for the feedback. Consider the benefits of NOT having some things locked in a rather centralized and disorganized protocol review process.

FreeTheOtherStuff

[vitorpamplona]

There is no centralization in event kinds. If you want something new just pick a number and go for it. You don't event need to submit an NIP.

[vitorpamplona]

often required for scalability.

I don't think switching from int to text does anything for scalability.

[manimejia]

A NIP proposal (PR) will be forthcoming, depending on the discussions in this issue. Here are some possible highlights of what such a NIP would specify

The NIP proposal details (int vs string) is not the thrust of this issue I raise.

And yes... pick a number and anyone can make a new event kind.

And yes... this entire issue is a big ask, for a big win. We should not take this lightly, and I appreciate your considered responses.

Please consider the benefit of (one way of) nipping nip bloat by formally offloading content type design into the "implementers" who are in the trenches where the real action is.

[fiatjaf]

I understand your concerns and your desire for flexibility, but I think you haven't thought enough about the compatibility. Nostr is not a dumb pipe like TCP where you can just write anything, it is a layer on top with an agreed upon format for events, and then other layers on top which are sub-formats agreed upon again.

You cannot skip the part in which different people have to agree on specific formats. If that is done by kind numbers or tag strings doesn't make much difference in the long run, but I do think kind numbers offer a better trade-off overall.

[fiatjaf]

Also the NIPs are not a centralized gate preventing you from coming up with your own subformats, it is just a place where we write down standards so others can implement them.

Yes, the discussions are annoying, but that would happen in any situation in which you would have to agree with others.

[manimejia]

Thank you for considering.

Yes, the discussions are annoying, but that would happen in any situation in which you would have to agree with others.

What I'm proposing is actually a formalized process for bypassing the annoying discussions.

• At least for novel content structures,
• or novel use cases for existing structures.
• At least for the initial "what if" and "let's see if this flies" ideation phase.

you cannot skip the part in which different people have to agree on specific formats.

Yes. We can. By formalizing a process by which clients and relays test out new ideas on their own ... If users are satisfied then it spreads organically. Many test environments under a single protocol means less people have to "agree" to see good ideas bubble up.

Also the NIPs are not a centralized gate preventing you from coming up with your own subformats, it is just a place where we write down standards so others can implement them.

With all due respect… this doesn’t even make sense. Developers look to standards for guidance. We are unabashed rule breakers, but only once we’ve exhausted all the ”right ways” of doing a thing. We not only expect to memorize the NIPs, for the sheer love of what nostr IS, we are bound to make sure every good thing we build ends up eventually as a nip.

The actual reality in practice (regardless of design) is that NIPs are the center of the nostr universe. NIPs will bloat. Like it or not.

Nostr’s future (IMHO) lies in knowing how to iteratively pair down and simplify the protocol at the same time as growing nostr and its implementation possibilities.

PS It's highly likely that I haven't thought the details through enough. Forgive me. I’m just a nostr nobody. Thank you for the opportunity to participate.

[melvincarvalho]

The actual reality in practice (regardless of design) is that NIPs are the center of the nostr universe

Agree. It's not even clear who even owns the NIP area. It would be good for it to become less of a single point of failure. I'd love to see people like Will, Semisol, Alex, Bumi, Pablo (apologies if ive missed anyone!) become co-owners.

The NIPs have been a very practical way of working in this first year, but we are hitting single points of failure issues.

[mikedilger]

I think that without some sort of coordination about what an event kind means (or a "c" tag if that were to happen), we are going to get lost. The meaning of the content-type/event-kind needs to be a shared understanding. Expressing that as a NIP helps the rest of us to write code supporting your new content type. Not expressing it as a NIP means your new content-type isn't going to become widely supported.

Adding a NIP isn't hard as long as it makes sense. And we all work together to try to make drafts make sense if there is a kernel of sense in them.

[manimejia]

The meaning of the content-type/event-kind needs to be a shared understanding. Expressing that as a NIP helps the rest of us to write code supporting your new content type. Not expressing it as a NIP means your new content-type isn't going to become widely supported.

Thank you Mike.

The value proposition in decentralizing the "design, testing, publishing, extending, and implementation" of novel "content types" is that such a "shared understanding" only bubbles up to the NIP level once a particular implementation becomes popular enough. (EG: two or three clients and relays are testing out a new content "feature" with good success.) This proposed architecture tries to provide a formal workflow for good ideas to bubble up, without polluting the NIP proposal space with (what will be many dozens) of content types.

The success of this proposal relies heavily on another issue I raised, (#862 Bidirecrional "handshake") for clients and relays to be able to discover what each other supports.

I'm still hot on this topic, but I think coming out with all guns blazing (my typical MO, for better or worse) is the wrong approach for this type of big picture thinking. Imma focus my "issue pushing" efforts on getting #862 accepted first. And try to "slow roll" (some version) of this one by engaging the larger nostr community with more discussion.

[erskingardner]

NACK. To me, his doesn't seem to add anything but complexity. Our number space for kinds is sufficiently large and the NIP process time and time again results in smarter, cleaner, more usable specs for doing a given thing. Building on nostr doesn't require having a merged NIP, just pick an kind number for your use case and go build.

The idea of having to do handshakes with relays and keeping lists of content types up to date (and all the variants of similar things that client developers will throw in there) sounds like a much worse fate than getting bike-shedded when trying to get a NIP merged.